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

作者：京东科技 康志兴

前言

从强调内外隔离的六边形架构，逐渐发展衍生出的层层递进、注重领域模型的洋葱架构，再到和DDD完美契合的整洁架构。架构风格的不断演进，其实就是为了适应软件需求越来越复杂的特点。

可以看到，越现代的架构风格越倾向于清晰的职责定位，且让领域模型成为架构的核心。

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

传统三层架构

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

三层架构特点就是简单，适用于一些无复杂业务场景的小型应用，或者“数据不可变”作为基础原则的DOP（面向数据编程）服务。

但是当业务场景稍微复杂一些、调用层级较多时，可复用性、可维护性就都非常差了，很多代码都耦合在一起，牵一发动全身。





DDD架构

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





优点

如此多的优点自然带来明确的缺点

简单的微服务分层架构

基于六边形架构规范的接口适配原则和防腐理念，同时借鉴了CQRS模式的优点，我们定义了一个简单的微服务分层架构。





 

分层定义如下：

最佳实践

优点

1. 开发效率

简单的业务开发过程中，相比较书写核心业务逻辑，更多的工作量几乎都是来自处理跨层调用时对象转换和Mapper定义，通过MapStruct和Fluent-Mybatis等组件的使用（也许再加上GitHub Copilot😁），编写一个实体的增删改查接口基本在5分钟内搞定，省下来的时间可以多走读两遍代码或者多写几个分支的测试用例，也算是降本增效了。

2. 服务隔离

通过module隔离不同的领域服务，降低不同领域服务之间的耦合程度。

3. 外部服务防腐

远程调用统一封装在基础设施层中，降低外部变化对系统内部的影响。

缺点

由于对基础设施层的依赖没有通过api包进行隔离，所以基础设施层的对象会直接暴露在领域服务层和门面层。对此可以通过使用ArchUnit组件进行架构防腐。

如果需要定义完善的领域实体充血模型，建议参考DDD架构定义gateway层来进行基础设施层的依赖倒置。

最后

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

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