微服务开发要点,微服务模式与CAP理念

前言 

前几篇博客我跟随大佬学习了一些浅薄的微服务知识,
也知晓即使在云技术的加持下,微服务依旧有许多的问题需要处理~
针对这些问题,大牛们提出了以下微服务开发要点与模式,
本文将对其进行介绍~

---

微服务开发要点

 - 位置透明
意为微服务之间的通信不依赖于具体的物理位置,
而是通过服务注册和发现机制,动态获取服务的地址和端口,
eureka、nacos等均可实现.
我个人的理解是所有地址对中心服务器透明可见,
方便根据服务名查询其url地址.

 - 有弹性
值微服务应该具备在面对各种故障和压力时,能够保持正常运行,
或拥有快速恢复的能力.
这个概念本身所指非常"泛",具体点描述应分为以下四种

   1.服务的可观察性:服务应易于通过日志,监控,跟踪等手段,实时了解服务的运行状态,性能指标,异常情况等等.
   相关实现:spring-boot-actuator,sleuth等~
   (毕竟解决问题的第一步永远是发现问题来着(～￣▽￣)～)

   2.服务的容错性:服务应能够通过熔断,降级,重试等策略,避免单个服务的故障导致整个系统不可用或性能下降.
   (就比如你一个项目的记录历史的功能给高并发冲麻了,你总不可能整个服务都寄吧~)

   3.服务的伸缩性:这个概念本身也是微服务开发要点之一,不仅仅是"有弹性"要点下,故之后讲~

   4.服务的可恢复性:服务能够通过备份,回滚,灾备等措施,在发生严重故障时,快速恢复服务的正常运行~
   (没想到微服务也会有备胎,啊不,灾备的概念ヾ(≧▽≦*)o)

 - 可重复
微服务要求将项目中公共的部分抽取出来,封装成公共模块或公共服务~
这样做能够方便其它模块或服务调用,能提高代码的复用性,可维护性和一致性,
以便减少冗余和错误~

 - 大小适当
值微服务的粒度应该既不过大也不过小.
需要根据业务能力和团队来合理划分~

 - 可伸缩
之前在有弹性中提到过,我个人也认为其与"有弹性"部分息息相关~
是指微服务的能力可以根据需求动态的添加和删除系统中的资源,
从而适应不同的负载和性能要求~
目前多见操作有:
   1.用容器技术(Docker:自然是我的主场~)将微服务打包为轻量级,独立的部署单元.
   (Docker:一个镜像装全家,打包发布就是方便~)
   2.使用集群技术,如Kubernetes(感觉不如k8s...好记上),将容器部署到多个节点,并实现水平或垂直拓展~
   3.使用负载均衡技术,如使用nginx将请求分发到不同微服务实例上,实现负载均衡和故障转移.

   ~~(ps:感觉不如f5,人家硬件负载均衡可比你nginx强多了~)~~
   ~~(A:你也不看看自己几个钱就学人家玩f5~~)~~

   4.使用消息队列技术,如RabbitMQ或Azure服务总线,
   实现异步通信和事件驱动架构,降低微服务之间的耦合度和网络延迟.

以上便是微服务开发要点,接下来是微服务模式的部分~

---

微服务模式

微服务模式亦分为多种,待我一一来写~

其一是核心微服务模式:微服务模式中绝对的核心(废话),有以下几个主要概念:

 - 服务粒度(这个概念对应的貌似是上面的大小适当来着?)
 - 通信协议(服务之间进行通用的协议,目前主流大概率还是json~壮哉我大spring-cloud~)
 - 接口设计(良好的接口能便于开发人员及服务本身进行调用~像feign或者openfeign框架所实现的那样~)
 - 服务的配置管理(毕竟我总不能每个服务设置一次配置吧...服务一多我修改配置要上天来着...)
 - 服务间的事件处理(使用事件解耦微服务,以便最小化服务之间的硬解码模式~个人感觉与promise的.then()非常相似~)

其二便是微服务路由模式,它保证客户端应用程序能发现服务的位置并路由到服务~
其基本分为服务注发现与服务路由来着~

[微服务路由模式示例图]

服务发现主要作用是为根据客户端请求中的服务名,抽象出服务的物理地址.
服务发现还包括实例健康度监测(剔除报废节点)等等~

而服务路由则更类似一个向导~
其能为微服务客户端提供单一的逻辑URL来进行通信~
还可以作为授权,验证和内容检查的策略实施点~

其三为微服务客户端弹性模式,其作用是防止单个服务中的问题级联暴露给服务的消费者~
常见的四种客户端弹性模式有:

 - 客户端负载均衡(简称选服务~)
 - 断路器模式(服务出问题不拔线让其快速失败是绝对不行滴~)
 - 后备模式(当服务调用失败时会尝试通过调用微服务之外的其它方法来执行工作)(我差点把它和灾备搞混来着...)
 - 舱壁模式(你就这么多资源,随便造,反正影响不到其它服务~)

其四是微服务日志记录与跟踪模式
(毕竟微服务将单体应用拆成了多份,日志也一样,我总不能满天找日志吧...)
 - 日志关联:通过唯一的标识id,使每个服务生成的日志条目联系起来~
 - 日志聚合:将微服务生成的所有日志合并到一个可查询的数据库中~
 - 微服务跟踪:在涉及所有服务中可视化客户端事务的流程~

之后还有几项如微服务构建和部署模式,微服务安全模式等等,不过碍于篇幅不过多描述了~

---

CAP理论

微服务还有一项相当重要的理论:CAP理论

[CAP理论示意图]

CAP理论指出:一个分布式系统最多只能同时满足

 - Consistency(一致性)
 - Availability(可用性)
 - Partition tolerance(分区容错性)

这三种中的两种.
毕竟如若要保证一致性,则需要花费更多的性能在数据同步上,自然难以保证可用性
而要保证可用性则更好相反~
所有AP和CP只能按需选择一种~
(啥?你说你想要CA?简单!单体应用,请ヾ(≧▽≦*)o)

---

 后记 

这是本人所写第三篇博客~
说这个是因为...
这篇博客质量确实不咋地,有点像流水账一般~
理论性一多我确实不太会排版啥的~
之后如有可能,我会尽力提升博客质量的!