微服务技术拆分最佳实践

1、过早拆分微服务是万恶之源微服务技术拆分最佳实践目录微服务架构简史1为什么不要过早拆分2如何设计真正的微服务3结语：过早设计是万恶之源4 软件系统腐化问题 企业组织结构和系统架构演进 单体架构的优点和问题用户展现层业务逻辑层数据访问层项目初始易于开发 易于部署 易于测试项目演进微服务的哲学原理 微服务的难点 微服务的误解微服务。构建轻量的RESTful API，这是微服务。有很多框架声称是微服务框架。使用这些框架的任意一种 来构建应用程序，这就是微服务。构建HTTP服务，使用Docker容器运行它，并且使用Kubernetes做集群管理，这就是微服务。使用API Gateway和服务发现以及服务

2、registry，这就是微服务。使用Spring Boot框架构建HTTP服务，并且使用NetflixOSS，这是微服务。使用Azure Service Fabric构建并会且运用行工应用具程序不，这代是 表理解 微服务架构的精髓和意图微服务的特征通过服务进行组件化围绕业务能力组织做产品而不是做项目智能端点与傻瓜管道去中心化地治理技术去中心化地管理数据基础设施自动化容错设计演进式设计 目录微服务架构简史1为什么不要过早拆分2如何设计真正的微服务3结语：过早设计是万恶之源4 很难界定微服务的边界主要的原因：现实世界中，一个名词会在不同场景下出现，很难确定它的边界是什么 合并微服务比拆分成本更高3

3、 Months2 Microservices12 Months10 Microservices18 Months60 Microservices 处理代码冲突修改上下游依赖重新设计部署架构现实世界中企业设计微服务的关注点这样拆合理吗? 我们拆出来30个微服务，够微吧为啥做这个业务，两个服务之间发了20次API请求需求是持续变化的，架构要响应变化1、“我只不过提一个 新的小需求，你们2 个月时间才弄出来， 反应太慢市场机会都 弄丢了！”2、“我们也没办法， 你这个功能要改5个 相关的微服务，新 功能能弄出来已经 不错了”3、“那其他功能 怎么也不好用了？”4、“微服务太多了， 没人能搞清楚架构。

4、 至于新BUG我们再 排查一下，但是需要 时间” 业务人员技术人员VS小心把微服务做成小单体假设你的系统已经进行了“ 微服务” 改造，由于你的业务发展的很快，新需求像潮水一样涌来。某些“ 微服务 ” 开始慢慢的膨胀起来，有一天你发现膨胀的“ 微服务” 有一部分业务能力需要拆分出去，但这个服务内部过度耦 合的实现让你已经无从下手，这就和当年“ 微服务” 改造前的单体一样。这是因为你构建的不是微服务而是小单体系统膨胀微服务改造 每个“微服务”都演变成一个小单体微服务边界不清 服务之间无法解耦目录微服务架构简史1为什么不要过早拆分2如何设计真正的微服务3结语：过早设计是万恶之源4 好的微服务设计，没

5、那么简单 如何确保微服务之间低耦合？如何确保微服务内部高内聚？ 如何确保微服务的职责清晰？ 如何控制微服务系统复杂度？ 如何DDD是微服务设计的最佳实践从本质上来看，作为一种设计思想的DDD和作 为一种架构风格的微服务，都要求我们从业务 视角去分离复杂度，最终目标都是为着追求高 响应力!在社区内DDD已经是公认的微服务设计最佳实践。 DDD的核心诉求让业务架构和系统架构形成绑定关系，从而当我 们去响应业务变化调整业务架构时，系统架构的 改变是随之而发的绑定 TADDD原则：聚焦核心域 DDD原则：通过协作探索模型传统模型设计，庞大的设计基于所有未来的假设需求 迭代探索模型，根据需求的变化不断演

6、进模型DDD原则：统一语言 DDD和微服务对应关系支付子域支付限界上下文支付聚合账户聚合日志聚合支付微服务 当服务需要拆分时支付微服务账户聚合 日志聚合 发布 支付已提交事件 订阅 支付已提交事件 支付聚合 事件发布器事件发布器 支付微服务账户微服务 操作日志微服务发布 支付已提交事件 订阅 支付已提交事件 目录微服务架构简史1为什么不要过早拆分2如何设计真正的微服务3结语：过早设计是万恶之源4 微服务架构的核心收益基于聚合构建系统，聚合可以和业务一一对应 微服务架构简史系统服务化和演进 微服务的哲学原理 微服务的难点和误解 微服务的特征为什么不要过早拆分难以界定服务的边界 合并比拆分成本更高 架构要持续演进小心把微服务做成小单体真正的微服务DD