既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上C C++开发知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新
工行的微服务体系组成如下图所示:
- 基础设施方面,不管是业务系统的服务节点,还是微服务平台自身的工作节点,都已部署在工行的云平台。
- 服务注册发现方面,除了常规的服务注册中心外,还配合部署了元数据中心,用于实现服务的按节点注册发现。
- 服务配置方面,通过外部的分布式配置中心,以实现各类动态参数的统一管理和下发。
- 服务监控方面,实现对服务各类运行指标的统一采集和存储,并与企业的监控平台对接。
- 服务跟踪方面,主要是用于实时跟踪服务的整体链路,帮助业务系统快速定位故障点,并准确评估故障的影响范围。
- 服务网关是为了满足传统业务系统访问服务需求,在 Dubbo 服务订阅及 RPC 能力之上,实现了新服务、新版本的自动发现、自动订阅和协议转换能力(HTTP 协议转 RPC 协议),实现 7×24 小时不间断运行。
- 服务治理平台,提供给运维人员和开发测试人员一个一站式的管理、监控、查询的平台,提升日常服务治理的效率。
最大的挑战
经过工行多年的落地实践,本文共总结了以下两方面的最大挑战:
- 性能容量方面,目前线上服务数(即 Dubbo 概念中的服务接口数),已超 2 万,每个注册中心上的提供者条目数(即每个服务的所有提供者累计),已超 70 万。根据评估,未来需要能支撑 10 万级别的服务数,以及每个注册中心 500 万级的提供者条目数。
- 高可用方面,工行的目标是:微服务平台任何节点故障都不能影响线上交易。银行的业务系统 7×24 小时运行,即使在版本投产时间窗内,各业务系统的投产时间也是相互错开的,平台自身节点要做升级,如何避免对线上交易带来影响,特别是注册中心的自身的版本更新。
本文将先从服务发现方面,来分享一下工行的应对策略及成效。
服务发现难点和优化
1. 入门
在 Dubbo 中,服务的注册订阅及调用是一个标准范式,服务的提供者初始化时注册服务,服务消费者初始化时订阅服务并获取全量提供者列表。而运行期间,服务提供者发生变化时,服务消费者可获取最新的提供者列表。消费者与提供者之间点对点 RPC 调用,调用过程不经注册中心。
在注册中心的选择上,工行在 2014 年就选择了 Zookeeper。Zookeeper 在业界的各类场景下有大规模的应用,并且支持集群化部署,节点间数据一致性通过 CP 模式保证。
在 Zookeeper 内部,Dubbo 会按服务建立不同的节点,每个服务节点下又有 providers、consumers、configurations 及 routers 四个字节点:
- providers 临时节点:记录该服务提供者清单。提供方下线子节点就自动删除,通过 Zookeeper 的 watch 机制,消费者可以第一时间知道提供者清单发生了变化。
- consumers 临时节点:记录消费者的清单,主要用于服务治理时查询消费者。
- configurations 持久节点:主要保存服务治理时需要调整的服务参数。
- routers:子节点为持久节点,主要用于配置服务的动态路由策略。
在线上生产环境,Zookeeper 分数据中心部署了多个集群,每个集群配置了 5 个选举节点,若干个 Observer 节点。Observer 节点是 Zookeeper3.3.3 版本引入的一个新的节点类型,它不参与选举,只听取表决结果,其他能力则和 Follower 节点相同。Observer 节点有以下几方面的好处:
- 分流网络压力:随着服务节点的增多,如果客户端都连接选举节点,对选举节点来说需要消耗大量的 CPU 去处理网络连接和请求。但是选举节点又无法任意水平扩容,选举节点越多,事务投票过程就越长,对高并发写性能是不利的。
- 降低跨城跨 DC 的注册订阅流量:当有 100 个消费者需要跨城订阅同一个服务,Observer 可以统一处理这部分跨城网络流量,避免对城际间的网络带宽带来压力。
- 客户端隔离:可以将几个 Observer 节点专门分配给某个重点应用使用,保障其网络流量隔离。
2. 问题分析
工行根据这几年线上 Zookeeper 的使用心酸血泪史,总结了 Zookeeper 在作为服务注册中心时面临的问题:
- 随着服务数量以及服务提供者节点的增加,服务推送的数据量会呈爆炸式增长。举个例子,一个服务有 100 个提供者,当提供者启动的时候,因为 Zookeeper 的 CP 特性,每上线一个提供者,消费者都会收到事件通知,并从 Zookeeper 来读取这个服务的当前全部提供者的列表,然后刷新本地缓存。这个场景下,理论上每个消费者总共收到了 100 次事件通知,并从 Zookeeper 读取了 100 次服务提供者列表,1+2+3+…+100,总计 5050 条提供者数据。这在业务系统投产高峰期问题尤为突出,容易导致 Zookeeper 集群的网络被打满,造成服务订阅效率极其低下,并进一步影响了服务注册的性能。
- 随着写在 Zookeeper 上节点数量的增多,Zookeeper 的 snapshot 文件也不断变大,每次 snapshot 写入磁盘,会出现一次磁盘 IO 冲高。投产高峰期,因为事务量大,写 snapshot 文件的频率也非常高,这对基础设施带来了较大的风险。同时 snapshot 文件越大,也预示着 Zookeeper 节点故障后恢复的时间越长。
- 当 Zookeeper 选举节点发生重新选举后,Observer 节点都要从新的 Leader 节点同步全量事务,这个阶段如果耗时过长,就很容易导致连接在 Observer 节点上的客户端 session 超时,使对应 providers 节点下的临时节点全部被删除,即从注册中心角度看,这些服务都下线了,消费者端则出现无提供方的异常报错。紧接着,这些提供者会重新连接 Zookeeper 并重新注册服务,这种短时间内大批量服务的注册翻转现象,往往带来更为严重的服务注册推送的性能问题。
综上,可以得出的结论是:总体上 Zookeeper 作为注册中心还是比较称职的,但在更大规模服务量场景下,需要进一步优化。
3. 优化方案
工行最主要的优化措施包括下面这几方面:订阅延迟更新、注册中心采取 multiple 模式、升级到按节点注册等。
1)订阅延迟更新
工行对 Zookeeper 客户端组件 zkclient 做了优化,把消费者收到事件通知后获取提供者列表做了一个小的延时。
当 zkclient 收到 childchange 一次性的事件后,installWatch() 通过 EventThread 去恢复对节点的监听,同时又使用 getChildren() 去读取节点下的全部子节点获取提供者列表,并刷新本地服务提供者缓存。这就是前面说的“5050 条数据”问题的根源。
工行在 zkclient 收到 childchange() 的事件后,做了个等待延迟,再让 installWatch() 去做它原来该做的事情。这个等待过程中如果服务提供者发生变化,则不产生 childchange 事件。
有人会问,这是不是违背了 zookeeper 的 CP 模型呢,其实并不是,zookeeper 服务端的数据是强一致的,消费者也收到了事件通知,只是延后去读取提供者清单,后面执行 getChildren() 时,读取到的已经是 zookeeper 上的最新数据,所以是没有问题的。
内部压测结果显示,服务提供者大规模上线时,优化前,每个消费者收到了总计 422 万个提供者节点的数据量,而延迟 1 秒处理后,这个数据量则变成了 26 万,childchange 事件次数和网络流量都变成了原来的 5% 左右,做完这个优化,就能从容应对投产高峰期大量服务的上下线。
2)Multiple 模式
工行采纳并优化改造了 Dubbo 新版本中 registry-multiple 的 SPI 实现,用于优化多注册中心场景下的服务订阅。
Dubbo 中服务消费者原有处理逻辑是这样:当存在多个注册中心的时候,消费者按注册中心对应的 invoker 缓存去筛选提供方,第一个注册中心对应的缓存中如果没找到,则去找第二个注册中心对应的缓存。如果此时第一个注册中心出现可用性问题,推送给消费者的数据有缺失,甚至为空,就会影响消费者的这个筛选过程,如出现无提供方的异常、调用负载不均衡等。
而 multiple 注册中心是把多个注册中心推送的数据合并后再更新缓存,所以即使单个注册中心故障,推送了数据不完整或者为空,只要有其他任意一个注册中心的数据使完整的,就不会影响最后合并的数据。
并且,multiple 注册中心机制也用于异构的注册中心场景,出现问题可以随时把注册中心下线,这个过程对服务节点的服务调用则完全透明,比较适合灰度试点或者应急切换。
更进一步,还有额外的收益,消费者端 Reference 对象是比较占用 JVM 内存,通过 multiple 注册中心模式,可以帮消费者端节省一半的 invoker 对象开销,因此,非常推荐多个注册中心场景采用 multiple 模式。
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
获取](https://bbs.csdn.net/topics/618668825)**
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!