SCL和你聊聊--微服务架构模型

我们都知道将若干功能完整、相对独立的模块以微服务的形式进行开发、部署和演进可以获得较高的效率和较低的维护成本。那么微服务的架构模型应该是什么样子呢？

 

一、单应用的角度

单应用其实就是我们最熟悉的三层架构——DAL数据访问层、BIZ业务逻辑层以及WEB能力输出层。WEB可以是http基于url请求的形式、也可以是rpc基于服务提供的形式；BIZ层是业务逻辑的组装，当然简单的业务逻辑可能只涉及数据库操作或者API调用，复杂的则需要一些缓存设计以及设计模式相关的知识去做封装处理；DAL层主要负责数据的存取，说白了就是数据库的操作，需要显示地或者使用工具来处理一些分库分表、读写分离、主从一致的问题。

 

二、领域能力提供的角度

单应用是微服务持续迭代和演进最小的维度，而当我们输出域能力的时候，往往需要若干个微服务之间相互配合，比如优惠域能力就依赖于预算、库存、（优惠）活动多个域能力的输出和组装。从架构上来说，领域能力的完整提供从下到上可能会包含领域层、代理层、接入层、展示层。领域层类似于单应用中的DAL层，代理层类似于BIZ层，而接入层是屏蔽多端对接差异而单独存在的一层，可能不被需要，展示层类似于WEB层。

 

三、拆还是合

集中式架构的问题显而易见，但是过于细粒度拆分的微服务架构也是灾难，比如说将一张表或若干表的CRUD操作简单地封装一层壳子作为一个微服务提供出去，而它本身明明更适合于依附于一段更完整的业务逻辑存在。这样的拆分就会带来几个问题：1、维护困难，每次至少需要改动两个项目；2、测试、问题排查更加麻烦、困难；3、资源成本更高，至少需要更多的机器来部署；因此我们要考虑好的一个问题是到底在这一层做单应用的逻辑聚合还是抛到上层做微服务间的逻辑聚合，也即是否需要将某个子域独立为微服务，以实现整体复杂度和快速迭代之间的平衡。

 

 

其实我们可以参考组件层级三原则：REP（复用、发布等同原则）、CCP（共同闭包原则）、CRP（共同复用原则），REP说的是要复用一段代码就把它抽成组件；CCP说的是将为了相同目的而同时修改的类放在抽成组件，是SRP原则在组件层面的描述；CRP说的是不应该强迫组件依赖它不需要的东西，是ISP原则在组件层面的描述。前两者是粘合性原则，会让组件更大，而后者是排除性原则，会让组件更小。

 

在项目的不同时期或者说在域能力逐步完善的各个阶段，我们的侧重点是不一样的，可能在项目初期确立了一些领域和职责划分来指导应用分包，但是随着时间的推移，某些功能不断的完善壮大，领域模型愈发清晰，我们就需要依据CCP将它独立出去；同时，如果我们发现某些领域虽然相对独立但是逻辑足够简单，也不妨依据CRP将其组合到上层。我们需要学会在不同的时间节点重新审视曾经的微服务架构模型。

关注源代码清单，技术人的学习清单