东营网站关键词优化,自助网站建设平台,网站搜索页面设计,免费的ppt通用模板简介#xff1a; Dubbo 作为分布式微服务框架#xff0c;众多公司在实践中基于 Dubbo 进行分布式系统架构。重启开源后#xff0c;我们不仅看到 Dubbo 3.0 最新的 Roadmap 发布#xff0c;而且还看到阿里在自身电商开始推进 Dubbo 和内部 HSF 的融合#xff0c;并在 双11 …简介 Dubbo 作为分布式微服务框架众多公司在实践中基于 Dubbo 进行分布式系统架构。重启开源后我们不仅看到 Dubbo 3.0 最新的 Roadmap 发布而且还看到阿里在自身电商开始推进 Dubbo 和内部 HSF 的融合并在 双11 上开始使用 Dubbo 3.0。本文是工商银行基于 Dubbo 构建金融微服务架构的分享主要讲述了服务发现的应对策略和成果后续将发布工行大规模服务监控治理的实践以及从企业角度怎么去对 Dubbo 二次开发等内容。欢迎关注。背景及概览工行传统的业务系统一般都是基于 JEE 的单体架构面对金融业务线上化及多样化的发展趋势传统架构已经无法满足业务的需求。因此从 2014 年开始工行选择了一个业务系统做服务化的尝试并验证、评估、对比了当时的几个分布式服务框架最终选择了相对完善、并且国内已经有较多公司落地使用的 Dubbo。与此同时工行还对 Dubbo 做了企业定制帮助这个业务系统完成了服务化的落地上线之后也收到了非常好的效果。2015 年工行开始扩大服务架构的落地范围一方面帮助传统业务系统进行架构转型另一方面也逐渐沉淀了类似中台的超大规模服务群组支撑业务系统快速服务的组合和复用。随着经验积累工行也不断对 Dubbo 进行迭代优化和企业定制同时围绕服务也逐步打造了完善的服务生态体系。2019 年工行的微服务体系也正式升级为工行开放平台核心银行系统的关键能力之一助力工行 IT 架构实现真正的分布式转型。工行的微服务体系组成如下图所示基础设施方面不管是业务系统的服务节点还是微服务平台自身的工作节点都已部署在工行的云平台。服务注册发现方面除了常规的服务注册中心外还配合部署了元数据中心用于实现服务的按节点注册发现。服务配置方面通过外部的分布式配置中心以实现各类动态参数的统一管理和下发。服务监控方面实现对服务各类运行指标的统一采集和存储并与企业的监控平台对接。服务跟踪方面主要是用于实时跟踪服务的整体链路帮助业务系统快速定位故障点并准确评估故障的影响范围。服务网关是为了满足传统业务系统访问服务需求在 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 次服务提供者列表123...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% 左右做完这个优化就能从容应对投产高峰期大量服务的上下线。2Multiple 模式工行采纳并优化改造了 Dubbo 新版本中 registry-multiple 的 SPI 实现用于优化多注册中心场景下的服务订阅。Dubbo 中服务消费者原有处理逻辑是这样当存在多个注册中心的时候消费者按注册中心对应的 invoker 缓存去筛选提供方第一个注册中心对应的缓存中如果没找到则去找第二个注册中心对应的缓存。如果此时第一个注册中心出现可用性问题推送给消费者的数据有缺失甚至为空就会影响消费者的这个筛选过程如出现无提供方的异常、调用负载不均衡等。而 multiple 注册中心是把多个注册中心推送的数据合并后再更新缓存所以即使单个注册中心故障推送了数据不完整或者为空只要有其他任意一个注册中心的数据使完整的就不会影响最后合并的数据。并且multiple 注册中心机制也用于异构的注册中心场景出现问题可以随时把注册中心下线这个过程对服务节点的服务调用则完全透明比较适合灰度试点或者应急切换。更进一步还有额外的收益消费者端 Reference 对象是比较占用 JVM 内存通过 multiple 注册中心模式可以帮消费者端节省一半的 invoker 对象开销因此非常推荐多个注册中心场景采用 multiple 模式。3按节点注册工行反向移植 Dubbo2.7 及 Dubbo3.0 的服务发现逻辑使用“按节点注册”的服务注册-发现模型。这里即配置中心、元数据中心、注册中心这个铁三角组合配置中心主要用来存储节点级别的动态参数以及服务的原来写在 Zookeeper 上的 configurations 和 routers 这些持久节点的数据。元数据中心存储节点元数据也就是每个服务节点名称也就是 applicaiton-name和其提供的服务的映射关系以及每个服务的类定义信息比如每个方法的输入输出参数信息。注册中心此时注册中心则只需要存储服务提供者节点名称和实际 ip 端口的关系。这个模型的变化对于消费者的服务调用则没有任何影响。消费者端根据元数据中心上“服务节点名称”与“服务”的关系以及注册中心“服务节点名称”与实际 ip 端口的关系生成兼容存量模式的服务提供方 invoker 缓存。压测结果显示按节点注册可以让注册中心上的数据量变成原来的 1.68%这对量就对线上的 Zookeeper 来说毫无压力10 万级别的服务量和 10 万级别的节点量都能够轻松支撑。未来的规划未来工行也希望能有机会走出去深度参与到社区中把自身在 Dubbo、Zookeeper 服务端、zkclient 上的好的 feature 贡献出来比如除了上面的优化点外工行还在 Dubbo 上做了 RPC 结果的精细化识别PAAS 的适配同端口多协议、自隔离等能力还在 Zookeeper 上增加了注册熔断机制同时正在研究 Observer 的同步机制避免数据全量同步带来的一系列问题。另外从微服务的发展看Mesh 已经是目前的热点之一。工行的痛点主要在服务 SDK 版本升级上Istio 不争气MCP 生死未卜如何能让存量 Dubbo 服务平滑过渡到 MESH 架构目前已经有初步的方案但还有非常多的技术难关需要克服。作者张远征原文链接 本文为阿里云原创内容未经允许不得转载
