登录
/
注册
首页
论坛
其它
首页
科技
业界
安全
程序
广播
Follow
关于
每日签到
每天签到奖励2圆-6圆
发帖说明
VIP申请
登录
/
注册
账号
自动登录
找回密码
密码
登录
立即注册
搜索
搜索
关闭
CSDN热搜
程序园
精品问答
技术交流
资源下载
本版
帖子
用户
软件
问答
教程
代码
写记录
写博客
VIP申请
VIP网盘
网盘
联系我们
每日签到
道具
勋章
任务
设置
我的收藏
退出
腾讯QQ
微信登录
返回列表
首页
›
业界区
›
业界
›
【架构与设计】常见微服务分层架构的区别和落地实践 ...
【架构与设计】常见微服务分层架构的区别和落地实践
[ 复制链接 ]
骆熙华
2025-6-6 09:45:22
作者:京东科技 康志兴
前言
从强调内外隔离的六边形架构,逐渐发展衍生出的层层递进、注重领域模型的洋葱架构,再到和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结尾。
最佳实践
命令服务必须访问领域服务层,允许简单查询直接调用基础设施层。
参数校验、请求出入参日志、审计日志记录、TraceID预埋、异常处理等非核心业务能力均由公共组件完成,减少项目内部的边缘能力代码。
由于在门面层进行统一的异常处理,非必要时无需在项目中进行大面积的try-catch,让代码更清爽。
实际开发过程中,门面层、领域服务层和基础设施层均有各自的实体定义,跨层调用的对象体转换使用MapStruct组件来减少手写映射代码的工作量。
数据层使用Fluent-Mybatis,最大好处是减少后期迭代中,数据对象增减字段时修改Mapper的成本。
优点
1. 开发效率
简单的业务开发过程中,相比较书写核心业务逻辑,更多的工作量几乎都是来自处理跨层调用时对象转换和Mapper定义,通过MapStruct和Fluent-Mybatis等组件的使用(也许再加上GitHub Copilot
来源:程序园用户自行投稿发布,如果侵权,请联系站长删除
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!
架构
设计
常见
服务
分层
相关帖子
让服务来“敲门”!HarmonyOS 近场能力激活服务找人新价值
Folly Expected 错误处理设计指南
软考高级“系统架构设计师”学习笔记
软考高级“系统架构设计师”论文——论微服务架构及其应用
MySQL常见存储引擎
原型设计实用干货!3款热门AI生成原型图软件横向测评
[OLAP/Doris] Doris 之表设计
为时序数据库 IoTDB 底层架构“保驾护航”,来听听新晋 Committer 的贡献心路!
Flutter应用架构设计:基于Riverpod的状态管理最佳实践
vip免费申请,1年只需15美金$
回复
使用道具
举报
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
照妖镜
相关推荐
业界
让服务来“敲门”!HarmonyOS 近场能力激活服务找人新价值
0
749
纪睐讦
2025-09-02
安全
Folly Expected 错误处理设计指南
0
710
吉娅寿
2025-09-07
安全
软考高级“系统架构设计师”学习笔记
0
454
渭茱瀑
2025-09-07
安全
软考高级“系统架构设计师”论文——论微服务架构及其应用
0
941
乱蚣
2025-09-08
安全
MySQL常见存储引擎
0
398
芮梦月
2025-09-09
安全
原型设计实用干货!3款热门AI生成原型图软件横向测评
0
942
庾签
2025-09-09
安全
[OLAP/Doris] Doris 之表设计
0
300
事确
2025-09-10
安全
为时序数据库 IoTDB 底层架构“保驾护航”,来听听新晋 Committer 的贡献心路!
0
214
石娅凉
2025-09-10
业界
Flutter应用架构设计:基于Riverpod的状态管理最佳实践
0
283
但婆
2025-09-11
高级模式
B
Color
Image
Link
Quote
Code
Smilies
您需要登录后才可以回帖
登录
|
立即注册
回复
本版积分规则
回帖并转播
回帖后跳转到最后一页
浏览过的版块
安全
签约作者
程序园优秀签约作者
发帖
骆熙华
2025-6-6 09:45:22
关注
0
粉丝关注
14
主题发布
板块介绍填写区域,请于后台编辑
财富榜{圆}
敖可
9984
杭环
9988
凶契帽
9988
4
氛疵
9988
5
黎瑞芝
9988
6
猷咎
9986
7
里豳朝
9986
8
肿圬后
9986
9
蝓俟佐
9984
10
虽裘侪
9984
查看更多