乐趣区

关于微服务:近万服务实例稳定运行-0-故障携程微服务架构是如何落地的

简介: 本文整顿自作者于 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 名即可取得《携程架构实际》图书一本

退出移动版