微服务引出

从早期的单体架构,逐渐演化出SOA架构模式,webService、ESB、Dubbo等等实现方式,到现在流行的微服务架构,核心解决问题,就是服务的高可用、高并发.

而在大多数场景下,服务的高可用是我们尤为关心的(毕竟高并发并不是所有系统都需要),但高并发和高可用是相互影响,高并发说白了就是在大TPS下的高可用的支持.

微服务

微服务架构中,各个业务单独运行,要求支持横向扩展.其要求每个子服务由单独的缓存、单独的数据,尽量避免单点故障造成的服务雪崩.

微服务的基本架构,要求我们将系统根据不同领域分成一个个单体子服务,那我们在拆分服务时有什么原则呢?

微服务拆分

常用的微服务拆分原则,常用有下面这四个:

AKF拆分原则(AKF的公司的技术专家抽象总结的应用扩展的三个维度):理论上按照x,y,z三个扩展模式，可以将一个单体系统，进行无限扩展。

AKF
前后端分离:前后端分开部署,互不影响
无状态服务:无状态服务原则并不是说在微服务架构里就不允许存在状态，表达的真实意思是要把有状态的业务服务改变为无状态的计算类服务，那么状态数据也就相应的迁移到对应的“有状态数据服务”中。
Restful通信风格:支持多语言,服务兼容性强

理想的微服务是要将系统按照业务的功能进行拆分,直到每个服务的功能和职责单一,甚至不可拆分位置.这样优点是

单机负荷小,服务耦合度小,内聚性高,发布上线快
故障影响小
系统伸缩灵活
扩容成本可控

但缺点同样明显:

服务数量过多,相互依赖关系服务,系统管理难度加大
,链路太长,问题排查困难

所以,实际项目中,我们需要根据业务,能够满足上层服务对底层服务自由编排并获得更多的业务功能即可,并需要根据组织团队人员的建设进行调整.

微服务组合模式和容错处理

业务被拆分为一个微服务,这里总结下微服务间的组合模式:

服务代理模式:通过一个代理层进行服务转发,在系统迁移时,通过新老系统双写、迁移数据、代理切换等操作可以平滑的进行服务迁移

微服务代理模式

服务聚合模式:常用的系统都如此,前端业务根据业务需要聚合底层的微服务,如交易系统对外提供商户定制服务,根据需要,调用商户系统获取商户数据、调用支付系统进行交易、调用计费系统进行费用计算.....

微服务聚会模式

服务串联模式:服务形成级联模式,层层调用,最后返回结果,此模式切记层级不要太深,否则问题很难处理

微服务串联模式

服务分支模式: 串联和聚合的组合,大多数微服务将形成此链路.因为实际业务的复杂性,形成分支组合很常见,这也是我们在做微服务治理时,提出要全链路跟踪的重要性原因.

微服务分支模式

服务异步消息模式:通过消息队列或异步定时处理,将长链路拆分为短链路,提高系统的TPS,但这里就会引出后面提到的数据的最终一致性、异步补偿措施等问题处理.

微服务异步消息模式

服务共享数据模式:对于一些批处理、运营功能集中处理需求,我们经常和各个微服务进行数据共享,即公用相同数据库,但这些系统大多数是提供辅助功能

微服务共享模式

微服务的一致性设计

系统根据业务需求拆分成多个微服务,状态一致性问题将无处不在,我们一般遵守如下原则:

ACID理论:指数据库中事务正确执行的四个要素的缩小，包含原子性(Atomicity),一致性(Consistency),隔离性(Isolation),持久性(Durability)。当用到分布式系统设计上同样适用.
CAP原则:指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。CAP定理明确了分布式系统所能实现系统的局限性，目前互联网中的很多分布式系统是基于首要满足可用性和分区容忍性而设计的。
BASE理论: BASE全称是BasicallyAvailable（基本可用）, Soft-state（软状态/柔性事务）, Eventually Consistent（最终一致性）。BASE模型在理论逻辑上是相反于ACID（原子性Atomicity、一致性Consistency、隔离性Isolation、持久性Durability）模型的概念，它牺牲高一致性，获得可用性和分区容忍性。

常用的实践方法有很多,下面类举常用5种:

查询模式:应对超时,异步调用失败的常用方法.
补偿模式: 对于异步处理逻辑,总会出现各种各样问题引起调用失败,通过补偿机制,我们实现最终的状态一致性.
异步回调确认模式: 核心服务迅速返回,通过异步回调,通知调用方进行状态变更
定期校对模式: 对于数据定期扫描检查,核对一致性.发现异常,即使预警纠正
服务端幂等的可靠消息模式:服务端提高幂等服务,消息发送端必须在接受服务端的成功反馈后才结束状态同步操作.

微服务项目结构

微服务项目对外提供restful服务,各语言间可以通过http传输json格式进行通信.而java微服务项目一般可以分为三层:服务发布层、接口层、实现层.

发布层:提供对外web服务
接口层:提供服务端和消费端公用的类
实现层:提供实际的业务实现

微服项目结构

总结

在实际工作中,微服务的拆分和部署更加复杂多变,我们要考虑的问题也更多.如对于系统故障的处理,如何做系统的失败熔断措施,如何实现对核心服务的限流保护,甚至单系统中不同模块的线程池隔离保护等等.
“编程路漫漫,修行在个人”,其实好多道理可能大家或多或少都接触过,我们要做的就是不断总结、反省、提炼、优化,才能不断提高自己艺术水平!

上一节: 谈谈设计思想(2)-延伸代码设计思想和微服务思想