微服务架构及设计模式微服务架构及设计模式
本篇文章一共分为三个部分,分别是微服务架构的演进过程、具体实践微服务的应用技术和领域驱动设计的意识转变。微服务
架构已经渗透到互联网应用的方方面面,而领域驱动设计也逐渐被业界所接收。
微服务架构几乎都是从 ALL IN ONE 的单体架构演进而来,中间又经历了分布式架构、面向服务架构的演进过程。
单体架构往往以烟筒式方式发展,往往存在两个主要问题:中心化和耦合度高。所谓中心化,就是数据集中存储在单个数据库
中,业务系统集中部署在单台服务器上,通过集群部署方式提供服务能力,然而中心化的问题,也就是单点问题。而耦合度
高,主要是指其中一个功能模块升级,其它的模块都得一起升级。这里要说明下,模块依赖度高不是单体架构的错,是因为本
来架构可能就没有设计好,但是,在实际场景中,随着快速迭代开发,研发换了一波又一波,产品走了一茬又一茬,难免系统
架构腐化严重。
看到了单体架构的诸多问题,系统开始通过按功能或模块进行拆分,拆分成多个独立的子系统,系统间通过 RPC、MQ 方式
调用,由此逐渐演变为分布式的服务架构。分布式服务架构主要通过服务化和层次化进行解耦拆分,《架构整洁之道》书中提
到一点,系统可以降解为策略和层次,而架构设计就是把相同的策略分到同一个组件中,反之,分属于不同的组件。所以,架
构设计可以通过分层设计,由高层次服务调用低层次服务,低层次服务通过接口向上提供服务,以实现系统之间的解耦。也正
是在这一阶段,单体架构一下子被拆分成几个或几十个系统。
但是随着架构的发展,问题又接踵而来,在没有做好边界的划分之前,系统拆分的服务往往是松散的。正如《架构整洁之道》
所讲:软件架构设计本身就是一门划分边界的艺术。所以,很多系统在这一阶段,又往往进行了服务内聚和去层次化的演变过
程。所谓服务内聚,就是以领域驱动设计为原则,重新界定领域边界,对模块进行服务整合,对系统进行合并。而去层次化,
则是去除服务层次高低之分,按服务调用最优链路提供服务请求,降低深度,以此保证系统的稳定性能。
系统如何从 0 到 1,从 1 到 2,从 2 到 100,在具体实践微服务的过程并不容易。首先,考虑的第一个问题是:微服务是什
么?其实,微服务是一个动作:拆。说到拆,就涉及到两个问题,第一,怎么拆?第二,拆到什么程度。
第一个问题,关于怎么拆,需要关注两个层面,一是发版速度,如商品、交易、促销等不同领域的迭代速度和开发速度是不一
致的,所以,应该拆分到不同的领域,否则,就可能耦合在一起,A 上线 B 必须跟着一起上,这可能就应该合并到一起。另
一个是能源协同,每个系统后面对应不同的研发团队,一个项目往往需要几个团队分工协作,那么系统拆分必然导致团队协作
的成本,所以拆分系统同样也是拆分团队,要考虑协作沟通所带来的成本。
第二个问题,拆到什么程度。其实,已经有很多人对微服务进行了定义,其中我认为最重要的两点:一是微服务或一组微服
务,应该是一套独立部署运行的服务,二是微服务所依赖的数据资源应该是彼此间相互独立隔离部署的。