关于架构设计:架构与设计常见微服务分层架构的区别和落地实践

作者：京东科技 康志兴

前言

从强调内外隔离的六边形架构，逐步倒退衍生出的层层递进、重视畛域模型的洋葱架构，再到和 DDD 完满符合的整洁架构。架构格调的一直演进，其实就是为了适应软件需要越来越简单的特点。

能够看到，越古代的架构格调越偏向于清晰的职责定位，且让畛域模型成为架构的外围。

基于这些架构格调，在软件架构设计过程中又有十分多的架构分层模型。

传统三层架构

传统服务通常应用三层架构：

• 门面层：作为服务裸露的入口，解决所有的内部申请。局部状况下，门面层甚至不须要独自定义对象而是间接应用服务层的实体定义。

• 服务层：作为外围业务层，蕴含所有业务逻辑。并对根底层能力进行简略组合提供肯定的能力复用。通常服务层会进行实体定义来避免上层对象体间接裸露给内部服务，导致底层任何变动都有可能间接传递到内部，十分不稳固。

• 根底层：用来寄存 dao 和内部 rpc 服务的封装，二者能够拆分为不同的 module，也可合二为一，以不同 package 进行隔离。

三层架构特点就是简略，实用于一些无简单业务场景的小型利用，或者“数据不可变”作为根底准则的 DOP（面向数据编程）服务。

然而当业务场景略微简单一些、调用层级较多时，可复用性、可维护性就都十分差了，很多代码都耦合在一起，牵一动员全身。

DDD 架构

DDD 架构能够看做是整洁架构的一种实现，分层职责如下：

• 适配层：用来做内部不同端申请的适配器，隔离不同端的协定差别，包装不同端不同款式的响应体。

• 应用层：用例、工作入口、音讯队列监听均在这一层，能够了解为业务流程的入口，通过聚合根的结构执行相应的命令操作。

• 畛域服务层：蕴含外围的畛域服务定义，并定义了 gateway 来做一层依赖倒置，使基础设施层仅做实现。

• 基础设施层蕴含所有根底能力：数据库、ES、近程调用封装等等。

长处

• 外围稳固：畛域模型在依赖链上是顶层角色，不依赖任何其余模块，所以极其稳固。其余任何业务域、存储、边缘能力的变动都不会对畛域模型造成影响。

• 麻利：适宜不同团队一起开发和保护而不会产生抵触。

• 可拆分：当有届上下文随着演进逐步收缩时，很容易拆分成微服务。

• 可扩大：增加新的性能非常简单，从而使得开发人员可能更快的部署和调整。

• 可演进：良好的可测试性带来非常低的重构老本，不会随着一直迭代导致我的项目成为难以批改的“大泥球”。

如此多的长处天然带来明确的毛病

• 专业性要求较高：须要对业务、架构准则了解粗浅的人员进行设计和保护，不失当的畛域模型将使后续迭代极为苦楚。

• 开发成本高：简单的架构设计，更多的架构分层，天然带来代码行数的指数级增长。尤其是项目前期的开发工作变得异样沉重。

• 不再适宜简略的业务场景：实现一个简略的 CRUD 显得过于简单。

• 扭转决策艰难：尝试应用整洁架构须要和团队的管理层和其余成员达成统一，这往往须要十分弱小的说服力。如果在架构演进过程中想切换回其余架构模式也十分困难，简直是整个我的项目级别的重构工作。

简略的微服务分层架构

基于六边形架构标准的接口适配准则和防腐理念，同时借鉴了 CQRS 模式的长处，咱们定义了一个简略的微服务分层架构。

分层定义如下：

• 门面层：作为程序的入口，通过包隔离来寄存 JSF 服务、Rest 服务、定时工作和 MQ 生产，其中对外提供服务的接口定义寄存在独自的 api 包中。该层的申请定义命名以 Request 结尾，响应体命名以 Response 结尾。

• 畛域服务层：每一个畛域服务寄存在独自的 module 中，并通过独自的 api 包对外裸露能力。该层的命令申请定义命名以 Command 结尾，查问申请定义命名以 Query 结尾，响应体命名以 Dto 结尾。

• 基础设施层：寄存数据库、ES、近程调用服务的封装。该层的长久化数据定义命名以 Po 结尾。近程命令服务入参命名以 RpcCommand 结尾，近程查问服务入参命名以 RpcQuery 结尾，响应体命名以 RpcDto 结尾。

最佳实际

1. 命令服务必须拜访畛域服务层，容许简略查问间接调用基础设施层。
2. 参数校验、申请出入参日志、审计日志记录、TraceID 预埋、异样解决等非核心业务能力均由公共组件实现，缩小我的项目外部的边缘能力代码。
3. 因为在门面层进行对立的异样解决，非必要时无需在我的项目中进行大面积的 try-catch，让代码更清新。
4. 理论开发过程中，门面层、畛域服务层和基础设施层均有各自的实体定义，跨层调用的对象体转换应用 MapStruct 组件来缩小手写映射代码的工作量。
5. 数据层应用 Fluent-Mybatis，最大益处是缩小前期迭代中，数据对象增减字段时批改 Mapper 的老本。

长处

1. 开发效率

简略的业务开发过程中，相比拟书写外围业务逻辑，更多的工作量简直都是来自解决跨层调用时对象转换和 Mapper 定义，通过 MapStruct 和 Fluent-Mybatis 等组件的应用（兴许再加上 GitHub Copilot😁），编写一个实体的增删改查接口根本在 5 分钟内搞定，省下来的工夫能够多走读两遍代码或者多写几个分支的测试用例，也算是降本增效了。

2. 服务隔离

通过 module 隔离不同的畛域服务，升高不同畛域服务之间的耦合水平。

3. 内部服务防腐

近程调用对立封装在基础设施层中，升高内部变动对系统外部的影响。

毛病

1. 基础设施层的实体作为顶层依赖

因为对基础设施层的依赖没有通过 api 包进行隔离，所以基础设施层的对象会间接裸露在畛域服务层和门面层。对此能够通过应用 ArchUnit 组件进行架构防腐。

如果须要定义欠缺的畛域实体充血模型，倡议参考 DDD 架构定义 gateway 层来进行基础设施层的依赖倒置。

最初

软件工程的方方面面都遵循一个最根本的情理：没有银弹，架构分层模型更是如此，每一种都有各自优缺点，所以请依据不同的业务场景，并遵循简略、可演进这两个重要的架构准则抉择适合的架构分层模型即可。

架构不只是工作，更是一门艺术。