微服务架构与领域驱动设计 王磊磊 华为 - 2012技术专家 ThoughtWorks - Lead Consultant Sybase - Tech Leader �2 关于我 • 丰富的持续交付/微服务架构/DevOPS经验 • 《微服务架构与实践》作者 • 《DevOps实践指南》译者 • 中国⾸首批EXIN DevOps Master教练 • ⻄西安DevOps ⻄西安DevOps Meetup 联合发起⼈人 • 《消费者驱动契约测试-Pact》译者 • 《使⽤用SpringBoot/Cloud构建微服务》视频作者(StuQ) 微服务架构与DDD 领域驱动设计的核⼼心 基于事件⻛风暴暴的DDD实践 01 02 03 �4 什什么是微服务架构 微服务架构 �5 Martin Fowler, Mar 2014 Microservices - the 什什么是领域驱动设计 领域驱动设计 �8 领域驱动设计解决的两个核⼼心问题： 1.业务架构如何合理理的设计划分？ 2.技术架构与业务架构保持⼀一致？ 领域驱动设计是⼀一种设计⽅方法，围绕业务概念构建领域模型， 并通过分离技术实现的复杂性，从⽽而控制软件演化的复杂度。 Tacking Complexity in the heart of software �9 微服务架构与领域驱动设计？

1 ServiceComb设计揭秘：标准与开发 华为CloudBU PaaS微服务引擎开发团队 代码阅读 • 一、系统架构解读 • 二、系统模块解读 • 三、框架的启劢不停止 • 四、框架运行时请求发送不处理过程 ServiceComb 开发框架 通信模型 (restful、 highway） 编程模型

反应式微服务框架 Apache ServiceComb设计思想 王启军 华为云 IoT⾸席架构师 王启军，华为云IoT首席架构师，曾担 任PaaS团队架构师，负责微服务框架 的开发。曾任当当网架构师，主导电 商平台架构设计；曾就职于搜狐负责 手机微博的研发。《持续演进的Cloud Native》作者，微信公众号“奔跑中 的蜗牛”博主。 p为什么微服务框架需要 Reactive 与传统流程不同的是，所有功能都在 eventloop中执行，并不会进行线程切 换 p 橙色箭头走完后，对本线程的占用即完 成了，不会阻塞等待应答，该线程可以 处理其他任务 p 当收到远端应答后，由网络数据驱动开 始走红色箭头的应答流程 p 只要有任务，线程就不会停止，会一直 执行任务，可以充分利用cpu资源，也 不会产生多余的线程切换，去无谓地消 耗cpu。 压测数据 系统: Ubuntu 18 com/GuoYL123/ReactiveBenchmark 调优后的压测数据 n 寻找拐点 n 调整consumer/producer参数（网络线程/业务线程等），提升处理能力 n 重新调整测试驱动压力（加大或减小），重复前面步骤 n 输出最终性能拐点时的各项参数，包括TPS/时延/CPU/带宽等等 Spring Cloud Gateway VS Zuul VS EdgeService 3

微服务的设计原则 与⽣生态系统 王磊磊 华为公司技术专家 ThoughtWorks⾸首席咨询师 Sybase Tech Leader • 《微服务架构与实践》作者 • 《DevOps Handbook》中⽂文译者之⼀一 • 国内较早倡导和实践微服务的先⾏行行者 • 对于⾃自动化测试、持续交付、DevOps有丰富的实践经验 • ⻄西安DevOps Meetup 联合发起⼈人 联合发起⼈人 关于我 议题 • 微服务架构的核⼼心 • 微服务架构设计原则 • 微服务架构⽣生态系统 Are you using microservices? Are you using microservices? https://www.nginx.com/resources/library/app-dev-survey/ 什什么是微服务架构？ • 微服务架构是⼀一种架构模式， - 运维意识是关键 架构只是抽象，直到真正投⼊入运维产⽣生价值 议题 • 微服务架构的核⼼心 • 微服务架构设计原则 • 微服务架构⽣生态系统 It is about architecture， BUT not only architecture…… 微服务架构的设计原则 • 竞争能⼒力力平衡 • 围绕业务构建 • “去”中⼼心化 • ⾃自动化“⼀一切” 没有完美的架构，只有适合的架构

一致性方案的选择建议 ? ??? ???? ? ?? ? ? ? ?? 一致性方案的选择建议 • 微服务内：聚合通过数据库事务保证强一致 内刚 • 微服务间：最终一致 外柔 微服务架构与领域驱动设计 • if our service boundaries align to the bounded contexts in our domain, and our microservices start in ensuring that our microservices are loosely coupled and strongly cohesive. 微服务：限界上下文 领域驱动设计是微服务系统架构的最佳指南 聚合与数据一致性 • A properly designed Aggregate is one that can be modified in any way 微服务：限界上下文 • 聚合边界：强一致边界 • 限界上下文 -> 1 .. N 聚合 微服务内：聚合通过数据库事务保证强一致 微服务间：最终一致 如果需要分布式强一致，先考虑设计是否合理而非追求最新技术 合理的设计能大大减少技术复杂度和商业成本 总结 • 起因：离 • 方案：Saga 222 • 选择建议：内刚 外柔 未来的开发计划 • 更易使用的数据一致性方案 • 集成调用链追踪 (Zipkin)，定位性能瓶颈

50+ 正在孵化的项目 • 组织前身是 1996年成立的 Apache Group • ASF成立于 1999年 Apache软件基金会 涉猎领域 • 人工智能AI • IoT • 大数据 • 金融管理 • 区块链 • …… 未涉猎领域 • 机器人 • 自动驾驶 • 星际探索 • 也有可能是你的项目 [社区网站] http://servicecomb.apache.org • 完成新功能设计，发送邮件进⾏讨论 • 编码，修复集成测试发现的问题 • 北美同事上线， IRC交流 • 回复邮件 [社区网站] http://servicecomb.apache.org [Github ] https://github.com/apache?q=servicecomb • 放羊式管理 • 完成商业服务支持 • 自由选择工作内容 • 邮件驱动开发的方式 如何安排开源事务 可以帮助我解决工作中的实际问题 • 视野/人际关系拓展  可以和一群志同道合的人一起成长  可以让我和世界级的开发者一起工作 • 个人品牌建立  可以使我的工作会被更多人看到  可以发挥我的专长在专有领域有所建树 • 更多的职业发展选择  可以让我找到更好的工作或者更喜欢的工作 [社区网站] http://servicecomb.apache.org [Github ] https://github

决策子项目 需求和方向 负责整体孵化项 目决策及投票 提议Committer 候选人及孵化器 候选项目 管理与监督基金会 商务与日常事务 • 涉猎领域  人工智能AI  IoT  大数据  金融管理  区块链  …… • 未涉猎领域  机器人  自动驾驶  星际探索  也有可能是你的项目 • 注册在美国的非盈利组织 • 提供法律和基础设施的支持 • 完全的自愿组织，虚拟的全球化组织 apache.org [Github ] https://github.com/apache?q=servicecomb • 放羊式管理 • 完成商业服务支持 • 自由选择工作内容 • 邮件驱动开发的方式 如何安排开源事务 [社区网站] http://servicecomb.apache.org [Github ] https://github.com/apache?q=servicecomb 可以帮助我解决工作中的实际问题 • 视野/人际关系拓展  可以和一群志同道合的人一起成长  可以让我和世界级的开发者一起工作 • 个人品牌建立  可以使我的工作会被更多人看到  可以发挥我的专长在专有领域有所建树 • 更多的职业发展选择  可以让我找到更好的工作或者更喜欢的工作 [社区网站] http://servicecomb.apache.org [Github ] https://github

q=servicecomb 微服务创新新品发布 马彬 2019 2 github.com/apache?q=servicecomb servicecomb.apache.org 在同一个业 务领域的微 服务中使用 了多种不同 语言进行开 发部署 使能多微服 务技术栈开 发的微服务 应用之间协 同工作和共 同治理 使能满足第三 方认证被广泛 采纳的趋势下 认证鉴权的性 能和安全的要 求 Syncer是一个多服务中心的同步工具，专为大型微服务架构设计，实现不同的微服务技术栈实现的微服务业务可以进行数 据通信，未来可支持跨云的数据通信支持。 •对应用程序透明。同步工具启停，不应该对应用程序的原有流程产生影响。 •为多服务中心提供对等网络。他们之间是松耦合的，成员可以自由加入与退出。 •对异构服务中心提供支持。插件化的形式支持多种服务中心驱动，用户可便捷的接入自定义插件。 gossip 协议 getUser.timeout=10s -在这样的数据格式设计下可生成多角度的配置视图，提升易用性，人类可读性 假如说我们要定义A到B以及到某个API的超时时间 -学习成本高，运维人员要学习这个只在团队内部生效的key规则 -所有的key集中在一种类型的视图中管理，管理成本高。 -不断增长的规则定义，越来越复杂，人类不可读。 -Key设计无法扩展变更，没法轻易变更数据结构 分布式系统配置中心

2014年⿊黑暗时代 2015年服务治理 2016年新的征程 背景介绍 业务系统B 业务系统A 2012年新的需求 领域服务 业务系统B 业务系统A 模块A 模块B 模块C 重⽤用服务 模块A 模块B 模块C 新的业务系统A 模块D 重复？ 领域服务 服务A 服务B 服务C 服务D 业务系统A Librarian 业务系统B 服务E 服务F 微服务架构初步形成 微服务架构初步形成 那时的微服务 系统集成消除重复 ful API Restful API ⾃自动 化部署 特性 团队 它给我们带来了哪些好处？ 新业务C三个⽉月上线 领域服务 服务A 服务B 服务C 服务D 服务E 服务F Librarian 业务系统B 业务系统C 服务G 服务H 业务系统A 你是我们⻅见过最棒的团队！ 更多服务更快⼀一点？ 服务越来越多，周期越来越短 设计⼀一个系统的任何组织所产⽣生 的设计和架构都等价于其组织间的 沟通结构。 —Melvyn Conway, 1967 康威逆定律 逐渐改进你的团队和组织结构 来促进你所渴望的软件系统架构。 —Sam Newman • 服务足够小  • 独立运行  • 轻量级通信机制  • 独立的部署  • 去中心化 微服务架构特性 API设计指导原则 容错性

Confirm：确认执⾏行行业务 • 真正执⾏行行业务，不不做业务检查 • Cancel：取消执⾏行行业务 • 释放Try阶段预留留的业务资源 业务服务 try confirm cancel 通过领域建模来解决 • 微服务内：聚合通过数据库事务保证强⼀一致 • 内刚 • 微服务间：最终⼀一致 • 外柔 微服务事务⼀一致性建议 • 1987年年Hector & Kenneth 发表论⽂文 （Orchestration-based coordination） • 集中式协调器器负责服务调⽤用以及事务协调 • 分布式的实现⽅方式 （Choreography-based coordination） • 通过事件驱动的⽅方式来进⾏行行事务协调 http://microservices.io/patterns/data/saga.html 集中式Saga实现 http://microservices.io/patterns/data/saga