 微服务API设计：支持Swagger API规范  开发方式：支持透明RPC、Spring MVC风格的微服务开发  编程模型：同时支持同步、异步的编程模型  性能：支持原生的Reactive模式（EventLoop），相比于传 统的同步服务调用，性能更高（吞吐量N倍+提升、时延降低 为原来的50%-）  轻量级、易集成：可以方便的与Spring MVC、Tomcat等 已 业务熟悉的模式，可以更好的重用已有代码和开发经验，提升重构 效率 实践-同步和异步 Website: http://servicecomb.incubator.apache.org/ Gitter: https://gitter.im/ServiceCombUsers/Lobby 不一刀切，根据业务实际需要选择同步或者异步微服务调用 微服务消费端 业务 线程 池 异步 I/O线 程池 NIO异步通信 NIO异步通信 业务线程阻塞， 同步等待 唤醒等待的业务线程， 获取响应 1 2 微服务同步调用问题： 1、同步服务调用：业务线程将请求消息交给I/O线程之后， 无论I/O线程是同步还是异步发送请求消息，业务线程都会 同步阻塞，等待响应 2、异步I/O通信：I/O通信方式与服务调用方式没关联关 系，无论是同步服务调用还是异步服务调用，I/O通信都 可以采用异步非阻塞模式 同步服务调用的几个缺点：

Java Chassis通信处理详解 通信优化实践 议题  问题不挑战  整体线程模型  Consumer  Producer 问题不挑战 消费者 编程 模型 透明 RPC Spring MVC Transport Highway Vertx REST Servlet REST 生产者 编程 模型 透明 Reactive还是同步 ServiceComb的同步 仅仅是指编程模型上的同步，跟网络通信无关 因为所有场景下网络操作都是异步的 •Producer •Consumer 整体线程模型 Producer Consumer Eventloop 连接 Eventloop 连接 …… 业务线程 业务线程 业务线程 业务线程 Eventloops Eventloops Executor 线程 …… 线程 队列 Executor 线程 …… 线程 队列 …… Consumer 消费端，主要需要处理的问题是如何更 高效地将请求推送到对端去，然后拿到 应答信息。 透明RPC Consumer业务线程 Consumer Eventloop 连接 业务线程 hello.sayHello()

Producer 透明RPC JAX-RS SpringMVC 以契约为核心，贯穿始终 • 开发模式(业务代码)、治理、传输三方解耦，互不感知 • 以高性能的Reactive为基础，同时兼容传统的同步开发模式，且支持传统的Servlet传输 LoadBalance …… QPS Trace …… QPS 架构 Common Swagger Generator Invocation endpoints endpoints endpoints Endpoint RESTful Highway All ...... 微服务调用-consumer 透明RPC： 同步、异步声明，可以分开进行，也可以在同一个接口中声明 interface Schema { String hello(String name); } interface Schema { C hello") CompletableFuture helloReactive(String name); } RestTemplate AsyncRestTemplate 微服务调用-同步consumer Consumer Eventloop connection Queue/Buffer consumer thread synchronize invoke Handlers

vs webflux ServiceComb 的通信模型演进 启动更多的线程 Why？ Thread 2 Thread 1 Thread 4 Thread 3 进程1 Thread 2 Thread 1 Thread 4 Thread 3 进程2 核3 核1 核0 核2 集中到⼀个线程 ServiceComb 的通信模型演进—Reactor 黄金法则：不要阻塞Event 等待一个互斥信号或监视器（例如同步的代码块） n 执行一个长时间数据库操作并等待其结果 n 执行一个复杂的计算，占用了可感知的时长 n 在循环语句中长时间逗留 10000TPS=0.1ms处理一个请求 如果利⽤多核？ ServiceComb 采⽤Vert.x的背景 3 Vert.x vs webflux 同步 Reactive ServiceComb同步线程模型 ServiceComb嵌套同步线程模型 ServiceComb非阻塞线程模型 p 与传统流程不同的是，所有功能都在 eventloop中执行，并不会进行线程切 换 p 橙色箭头走完后，对本线程的占用即完 成了，不会阻塞等待应答，该线程可以 处理其他任务 p 当收到远端应答后，由网络数据驱动开 始走红色箭头的应答流程 p 只要有任务，线程就不会停止，会一直 执行任务，可以充分利用cpu资源，也 不会产生多余的线程切换，去无谓地消 耗cpu。

（OpenAPI） 服务发现 熔断 负载均衡 配置 跟踪 … 运行模型 围绕服务契约进行开发以及运维 异步化支持 • 基于Vertx提供的异步内核 • 保持高性能的同时支持同步调用方式 • 将通信线程与业务处理线程分离 • 操作级别线程池控制，支持隔离仓 • 支持多种异步编程接口 • CompletableFuture • RxJava • Reactive Stream • ……. Process 服务中心 多数据中心支持 契约测试 微服务管理控制 开源配置中心 对接多监控系统 Service Mesh 多语言微服务支持 监控管理对接 微服务事务协调器 服务端高可用 管理控制台 同步异步事件支持 如何加入到ServiceComb社区 • 线上 • 关注ServiceComb微信小助手， 加入微信群与大家进行交流 • 官网 http://servicecomb.incubator

微服务是大型系统的唯一选择。 解耦合 独立开发部署 架构、组织、流程 微服务架构定义“三步法” 微服务拆分方法 微服务拆分-指导原则 拆服务-单体重构的节奏 服务分解的四大障碍 1、网络延迟 2、同步通信降低了可用性 3、跨服务的数据一致性 4、上帝类 微服务的忠告 n 第一，要记住微服务不是解决所有问题的万能 “银弹”。 n 第二，编写整洁的代码和使用自动化测试至关重要，因为这是现代软件开发的基础。 还必须记住：实现微服务架构并不是你的目标。你的目标是加速大型复杂应用程序的开发。 --Chris Richardson 容错 故障和问题 线上故障“画像“ 系统稳定性指标 可监控设计 同步调用下-无线程池隔离 同步调用下-线程池隔离实现方法 快速失败-超时 快速失败-时间窗口 快速失败-超时重试次数 区分部署和上线 常规系统保障流程 没有不出问题的系统 什么是混沌工程 混沌工程 故障注入

不同的业务，涉及的不同的服务间通信有不同的要求 1. 关注事务性要求（ACID） 2. 关注对性能的要求 举例：客户维护和订单是2个微服务，订单系统对性能有较高要求，所以可以考虑把购房资格信息从客户维护微服务同步到订单系统，改同步动作 对性能没有要求，对事务性有要求。 常见的服务间通信模式：同（异)步通信，API组合，基于MQ的异步通信 事务性： saga, 事务性消息发布（一次仅一次），分布式事务等 很易用的 Login House- order Realestate User- Center Customer-db Order-db Login-db Redis Redis Gateway Saga同步qualification 1. 每个微服务对应自己数据层 2. 拆分经验：看业务，不看技术 3. 利用：saga, 事务性消息发布，最终一致性，同（异）步调用组合等微服务模式 [社区网站] http://servicecomb [Github ] https://github.com/apache?q=servicecomb 其他优化… 步骤3 其他优化： 1. 可以使用JMeter集群进行压测，不断调优，每台最高约1250 线程, 同时发请求。JMeter 需要调高 Xmx / Xms。 2. 需要迅速伸缩，用了docker-compose。 注意NAT的性能问题。 启发：不一定要K8s，Istio， 一定是需求驱动。

跟踪 … 运⾏行行模型 围绕服务契约进⾏行行开发以及运维 异步化⽀支持 • 基于Vertx提供的异步内核 • 保持⾼高性能的同时⽀支持同步调⽤用⽅方式 • 将通信线程与业务处理理线程分离 • 操作级别线程池控制，⽀支持隔离仓 • ⽀支持多种异步编程接⼝口 • CompletableFuture • RxJava • Reactive Stream • ……

Microservice NO.1 深圳站： Cloud Native 架构下的 K8S 和微服务实践 异步性能支持 • 基于Vertx提供的异步内核 • 保持高性能的同时支持同步调用方式 • 将通信线程不业务处理线程分离 • 操作级别线程池控制，支持隔离仓 • 支持多种异步编程接口 • CompletableFuture • RxJava • Reactive Stream • …….

无论是华为内部的DSF，还是开源的Netflix、Spring Cloud等，都无法完全满足业务的 选型诉求，而CSE则能够很好的满足我们的需求  仔细阅读了CSE的主要模块代码，包括网络通信、线程调度模型等，代码质量非常高， 对细节的把握比较好  选型试用时，大家对CSE的接受度比较高，使用CSE改造已有的Spring MVC代码相对较 容易些  华为内部的平台，无论是新需求 底层基于Netty，性 能比传统Servlet NIO性能高X倍  Highway RPC：采用Netty + PB，既支持多语 言，又保证高性能  高性能幵发设计：线程绑定技术，网络I/O线程 绑定后端的服务调度线程，最大限度减少锁竞 争。采用连接池机制，重用已有的连接 CSE在消费者云业务的实践-分布式事务 1、服务化乊前本地事务： 2、服务化乊后引入分布式事务：