简介： 本文整顿自作者于 2020 年云原生微服务大会上的分享《携程微服务框架实际及思考》，次要介绍了从携程自研框架遇到的问题，转到落地 Dubbo 微服务框架，携程是如何实际的，以及实际过程中遇到的问题；将来转型 service mesh 的路线上，dubbo 协定存在的问题，咱们须要怎么样的协定层以及微服务 SDK 的定位。

作者 | 顾陆地  携程框架架构研发部技术专家

导读：本文整顿自作者于 2020 年云原生微服务大会上的分享《携程微服务框架实际及思考》，次要介绍了从携程自研框架遇到的问题，转到落地 Dubbo 微服务框架，携程是如何实际的，以及实际过程中遇到的问题；将来转型 service mesh 的路线上，dubbo 协定存在的问题，咱们须要怎么样的协定层以及微服务 SDK 的定位。

阿里巴巴云原生公众号后盾回复 818 即可获取直播回看地址和大会 PPT 合集。参加文末互动，还有机会得《携程架构实际》一书！

携程从 .Net 技术栈的时代就曾经开始微服务畛域的摸索，转入 Java  技术栈之后，更是经验了自研微服务框架，到当初高性能的 dubbo，目前咱们正在 Service Mesh 的路线上摸索，心愿可能实现微服务框架的全面标准化、以及云原生。

过来(自研服务框架)

携程从 .Net 技术栈开始，最开始是基于 ESB 总线，尽管解决了内网服务调用的治理问题，然而集中式的服务架构，常常会呈现单个服务把整个总线拖垮的状况，进而导致全网瘫痪的景象。基于注册核心的 SOA 服务架构，通过分布式的服务调用，解决了单点故障带来的微小影响。目前，携程次要是以 Java 技术栈为主，思考到兼容历史 .Net 技术栈，所以当初的框架以自研为主，然而比照开源的高性能服务框架，自研的框架可能又存在下述提到的几个问题。

当初(CDubbo 服务框架)

CDubbo 名字里的 C 代表携程的治理，Dubbo 代表阿里开源的 Dubbo SDK。纵观过来两年的实际和摸索，从 2018 年 4 月的第一个版本落地，到当初的近万服务实例，咱们大抵能够总结为上面的几个次要里程碑。

1. 注册发现

注册发现是分布式服务框架的外围因素，为了反对现有的服务互通，所以须要接入携程的注册核心。

服务注册反对衰弱检测扩大机制，业务能够依据业务场景自定义衰弱检测扩大，例如当依赖的数据库不可用时不再对外提供服务。服务端通过 5s 一次的心跳放弃服务的可用性，当间断 N 次没有发送心跳时就会主动告诉客户端。

客户端发动对服务的订阅，通过推拉联合的模式，保障节点在客户端的最终一致性。通过 Dubbo 的扩大机制，实现了自定义的路由策略，比方依据办法名指定路由策略，以及依据申请参数决定不同的路由策略，同时也可能反对就近拜访，优先拜访本机房的服务。

2. 监控 – CAT

对微服务来说，没有了监控就好比瞎子一样，什么也不分明。CAT 提供了分布式链路追踪的能力，能够提供很好的报表，以及场景化的问题剖析。

有时，须要理解服务总的申请量以及单机的申请散布和 QPS，或者还要晓得服务的执行耗时及 99 线。CAT 的聚合报表能够帮忙咱们更好的理解服务的健康状况。

对于超时，可能须要晓得哪个阶段变慢，客户端还是服务端，序列化阶段还是服务执行过程太慢。对于异样报错，能够看到哪个过程呈现的异样，同时会打印异样堆栈信息，帮忙问题的定位。

3. 监控 -Metrics

框架人员须要理解公司服务的宏观状况，比方各机房都有哪些服务，哪些服务应用了 protobuf 序列化格局，哪些服务应用了 SOA 协定等，以及均匀执行耗时等状况。业务共事可能也想晓得本人服务具体情况，比方有哪些调用方，线程池是否曾经跑满了。

通过接入携程的 Dashboard，能够提供全局的总量、谬误量、线程池统计信息，也能够依据机房、协定、序列化格局等聚合数据。还可能自定义告警规定，在问题产生时可能尽早的染指。

4. 动静配置

对业务共事来说，有可能会存在依赖的服务忽然变慢导致客户端超时的状况。框架人员可能须要在机房故障时，须要全局调整 check 为 false，以解决 A B 服务循环依赖谁都无奈启动的问题。动静配置提供了配置热失效的能力，不须要为了一个配置从新公布，老本很高。

服务端的多个办法，可能执行耗时也会有所不同，通过多级别的参数配置，能够设置服务默认超时为 1s，独自为执行较慢的办法设置独立的超时工夫为 5s。

服务 Owner 可能更分明本人服务的耗时，通过服务端对客户端的参数设置，不须要每个调用方都设置一次超时，设置的工夫也会更正当一些。为了防止配置出错带来的损失，咱们提供了敌对的可视化界面。

5. SOA 协定及互通

为了反对现有客户端迁徙到 CDubbo，须要思考反对现有的 SOA 协定。除了要确保兼容 HTTP 1.1 协定不变，其次要保障跟客户端的序列化器统一。

CDubbo 会通过 Tomcat 端口接管 SOA 协定的申请，利用现有的序列化器执行申请对象的转换，并保障 Dubbo 外部调用和 Filter 链路的一致性，确保业务逻辑的对立，也就是业务代码不须要改变，就能够启动两个协定。

6. 测试平台

对于公有的二进制协定来说，没有现成的 Postman 等工具能够应用。有时，开发人员须要在本地验证测试环境的服务，也可能要验证本地启动的服务端，每个开发人员都结构一个客户端显得老本比拟高。

通过 VI(github 开源叫 coreStone)，以及利用 Dubbo 2.7.3 提供的元数据中心和泛化调用能力，咱们实现了相似 postman 的调用工具。岂但能够反对直连，也可能反对本地测试，同时还能够反对 protobuf 序列化格局。对于 protobuf 序列化的测试计划，曾经奉献到 dubbo 社区，感兴趣的同学能够自行理解。

7. 降级 Dubbo 2.7.3

对于 Dubbo 2.7.3 的具体降级历程，能够参考：https://www.infoq.cn/article/kOxdaV3y9fMZ0Bzs0jb2

当初回顾下降级的最终后果如何。目前，携程 99% 的服务曾经跑在 dubbo 2.7.3 之上，迄今为止 0 故障，只有一些不兼容的小问题，对于不兼容的问题也是确保了编译时提前裸露，运行时没有任何问题。

在公布后，也陆续的呈现了一些小的问题，比方预热能力不失效，异常情况下不会回调 onError 等问题，反对服务端异步的 Trace 埋点等，这些问题曾经在开源版本彻底修复了。

8. Threadless

业务共事反馈，须要把线程管制在现实的范畴之内。然而，dubbo 的线程数量太多，一方面是服务级独享线程池，当调用方依赖了 10 个服务，每个服务的 QPS 为 1，lantency 可能只有 10ms 的状况下，因为每个服务独立线程池，至多也须要 10 个线程了。如果多服务共享一个线程池，因为客户端默认是 Cached 的线程池模式，那么在这个场景下可能只有 1 个线程就足够了。另一方面，对同步服务来说，dubbo 2.7.5 的 threadless 能够省去 DubboClientHandler 线程，Netty IO 线程间接把响应交给业务线程，从而节俭了一次线程切换。

通过实际，业务线程数量有了很大水平的降落，在高 QPS 以及依赖服务数量较多的状况下，甚至能够降落 60-70%。

9. CDubbo 服务体系

现有 CDubbo 的服务体系，同时反对 Dubbo 和 SOA 协定，对于 Dubbo 客户端可能反对 TCP 协定的传输，对于现有的 SOA 客户端，可能兼容现有的 SOA 协定。

同时，也可能反对内网和外网 gateway 的申请，保障了多协定的配置对立，以及兼容了 SOA 的序列化格局。

10. 性能体现

从协定层面来看，Dubbo 协定的响应较 SOA 协定有所晋升，均匀耗时从之前的 1ms 升高到了 0.3ms 左右，当然具体晋升也要依据服务的报文及申请量有所差别。

可能有些人会感觉几毫秒的性能晋升不足以挂齿，然而性能的稳定性对服务来说会很重要。咱们察看了服务流量突增 3-4 倍的状况下，客户端还能放弃 0 异样。长连贯的多路复用，提供了很好的抗冲击能力。

11. 扩展性

微服务框架跟业务代码耦合比拟重，框架人员次要是用 20% 的工夫解决业务 80% 的需要，另外 20% 的需要却须要 80% 工夫的问题，更适宜留给业务本人去解决，可能提供这个能力的唯有扩展性，dubbo 无论横向和纵向的扩大能力都很好。

通过实际，发现业务确实在各个层级都有本人的扩大。例如：业务扩大了 Router 层，反对本人的路由规定，扩大了负载平衡策略，机票共事甚至扩大了 Transport 层换成了适宜本人的传输协定。

12. 生态

好的生态，能够升高开发成本，例如利用现有的开源 dubbo admin，dubbo go 等组件。另外，也能够升高业务的学习老本，在其余公司学习的 dubbo 框架，到了携程还能够接着用，不须要重新学习公有的服务框架。技术支持也比拟少，很多业务共事甚至比咱们还相熟 dubbo 框架。

13. Dubbo 协定现有问题 & Dubbo 3.0 布局

除了后面提到的 Dubbo 框架失去业界宽泛认可的长处，在咱们实际的过程中，也发现了现有的 Dubbo 2.x 版本协定存在的一些有余，比方在云原生大背景下，协定对网关不够敌对，不足挪动端的轻量级 SDK 等。据咱们与 Dubbo 官网保护团队的深度交换，这些点也都是以后 Dubbo 3.0 在重点冲破的方向，如下一代协定、利用级服务发现、云原生基础设施反对等，携程作为 Dubbo 深度用户也将继续的参加到 Dubbo 3.0 的建设与落地过程中。

将来(Service Mesh)

网上对于 Service Mesh 的意义讲了很多，七嘴八舌，集体认为可能最次要还是以下几点。

• 标准化意味着更低的老本，比方研发成本低，学习老本也比拟低，其余公司学习的微服务框架，到携程还能够持续用，省去了学习和踩坑的老本；
• 过程解耦，框架同学可能比拟感兴趣，中间件无奈独立降级的问题始终困扰着框架研发同学，在这个问题上，envoy 能够独立降级也是值得期待的；
• 通过下沉，复用了云基础设施的一些能力，一方面，可能更好的反对多语言，业务依据本人的场景抉择适合的语言，另一方面，通过下沉也可能让 SDK 更简略，缩小 Jar 依赖的兼容性问题；
• 因为更加规范以及下沉，可能带来更好的云部署能力，业务出海时能够依据理论状况部署须要的组件，不再依赖框架全家桶了。

1. Service Mesh SDK

下图是 Istio 官网提供的 Service Mesh 架构图，如果说 Istio 解决了管制立体的标准化，envoy 或者 sofa-mosn 解决了数据立体的标准化，那么对于 SDK 来说，是否须要有个标准化的组件，或者是否存在适宜咱们的规范的 SDK 呢？

对于局部中小公司，没有本人的中间件团队，可能会抉择商业版 SDK。然而，对于携程这样的规模，对扩展性要求很强，同时曾经存在上千 dubbo 服务的公司来说，咱们可能更期待 3.0 的标准协议。

2. 现有协定不适宜下沉

现有的 SOA 协定可能不太适宜作为标准协议，基于 Http 1.1 的文本协定，跟 TCP 协定相比，建连带来的老本，很大水平上会导致长尾，影响服务的稳定性。

Dubbo 协定因为对网关不太敌对，同时存在着跨语言和协定穿透性等问题，envoy 自身也能够了解为单机网关代理，所以也不太适宜作为标准协议。

其次，存在的跨语言和协定穿透性问题，阿里刘军同学有过分享，感兴趣的同学能够参考：https://www.infoq.cn/article/y5HC2JjtAvMWYILmVILU

3. 新协定

既然现有的协定都不太适宜，是否能够思考云原生的标准协议 gRPC。没错，从协定层面来看，这个抉择没有问题，然而 gRPC 跟 proto 强绑定的问题，须要携程现有的几千个服务重写业务逻辑代码，这个老本可是无奈被承受的。

咱们对于新的协定的期待，应该是可能基于 POJO 对象，同时还要合乎 gRPC 协定标准。一方面，可能很好的利用云原生的根底能力。另一方面，对于小众语言，也能够利用现有的 gRPC 框架实现与支流 SDK 的互通。

对于新的 SDK，岂但要有规范的传输协定，同时思考到服务框架与业务的严密耦合，扩展性也是要保留的次要的个性，还须要思考 API 的标准化，利用对立的监控组件。

4. 总结

当初，咱们实现了 SDK 的局部标准化。将来，咱们肯定会在云原生的路线上走的更快，更稳，更规范。

有奖互动

9 月 4 日 11:00 前在阿里巴巴公众号留言区写下你 对于微服务架构的思考或问题，点赞前 5 名即可取得《携程架构实际》图书一本！