Meetup 联合发起⼈人 • 《消费者驱动契约测试-Pact》译者 • 《使⽤用SpringBoot/Cloud构建微服务》视频作者(StuQ) 微服务架构与DDD 领域驱动设计的核⼼心 基于事件⻛风暴暴的DDD实践 01 02 03 �4 什什么是微服务架构 微服务架构 �5 Martin Fowler, Mar 2014 Microservices - the new architectural 微服务架构与领域驱动设计 • 能有效指导服务的设计与划分 基于领域驱动设 计，能有效识别 业务模型/业务上 下⽂文。从业务⻆角 度指导服务拆分。 微服务架构与DDD 01 领域驱动设计的核⼼心 02 基于事件⻛风暴暴的DDD实践 03 领域驱动设计的核⼼心 1.建⽴立统⼀一语⾔言 2.建⽴立领域模型 3.识别依赖关系 4.细分界限上下⽂文 将业务架构和系统架构对应起来，建⽴立针对业务变化的⾼高响应⼒力力架构 Infrastructure • 数据相关部分：WebService/DB/File • ⽀支撑相关部分: 环境相关配置 Onion架构 微服务架构与DDD 01 领域驱动设计的核⼼心 02 基于事件⻛风暴暴的DDD实践 03 如何落地领域驱动设计？ Vaughn Vernon Eric Evan Event Storming是⼀一种快速探索复杂业务领域的⽅方法： Event Storming

每个微服务实例注册到服务中心， 并与服务中心保持心跳 • 消费者周期性从服务中心更新目 标微服务实例集合 • 微服务实例与服务中心之间的如 果成功建立WebSocket连接，则服 务中心会将目标实例变更事件尽 快推送给相关的消费者 服务发现-LoadBalance 1.将从服务中心取得的实例集合，进行过滤，得到 Endpoint集合 • 根据兼容规则，将实例进行分组 只有edge service场景下，对于同一个目 complete Edge Service • 作为整个微服务系统对外的接口，向最终用户提供服务，接入RESTful请求，转发给内 部微服务 • 基于ServiceComb标准consumer流程转发请求到内部微服务，所有consumer治理能力， 不必独立开发，直接重用 ELB Edge Service Backend ...... Edge Service ...... Backend Edge 0的微服务 如果内部微服务URL规则为： /{microserviceName}/{v1/v2/......}/pa th 则可以配置为 servicecomb: http: dispatcher: edge: default: enabled: true prefix: rest withVersion: true prefixSegmentCount: 1 如果内部微服务URL规则为：

>大量关联查询 >系统架构复杂度提升 Huawei Confidential 6 通过微服务拆分工具解放开发者 支撑活动 方法论 • ThoughtWorks五步十一阶 • DDD聚合 • 事件源Event Sourcing • 命令查询责任分离CQRS 现有做法 业务改造 投入大 + 应用上云 + IaaS 应用微服务改造 + PaaS 业务创新 如AI 拆表 拆界面及业务逻辑 成表关联关系加权图 Step6：采用图切割算法并配合启发式规则将表分 割到不同库中 原则：低耦合，高内聚 耦合度：微服务划分后，微服务与微服务连接的边的权重之和 内聚度：微服务划分后，微服务内部表与表之间的边权重之和 采用图搜索算法划分微服务的启发式规则(规则可自定义)： 规则1：贪婪原则 规则2：完全独立的表可归属任意微服务，也可独立成微服务 规则3：归属同一微服务的表数量不低于5（作为参数可配置）

（Orchestration-based coordination） • 集中式协调器器负责服务调⽤用以及事务协调 • 分布式的实现⽅方式 （Choreography-based coordination） • 通过事件驱动的⽅方式来进⾏行行事务协调 http://microservices.io/patterns/data/saga.html 集中式Saga实现 http://microservices.i B Omega Alpha Alpha • Alpha是狼群⾸首领，负责协调事务执⾏行行情况 • Omega是狼群成员，负责收集事务，向狼群⾸首领上报情况，并执⾏行行相关指令 Omega 内部实现 Pre Processor Post Processor Transaction DB Request (Tx id) Request Interceptor Build TxContext

支持多种Rest服务实现方式 Process Event-Loop Process R R W W 线 程 池 • 框架以事件驱劢为基础 • 异步操作提升应用处理效率 • 支持Restful以及RPC 异步事件操作保证系统性能 分布式调用追踪 • 支持标准追踪协议 • Zipkin • 支持@span扩展事务追踪 • 提供调用追踪扩展

基于Pack模型的新构架 由 Alpha 和 Omega组成 •Alpha充当协调者的角色，主要负责对事务的 事件进行持久化存储以及协调子事务的状态，使 其最终得以与全局事务的状态保持一致，即保证 事务中的子事务全执行，或全不执行。 •Omega是用户程序侧代理，负责对网络请求 进行拦截并向Alpha上报事务事件，并在异常情 况下根据Alpha下发的指令执行相应的补偿或重 试操作。 Service A Omega

DNS-F在数据 库场景的落地 名字服务在负 载均衡场景的 落地 DNS-F在微服 务场景的落地 应用层探活 数据库故障 恢复时间长 服务故障牵 引慢，流量 接入生效时 间长 DNS生效慢 内部服务无 就近接入能 力 服务性能下 降流量不摘 除 实 例 切 换 能 力 秒 级 流 量 牵 引 能 力 D N S 就 近 接 入 能 力 异 常 摘 除 能 力 dmx dns-f 微服务架构中基于DNS的服务注册与发现 背景 公司内部注册中心比较多，常见的有zookeeper、 ectd、consul、eureka等。服务注册通常有三种： 自注册、第三方注册、注册中心主动同步，异构微 服务相互调用困难；公共DNS不稳定，解析结果生 效慢，解析失败率高；DNS无法提供内网环境的就 近接入能力，内部服务调用无法实现就近访问。 目标 DNS解析成功率 100% 公共DNS分钟级生效 内部DNS秒级生效 基于IP+CMDB实现就近访问能力 数据库模拟消息队列，Apollo定时 读消息 HTTP异步通知 单机读（tps） 9000 15000 单机写（tps） 1100 1800 技术选型 • Dubbo生态产品， Nacos源于阿里内部服务的开源实现； • 支持各种生态环境， 支持k8s， spring cloud， dubbo， service mesh等集成； • 配置中心与注册中心原生打通； 落地的改造和升级 Nacos

e Mesh服务商⽤用上 线公有云 • 简介 • 实现⼀一个Service Mesh • 使⽤用Service Mesh快速构建微服务 • ⽣生态与扩展 • Service Mesh在华为内部的技术演进 我们在构建微服务，⽽而构建微服务是困难 的 微服务架构模式引⼊入的问题 路由规则 • 引流 • ⽀支持权重 • 根据消费者信息或请求特征进⾏行引流 Consumer 0.2 • 实现⼀一个Service Mesh • 使⽤用Service Mesh快速构建微服务 • ⽣生态与扩展 • Service Mesh在华为内部的技术演进 第⼀一代：基于Nginx的微服务代理 • 2013年,微服务开发平台中的组 件，公司内部某电信业务 • 400多个微服务，800左右实例， 200多个数据中⼼心 Sidecar模式 • 基于容器的分布式系统设计模式 • 容器可以共享存储与⺴⽹网络的能⼒力 0多M） • 简介 • 实现⼀一个Service Mesh • 使⽤用Service Mesh快速构建微服务 • ⽣生态与扩展 • 与PaaS平台结合 • Service Mesh在华为内部的技术演进 整体架构 Mesher Service Mesher Service Mesher Service Mesher Service Mesher Service Mesher

导致整个提交流⽔水线堵塞，测 试⼈人员⽆无法拿到新的版本，交 付延期 4 团队出现冲突，架构腐化严重 交付不能完成导致各⾓角⾊色间的 冲突越来越严重，为了快速上 线质量遭到牺牲。架构⽆无⼈人守 护，各种不⼀一致性，服务内部 接⼝口⼀一⽚片混乱，核⼼心⼈人员离 职。 2014年问题倍出（⼆二） 不要再添加任何服务！ 当然不是！ 业务迅速扩张 技术选型灵活 助⼒力客户快速占领市场 那怎么办？ 2015年服务治理 导致整个提交流⽔水线堵塞，测 试⼈人员⽆无法拿到新的版本，交 付延期 4 团队出现冲突，架构腐化严重 交付不能完成导致各⾓角⾊色间的 冲突越来越严重，为了快速上 线质量遭到牺牲。架构⽆无⼈人守 护，各种不⼀一致性，服务内部 接⼝口⼀一⽚片混乱，核⼼心⼈人员离 职。 部署成功率很低，部署时经常 有⼀一堆环境修改需求，运维⼈人 员出错机会增加，运维效率极 低。 ⽆无法快速有效定位问题，⽆无法 快速有效知晓服务运⾏行状态， 导致整个提交流⽔水线堵塞，测 试⼈人员⽆无法拿到新的版本，交 付延期 4 团队出现冲突，架构腐化严重 交付不能完成导致各⾓角⾊色间的 冲突越来越严重，为了快速上 线质量遭到牺牲。架构⽆无⼈人守 护，各种不⼀一致性，服务内部 接⼝口⼀一⽚片混乱，核⼼心⼈人员离 职。 部署成功率很低，部署时经常 有⼀一堆环境修改需求，运维⼈人 员出错机会增加，运维效率极 低。 ⽆无法快速有效定位问题，⽆无法 快速有效知晓服务运⾏行状态，

reservation)机制保证 了Provider端与ServiceCenter在出现网络分区故障时依然保持业务可用。 ServiceCenter在一个时间窗内监听到etcd有80%的实例下线事件，会立即 启劢自我保护机制。即使etcd存储的数据全部丢失，这种极端场景下， SDK与ServiceCenter之间可在不影响业务的前提下，做到数据自劢恢复。 虽然这个恢复是有损的，但在这种灾难场景下还能保持业务基本可用。