“波浪式的用户增长曲线和持续加码的数字化业务平台，对 UU 跑腿的 IT 基础设施建设提出了更高的要求，云原生化摊薄了我们公司的经营成本。”——UU 跑腿 CTO 袁沼
连辙、鼎岳、亦盏、白玙、稚柳、寒砚对本文亦有贡献。
UU跑腿，自2015年6月18日正式上线以来，9年多时间，已经“跑”进全国200余座城市，平台合作“跑男”（UU对骑手的称呼）已超过850万人，为全国亿万用户提供同城即时跑腿服务，成为同城即时生活服务行业的头部企业。
同城配送是竞争极为激烈的赛道，不仅面对大厂的“散钱式”推广、极低发单价以及高价跑单奖励的竞争，还有大量的中小物流公司的竞争。面对大厂及同行的围攻，UU 出生草根，无法用资金去反击，只能选择坚持自己的道路。历经与大厂、中小物流公司的厮杀，如今已做到行业前三，且是唯一一家实现盈利的公司，通过一次次地突破自己、打破束缚，成为这个行业里真正的黑马。
UU 跑腿的差异化竞争力
当被问到企业的差异化竞争力是什么？作为程序员出身的 UU 跑腿创始人乔松涛举了两个例子。
在获客方面，大厂有资金优势，通常会通过地面推广+海量投放来获客，而我们是做了很多创新的小游戏用于拉新（当时很火的一个游戏就是“是男人就下100层”），这很考验团队的创新和对用户的关注。现在我们做了多短视频账，有不少10w+点赞的。这些都给我们的用户增长带来了源源不断的流量。这种获客方式决定了我们的用户增长是波浪式的，今天是平平的，明天之后一个高峰，后天又平平，然后又一个高峰。
在企业经营方面，大厂也有资金优势，会聘用业内能力最强、经验最多的人，而我们的思考是，在存量竞争的领域，创业公司绝对不能只靠人力，我们如今的业务规模是2020年的四倍多，但是我们的客服人数没有变，BD 人均产出更高，原因就是通过数字化来加强业务系统的建设，通过自动化和智能化来提升效率，我们专门建立一个这样的团队，一年好几百万的投入，但规模大了之后，会摊薄公司的经营成本。58当时投我们的时候，看到我们的数字化业务平台都震惊了，惊讶我们居然做到这种程度。
但波浪式的用户增长曲线和持续加码的数字化业务平台，对 UU 跑腿的 IT 基础设施建设提出了更高的要求，我们通过云原生化摊薄了公司的经营成本。”因此，这里我们分享下 UU 跑腿的 IT 基础设施云原生化历程。
UU 跑腿的业务架构和应用架构
UU 跑腿依托领域模型构建中台战略，借助业务支撑域和通用域的业务复用能力，快速扩展并有效支撑家政、代驾、货运等多业务的发展。各个业务线之间，有共性的，也有差异化。我们对功能性需求进行了抽象，提炼特有业务和公共业务，用领域驱动的概念拆分核心域、通用域和支撑域，我们想给用户提供一条龙的服务。
技术架构不是一蹴而就，也不是在最开始就设计成这样，而是根据业务的发展逐渐演进成现在的样子。
UU跑腿业务体量在快速增长的同时，业务范围也在不断扩展， 这对系统架构提出了更高的要求。系统的整体架构完成了从集中式单体架构到微服务架构的演进和优化。微服务有很多优点，包括快速可伸缩性、服务解耦、高容错性、高可扩展性、自动化运维、大规模高复杂性系统等。但是微服务不是银弹，随着链路越来越长，复杂度呈指数增加，也确实带来一系列的挑战，包括如何应对创新的营销推广活动带来的突发流量，遇到线上故障如何在短时间内恢复生产等。
UU 跑腿的云原生演进之路
我们起初是把业务部署在 IDC，但经历过频繁的服务器网线意外断掉，震网病毒在无通知的情况下封禁一批端口，其中包含数据库 alwayson 的端口，导致大量的同步日志挤压，最终数据库崩溃，无法启动。这些都严重制约了我们业务的发展，于是真正决定要开始上云。
另外，我们最开始用的C#语言，开发的单体架构，优点是小团队、小型业务的情况下，10天就能完成研发、2周即可上线。但随着业务内容变多、业务体量变大，原有的技术栈已经影响了开发团队的协作效率。2022年开始，我们启动微服务改造，转向 Java 技术栈，并拥抱容器化。
我们的云原生经历了以下四个阶段：
- 从虚拟机升级到容器化，提升迭代效率和弹性，保障业务稳定性，以容器为核心。
- 从单体拆分为分布式应用，实现更敏捷的开发，以应用为中心。
- 应用之间的治理，确保安全与稳定，以业务为中心。
- 实现微服务洞察，以应用监控为核心。
而这些变化都是最近几年伴随着业务的发展同步进行的，如同给飞行中的飞机换引擎，难度可想而知。
我们做微服务改造，原因有两个。
一是在前期，业务复杂度、业务量、服务器数量都较低的情况下，是能通过简单的横向加服务器就能解决业务的增长问题，后续随着业务复杂度的增加，简单的加机器都无法做到很好的伸缩，因为从单体到微服务的改造成为必然。
二是在2021年后，跑腿业务的基础上，拓展多样化业务，包括家政、代驾、货运等。高效支持多样化业务，就需要对系统进行微服务改造，不仅保证快速支撑新业务的同时，还要保证跑腿系统的稳定。
虽然可以采取开源的方案进行微服务的自建和自运维，但需要大量的中间件的架构师和程序员，研发成本会大量增加，这些成本既无法摊薄我们的经营成本，还会随着业务的增长而增长，我们更希望以云原生的方式，实现 IT 成本的精益可控，从而高效的解决下方的问题：
- 高峰期发布问题，在日均处理数百万订单的高负荷环境下，应用变更会造成响应时间变长或业务闪断，导致用户体验下降。
- 自建 CI/CD 系统，需长期维护，人工运维成本较高。使用人工部署，开发/运维发布负担较重。
- 自建中间件难题：Nacos、网关、MQ 等，缺少弹性能力，人工维护成本高。
- 借助 Zipkin 分布式链路追踪系统，能做到事中告警，但缺乏事前预警能力。
微服务的前提一定是容器化的，否则无法高效的进行运维。因为微服务化后，系统的应用数量、应用层级、复杂度都是指数级提升，伴随着的解决方案就是服务治理和可观测，这些都是环环相扣的，缺一不可。
云原生网关：从多层架构到统一架构
网关是系统的门户，对后续的技术选型，至关重要。
最早一个 Nginx 搞定所有，微服务后必须要有微服务网关，否则每个服务一个地址，可能会有成百上千个服务，让客户端记录这么多服务地址显然不可能，所以诞生了微服务网关。但是微服务网关就成了系统的唯一入口，那就是单点，可能会成为系统瓶颈，所以需要多个微服务网关，然后就是 Nginx +微服务网关的组合网关，分别承担流量转发和微服务入口管控的职能。
但是多层网关对系统的开发和运维都带来了额外的复杂度，而且基于 Java 语言的微服务网关性能并不优秀，徒增了很多扩容的烦恼和风险。
因此，我们和阿里云微服务引擎 MSE 团队合作，统一了网关架构，实现了以下能力：
●容灾能力：
o 跨可用区独立部署，非用户的 K8s 集群避免和自建 Nginx Ingress 的资源竞争。
o 解决了重启时，流量抖动影响长链接的用户体验。
o 支持接入多 K8s 集群部署，支持热更新、不停机发布。
● 预热能力：
o Spring Boot 与 Dubbo 框架混用，通过选用 Higress（企业版是 MSE 云原生网关），并结合 Kubernetes Service，实现了多服务注册与 Fallback 回调机制。
o 配合负载均衡轮训策略、预热区间和健康检查，有效降低了 RT等情况。
● 灰度能力：
o 项目发布前必经小流量验证，灰度测试通过开始滚动部署并下线灰度。
o 采用灰度标签路由实现，多套环境逻辑隔离，成本要低于物理隔离。
● 安全认证能力：基于 ext-auth 插件实现了向外部授权服务发送鉴权请求，以检查客户端请求是否得到授权，提高系统的安全性。
从部署的拓扑上来说，我们分为外部网关和内部网关
● 外部网关通常位于企业网络的边缘，用于连接企业内部网络和外部互联网，负责管理南北向流量，实现安全访问、流量控制等功能。
● 内部网关则位于企业内部网络中，适用于异构语言体系，用于管理东西向流量。
微服务治理：投入1元，避免100元的损失
我们在业务系统上的迭代频率很高，一是支撑多样化业务的快速发展，二是员工使用的数字化业务平台是我们企业的核心竞争力之一，我们需要确保软件迭代过程中的可用性。在业务快速迭代的同时，我们的微服务架构也在同步升级，例如我们将 Dubbo 版本升级到 Dubbo3，升级到应用级服务注册，同时通过 Triple 协议实现了 RPC 服务和 Rest 服务的统一。 在这些业务迭代和架构升级的过程中，稳定性显得尤为重要。
根据三方统计，70%的线上故障源自软件变更，而软件变更过程中主要存在两类引发故障的风险：一是发布过程中流量损失、二是新版代码出错。我们通过引入 MSE 的微服务治理能力，有效地保障了发布变更过程中的稳定性。
在新版本发布的过程中，MSE 全链路灰度功能能够确保在不开启灰度规则的前提下新版本不接收到任何流量。当我们开启灰度规则之后，只有内部测试账号的请求会被引入到灰度环境，我们在线上环境完整地验证新版本的正确性。在内部测试账号验证通过后，再逐步扩大灰度范围，实现发布过程中的全链路灰度，安全地发布一个新版本。
MSE 的全链路灰度功能在新版本发布时提供了额外的保障。在未开启灰度规则的情况下，新版本不会接收到任何流量，从而避免影响现有用户。只有开启灰度规则后，灰度账号的请求才会导入灰度环境，从而在生产环境中全面验证新版本的正确性。在灰度账号测试通过后，我们会逐步扩大灰度范围，安全稳定地完成新版本的发布。
我们借助 MSE 服务治理，在不修改任何代码和配置的情况下实现了可灰度、可观测、可回滚的安全生产方式，可以有效降低变更带来的风险。此外，由于我们有非常多创意类的营销活动，经常会遇到突增的新用户，我们依托于 MSE 的限流、降级、熔断、隔离等能力，出现偶发的流量洪峰和依赖服务出现异常时，有效地限流保护、削峰填谷、隔离故障、降级保护。
可观测体系：云产品收益远大于自建
随着 UU 跑腿业务全面转型容器化部署，采用云原生技术栈，强化服务治理，可观测性变得日益重要：
- 缺乏故障预警能力：在日均处理数百万订单的高负荷环境下，系统发布时极易出现响应超时（RT 超时）和 500 错误异常，导致用户体验下降，甚至业务中断。借助 Zipkin 分布式链路追踪系统能做到事中告警，但缺乏事前预警能力。
- 缺乏微服务洞察能力：从虚拟机升级到容器化，提升迭代效率和弹性，保障业务稳定性；从单体拆分为分布式应用，实现更敏捷的开发；但调用关系变得复杂，故障定位难度增大。
- 更严格的成本要求：运维体系全部自建运维需要大量非功能开发的技术架构师，开源方案并不是直接用于生产，需要结合业务特性进行改造，研发成本大幅增加。
借助阿里云可观测产品家族，UU 跑腿快速建设可观测体系： - 构建全栈可观测体系：结合日志服务 SLS 的 Ingress 监控、云监控–可观测监控 Prometheus 版、ARMS-应用监控，搭建自上而下的可观测体系，覆盖业务指标、应用性能/日志/调用链、容器层指标、IaaS/PaaS 层指标。
- 基于可观测性进行应用巡检：基于可观测性进行应用巡检任务，服务器相关监测 Pod 的 CPU 使用率和内存占用情况；服务相关监测记录总请求量、平均响应时间、错误数、实时实例数、FullGC 次数、慢 SQL 次数、异常次数和慢调用次数等指标；后端应用日志检查是否有异常或错误记录；应用运行状态和指标监测 JVM 状态、应用上下游依赖服务拓扑图等。通过以上措施，可以帮助开发人员快速定位和解决系统中的问题
- 通过微服务治理实现应用稳定性提升：借助 ARMS-应用监控的基于 Java-Agent 字节码增强技术，实现无侵入式微服务治理增强，让微服务应用获得无损上下线、全链路灰度、可观测能力，从而将版本发布对正常业务的影响降到最低。
云消息队列：提升业务稳定性与运维效率
业务扩张背景下，消息队列面临诸多挑战
UU 跑腿的系统架构涵盖了业务订单、积分奖励、活动营销等核心业务链路场景，在向微服务架构演进的过程中，消息通信模式的异步化变得尤为重要。然而，随着业务规模的不断增长，自建开源 RabbitMQ 逐渐暴露出诸多问题，包括集群构建成本和运维复杂度过高、营销推广活动期间的稳定性挑战等，这些问题对用户体验造成了不利影响。主要问题如下：
开源 RabbitMQ 的稳定性问题：
a. 消息堆积等各种情况引起的内存问题，导致机器宕机，且无法通过重启恢复。
b. 镜像队列集群的节点异常宕机后重启，会重启失败或数据丢失且无法恢复。
c. 遇到异常情况，无法定位根因，靠重启等简单的运维手段尝试恢复。自建成本高：为缓解上述稳定性风险，需将业务流量分散至多个集群，从而将单个集群的水位控制在低水位，但是这无疑增加了硬件投入。
集群运维复杂：鉴于集群规模庞大及其固有的稳定性隐患，必须加大人力投入，以确保系统的平稳运行。
云消息队列 RabbitMQ 版：保障业务稳定，提升运维效率
为有效应对这些挑战，UU 跑腿采用了云消息队列 RabbitMQ 版，不仅彻底解决了开源稳定性问题，还进一步提升了系统的稳定性、可靠性和可扩展性，为用户提供了更流畅的服务体验。
1. 彻底解决开源稳定性问题
- 全托管稳定服务：云消息队列 RabbitMQ 版是一款基于自研的分布式存储架构实现的 AMQP 0-9-1 协议的消息产品，兼容所有版本的开源 RabbitMQ 客户端，彻底解决了开源各种稳定性问题（例如消息堆积、脑裂等问题）。全托管的服务，消除客户对服务不稳定的担忧。
- 多可用区高可用：云消息队列 RabbitMQ 版默认支持多可用区高可用的部署模式，能够在单可用区故障时，实现业务的快速自动切换与恢复，从而有效避免业务上的巨大损失，极大提升了系统的整体稳定性和容灾能力。
2. 强大的监控与诊断功能
- 全面的监控仪表盘：从实例级别到队列层面，均可实时追踪各项性能指标的变化趋势，便于快速识别潜在问题。
- 可视化消息轨迹追踪：记录每条消息从生产到消费全过程的关键时间点及状态信息，助力于精准定位故障源头。
- 消息内容检索与处理：支持对特定消息的内容进行查询分析，并提供了重投工具，以便于执行进一步操作。
通过采用云消息队列 RabbitMQ 版，UU 跑腿进一步优化了系统架构，不仅提高了整体稳定性，还显著提升了运维效率。随着 UU 跑腿业务的持续扩张和营销活动的不断推出，云消息队列 RabbitMQ 版将继续保障 UU 跑腿业务的稳定可靠，实现提效降本，将更多精力集中在核心业务逻辑上，无需担心基础设施层面的复杂性和可靠性问题，为用户提供更流畅、更优质的服务体验。
容器化弹性实践：
从21年UU跑腿开始容器化后，与传统应用部署在虚拟机/物理机方式相比，面临如下几个挑战：
- 容器集群节点运维繁琐：随着单个集群部署业务越来越多，节点数量也随之增长，给运维同学带来了额外的工作量和工作负担，尤其是当节点出现 CVE 漏洞修复、NotReady 等异常时，需要人工登录每一台机器进行手工修复。
- 成本洞察困难：由于多个业务之间 Pod 混合部署在多个节点上，而阿里云账单只能体现 ECS 节点实例的账单数据，无法按照 Pod 纬度看到成本信息，这给业务成本分析带来较大的挑战。
- 如何合理使用容器弹性组件：阿里云容器服务 ACK 除了支持开源的弹性伸缩组件 HPA、VPA、Cluster Autoscaler 之外，还提供了 CronHPA、AHPA 以及 Serverless 的弹性能力，针对 UU 跑腿的业务特点，面临如何选取合适的伸缩组件能够带来稳定性的保障和成本的降低的问题
借助阿里云容器服务 ACK，UU 跑腿快速应对和解决了如上痛点：
1. 容器服务 ACK 托管节点池：阿里云容器服务ACK托管节点池能力，可以在指定窗口对节点 OS 的CVE漏洞自动进行修复，除此之外托管节点池还提供了节点 kubelet 自动升级、节点故障重启等多种自定义运维能力，进一步帮助运维提升效率，解决运维繁琐问题。
2. 容器服务 ACK 成本套件：阿里云容器服务ACK成本套件能力，可以支持集群、命名空间、节点和应用四个维度分析业务的成本趋势，并且支持CPU/Memory/混合的成本分摊计算方式，实现精细化成本控制。
3. 容器服务 ACK 弹性组件：针对UU跑腿的特定时间点业务流量增加的业务特点，CronHPA+HPA 结合使用，一方面解决弹性不确定性可能带来稳定性问题，也解决了在业务高峰期间资源水位高的问题；针对集群前期规划的节点容量可能不足的情况，结合使用 Serverless 的资源快速应对，提升了资源调度灵活性，快速应对业务高峰对资源的诉求。
云原生带来的收益
最后提炼下，我们在云原生化过程中的具体收益。
80% 微服务无缝迁移上云
集群高可用，性能显著提升：通过微服务架构的优化，实现了80%的微服务无缝迁移至云端，集群的高可用性和整体性能得到了显著提升。1分钟 弹性效率
节点应用自动伸缩，提升系统并发能力，应对突发流量：采用 Kubernetes 集群管理，实现节点应用在1分钟内的自动伸缩，有效提升了系统的并发处理能力和应对突发流量的能力。80% 降本提效
简化运维流程，实现自动化部署：通过自动化运维工具和流程优化，大幅简化了运维工作，实现了80%的运维成本降低，并确保了零异常的自动化部署。80% 变更稳定性
通过服务治理优雅上下线，保证变更稳定性：借助 MSE 服务治理工具，实现了服务的优雅上下线，确保了80%的变更稳定性，提供了高质量的服务 SLA 保障。
