DDD 是如何解决微服务拆分的难题 2021-09-05 程序之旅,记录 暂无评论 964 次阅读 ## DDD 是如何解决微服务拆分的难题 将微服务落地到具体的业务中，真正的难题是`微服务按照说明原则拆分、如何拆分以及会面对哪些潜在风险` > 微服务的拆分原则--“小而专”即微服务内高内聚、微服务间低耦合 > > 微服务的高内聚：就是单一职责原则，将代码修改的范围缩小到这个微服务内 > > 微服务间低耦合：在微服务实现自身业务的过程中，如果需要执行的某些过程不是自己的职责，应当将这些过程交付给其他微服务去实现，你只需要对它的接口进行调用 通过 DDD 进行业务建模，再基于领域模型进行限界上下文划分，能保证系统的设计，在限界上下文内高内聚，在限界上下文间低耦合。 > 领域建模是将一个系统划分成多个子域，每个子域都是一个独立的业务场景，每个子域的实现就是“限界上下文”，它们之间的关联关系是“上下文地图”。 ### DDD 的微服务设计 - 按照限界上下文进行微服务的拆分，按照上下文地图定义各微服务之间的接口与调用关系 - 将领域模型划分到多个问题子域，每个子域都有一个领域模型的设计 - 基于充血模型与贫血模型设计各个微服务的业务领域层，即各自的 Service、Entity 与 Value Object - 按照领域模型设计各个微服务的数据库 例如下图  - “用户注册”时，调用“用户注册”微服务 - “用户选购”时，查询“饭店管理”微服务 - “用户下单”时，调用“用户下单”微服务 ### 领域事件通知机制 邻域事件通过消息队列实现领域事件在微服务间的通知。  ### 微服务落地的技术实践 作为顶级架构师应当巨白的核心能力 1. 能够将业务转换为技术 具备超强的业务落地能力，能够把用户的业务需求落地到技术方案 2. 能合理利用技术支撑业务 具备广博的知识与开阔的视野，能将用户的业务痛点快速落地形成合理的，甚至是最优的技术方案 ### 微服务接口 - 当多个团队都在向你提出AP接口时,你怎么提供接口？ 对这些接口进行规划,通过复用用尽可能少的接口满足他们的需求，这样做就能以更低的维护成本更好的维护自己的微服务。 - 当调用方需要接口变更时怎么办 变更现有接口应当尽可能向前兼容，即接口的名称与参数都不变,只在内部增加新的功能 - 调用双方传递的值对象需要完全一致吗 不用 - 调用方如何调用接口呢 - 异步调用：用户接单 Service”在完成下单后用消息队列通知“饭店接单 Service” - 同步调用：“用户接单 Service”通过同步调用“用户注册 Service”的相关接口 ### 数据管理查询的难题 在查询信息时，如果部分内容是其他表的数据，可以采用补填的方式进行数据关联，保证数据的完整，避免使用 join 的方式进行表查询。避免 join 操作，既解决了跨库关联查询的问题，又提高了海量数据下的查询效率。但是如果查询的过程中以其他辅表的字段作为查询条件，该如何处理？例如： 在查询订单时,如果要通过用户姓名、联系电话进行过滤，然后再查询时,又该如何设计呢？ 1. 提升海量数据的查询性能,适当增加冗余,即在订单表中增加用户姓名、联系电话等字段。 2. 当系统要在某些查询模块进行订单查询时，可能对各个字段都需要进行过滤查询，利用 NOSQL的特性,采用“宽表”的设计。 ### 总结 - 微服务间要通过 feign接口相互调用,数据要通过补填关联查询。 - 还有聚合的实现、仓库和工厂的设计。 打赏: 微信, 支付宝 标签: DDD, 邻域模型 本作品采用 知识共享署名-相同方式共享 4.0 国际许可协议 进行许可。
微信
支付宝