中仑网络在 2022 年完成了服务框架从 Dubbo 2 到 Dubbo 3 的全站升级，深度使用了应用级服务发现、Kubernetes 原生服务部署、服务治理等核心能力。来自中仑网络的技术负责人来彬彬对整个 Dubbo 3 的选型、升级过程及收益等做了深入总结。
来彬彬，2020 年加入苏州中仑网络科技有限公司，担任架构部负责人/高级架构师，十四年架构开发经验。曾任职于苏宁易购七年参与商户平台、物流四方服务平台等架构设计，为用户提供亿级 SaaS 服务。现重点保障中台化实施、性能优化、业务架构、稳定性等，专注零售行业、互联网、云计算、架构设计。
值得一提的是近期 Dubbo 3 官网文档 整体有了本质的提升，并且社区承诺短期内文档还会投入大量精力完善文档，这点对于 Dubbo 3 的使用和用户信心提升非常重要。
公司业务与技术架构简介
苏州中仑网络科技有限公司是一家“专注零售门店增收服务”的公司，一直以“解决中小零售门店经营难的问题”为初心，致力于为零售商户提供门店运营一体化解决方案，帮助零售门店实现增收。中仑网络以零售技术为核心，为零售商户打造出集收银系统、中仑掌柜、微商城、汇邻生活平台、大数据平台、移动支付、智慧农贸、汇邻门店运营服务等为一体的新零售生态体系，实现线上线下全方位融合，为零售商家赋能增收。技术团队在构建之初选取 Dubbo 2.5.3+Zookeeper 版本构建公司微服务基座支撑公司业务发展，后期同阿里云深度合作整体迁移使用阿里云，使用云原生基础设施 ACK（Kubernetes）+MSE（Zookeeper）+Dubbo+PolarDB 等构建，实现可动态缩扩容的服务能力。
伴随合作商扩展 3000+，市场遍及 300+城市，零售商户 30 万+，服务覆盖餐饮、茶饮、服装、母婴、烘焙、生鲜、商超、美业、美妆、宠物等多个行业。伴随着领域拓宽、商户量快速增长上升，系统数量和部署节点也迎来了暴增，随之在系统可用性上受到较大挑战：微服务治理能力、微服务地址注册发现，Kubernetes 平台服务的无损上下线顺滑度上问题与挑战越来越多。架构图见图一。
图一
Dubbo 3 升级总结
在升级微服务组件技术选型上主要考虑解决以前的痛点：服务治理能力、云原生友好性、服务注册发现，这几个制约业务发展的紧要问题。比较下来 Dubbo 3 架构设计理念与我们较为契合，能较好的满足我们业务发展要求。
1、服务治理能力
Dubbo 3 提供丰富的服务治理能力，可实现诸如服务发现、负载均衡、流量调度等服务治理诉求。在使用上我们有两种选择：
- 使用 Dubbo 管理控制台管理配置
- 集成相关 API 能力到系统
同时 Dubbo 扩展性较好，可以在很多功能点（见图二）去定制自己的实现，以改变框架的默认行为来满足自己的业务需求。
Dubbo SPI ( Service Provider Interface)将接口实现类的全限定名配置在文件中，并由服务加载器读取配置文件，加载实现类。这样可以在运行时，动态为接口替换实现类。基于此特性，我们可以很容易的通过 SPI 机制为我们的程序提供拓展功能，如我们在此基础上实现了基于生产和消费者过滤器 Filter 实现全链路自定义的链路监控;基于路由扩展标签路由方式进行测试环境的隔离方便快速多版本服务测试验证。实操上我们基于生产者注册服务时打标，如原系统 A V1 版本部署在 fat 环境上，现在为了测试 V2 版本，我们将 V2 版本打标 tag=fat-v2；使用端在消费时指定 Invocation Attachment 参数，inv.setAttachment(TAG_KEY, routeTag)；基于此我们可以方便自测试，同时生产上我们也可以做简单的生产灰度运用。
图二
2、云原生友好性
Dubbo 在设计上遵循云原生微服务开发理念，微服务支持 Kubernetes 平台调度，实现服务生命周期与容器生命周期的对齐，包括 Dubbo 的启动、销毁、服务注册等生命周期事件。中仑网络微服务管理使用的是 MSE（Zookeeper）,因而我们服务暴露使用需与之对齐。具体操作上我们自定义 Startup 启动探针、 Liveness 存活探针、Readiness 就绪探针。项目的正常切换需要保障无损的上下线，在实施中无损上线相对于下线来说会更麻烦点，项目的发布上线过程大体会遵从如下流程（大致分成三个阶段）：
第一阶段升级少量（如 20% ）的实例，并切换少量流量到新版本，完成这个阶段后先暂停升级。
经过人工确认之后继续第二个阶段，升级更大比例（如 90% ）的实例和流量，再次暂停等待人工确认。
最后阶段将全量升级到新版本并验证完毕，从而完成整个发布过程。如果升级期间发现包括业务指标在内的任何异常，例如 CPU 或 memory 异常使用率升高或请求 500 日志过多等情况，可以快速回滚。
因为我们使用的是 MSE（Zookeeper）服务，Dubbo 服务自注册在应用启动过程暴露不受 Kubernetes 生命周期的控制，出现项目未完全就绪部分服务可被提前可被访问问题。
图三
实施处理上我们主要利用 Dubbo Qos 指令,初始使用服务不暴露，在应用就绪后调用 Qos online 指令进行服务上线替换老节点，每次替换的节点数量基于发布策略来制定;下线过程针对需下线节点我们会先使用 Qos 指令进行下线 offline 操作等待应用执行完服务，从而进行优雅停机，从实践的效果来看能满足我们的生产需求。
3、实例级别升级切换
相比于 2.x 版本中的基于接口粒度的服务发现机制，3.x 引入了全新的基于应用粒度的服务发现机制，进一步提升了 Dubbo 3 在大规模集群实践中的性能与稳定性。此次升级过程中我们也同步引入了配置中心与原数据中心，即将图四置灰部分启用：
图四
采用实例级别注册管理，一个应用 N 个服务，接口级时 N 服务需监听推送，应用级只关注单实例相关信息。同时引入元数据中心后极大降低接口配置数据信息，减少接口数据传输大小，相关职责配置也更加清晰。根据测试新模型大幅提高系统资源利用率，降低 Dubbo 地址的单机内存消耗，大幅降低注册中心集群的存储与推送压力，上线后稳定性有较大的提升。
总结与展望
在中仑网络 Dubbo 2 升级 Dubbo 3 的过程中我们也有过一些迟疑，如把接口级换成应用级还是混合注册；Dubbo 3.0 新特性新技术在项目中引入的时机与范围。对公司来说大的升级意味风险和不可预知的问题，但同时也能为之带来资源利用率提升、基础功能的扩展与增强，作为技术人员我们需要反复谨慎评估与论证。现在我们已经完成切换所有的业务领域。
作者：刘军
原文链接
本文为阿里云原创内容，未经允许不得转载。
