韵达基于云原生的业务中台建设 | 实战派

本文将为大家分享韵达业务中台基于云原生的建设过程。主要分为三部分，第一部分是 IT 信息的发展规划，第二部分是韵达业务中台建设的详细过程，第三部分是对应云原生技术的支撑。

IT 信息的发展规划

大部分人都知道韵达是“三通一达”里面的一达，是综合物流快递的服务商，其实它现在也有很多新兴的业务，包括供应链、国际业务、冷链业务等，给用户提供安全、快捷的物流服务。韵达是以客户为中心，其企业使命是传爱心、送温暖、更便利，目标是基于大数据、云原生、智能科技等信息技术来打造一流的物流企业。

韵达公司的业务发展很快，随着电商的发展，电商物流企业每天的订单量、运单量、数据量非常大。还有一些新兴的业务，业务的快速发展给其 IT 建设也提出更高的要求，主要是两方面：

一方面是如何更敏捷地支持业务发展：

• 更加敏捷地支持业务快速发展。因为业务发展很快，核心业务能力需要服务化，要加强复用，所以一定要提升核心业务能力的复用率。
• 服务需要加强管控和运营。系统建设好以后要在公司内部进行快速推广，要降低沟通成本。
• 业务性能需要快速响应。现在互联网企业里常说的三高之外的新要求，就是高响应力，针对业务需求能够快速迭代发布上线。

另外一方面就是如何更稳定地支撑业务运行。

一部分人认为物流公司无非就是开个车送包裹就可以了。实际上韵达的业务量、订单量一天都是好几千万的，按运单轨迹一天数据量是几十亿的，不是开车就可以的。快递物流对应用系统依赖性是非常高的，如果我们的系统出问题快递包裹就不知道怎么送了，包括中转站包括也不知道往哪个道口分发。

韵达业务中台建设的过程

韵达整个业务运转需要系统更加稳定的运行，要更加高效，可以支持海量高并发处理能力。有些 API 每秒调用量可以达到几万，数据存储量很大，对于海量数据高并发处理也有很高要求。业务需要可观测性、故障快速定位可恢复。像韵达业务中台一些系统基本上复用率可以达到 70% 到 80%，系统出现问题，业务方一堆反馈就过来了，因此，对于故障的快速定位、恢复也有更高的要求。

基于前面两个要求，韵达开始了中台化的建设。核心是共享业务中台的建设，整个项目基于阿里云原生技术构建，其中包括企业级分布式应用服务 EDAS、应用实时监控服务 ARMS、消息队列 RocketMQ 、容器服务 ACK。韵达希望给客户提供高效、稳定、更好的物流服务，因此韵达选择与阿里云合作。

除了阿里云云原生产品之外，韵达也采用业界开源成熟的框架，包括大家都用到的 Redis、Elasticsearch 等设计，还有 Pika、Apache Doris、Apache Flink 等。韵达整个基础设施技术主要就是云原生+开源的成熟技术框架。在基础设施层上面搭建了韵达业务中台，包括订单中心、运单中心、分单中心、会员、用户画像、交易中心等，交易中心是新建设的，提供统一自理运营，其他包括能力注册、能力扩展、依赖管理、质量管理，都是业务中台统一提供。我们支持前端快递的业务板块，包括新兴业务、供应链、冷链、同城等业务。

韵达的业务中台分三个阶段，每个阶段是三个月，也是循序渐进来推动的。其中我们通过和阿里专家的合作，导入了 DDD 领域驱动设计的方法论，在战略设计阶段把整个业务中台分成了不同业务域、子域以及衔接上下文的映射关系。在战术设计阶段，进行面向对象的代码开发实践，包括领域实体、领域服务以及领域事件，实现业务逻辑和技术细节的分离。韵达的开发人员只需要聚焦于业务逻辑的实现，在基础设施层基于阿里云原生技术来搭建。

在业务中台建设过程中，韵达并不是完全从零开始的，在发展的二十多年里，韵达有很多共享能力之前在各个业务线上里，需要把这部分业务能力移交给业务中台团队，再在原有系统基础之上，对接阿里云原生技术，再进行系统层面的改造升级加固，让它可以支持海量数据高并发的处理能力。

当然，也有一些系统是从零开始建设的，比如说交易中心之前是没有的，交易中心主要做在线交易、支付等业务，整体架构上采用阿里开源的 DDD 框架（COLA），它把整个应用系统分为应用层、领域层、基础设施层，代码分层很清晰，让我们核心能力建设可以有快速地迭代并具备高响应能力。

这就是韵达的业务中台建设的大致过程。

云原生技术的支撑

在韵达的业务中台建设完成之后，能给业务带来哪些价值呢？我们简单总结一下：

第一，敏捷高效地支撑业务。将新的业务应用、业务创新进行快速组装，可以实现相关的业务应用快速响应市场。整个业务能力分为两块：第一个是基础能力，还有一个是商业能力，商业能力基于业务场景做了粗粒度的组装、打包服务。通过服务的沉淀可以带来业务的复用，快速响应市场和业务发展的需求，最大程度减少系统建设和运维带来的成本。韵达业务中台很灵活，并不是很臃肿的，它可以基于业务上的需求快速迭代更新。

第二，构建面向业务全景监控能力。按照统计数据，业务中台的核心能力每天光 API 调用量近五亿次，推送消息记录就有大概十多亿的消息量，有些核心能力复用率都达到 70%，很多业务线应用都依赖于业务中台提供的能力，如果系统出问题我们需要很快知道哪里出现问题，这是很重要的。

如果没有出问题，我们也要知道中台服务的调用量，这些都要看得很清楚，出现问题也要快速定位、快速修复，这对于我们业务中台非常重要。基于项目建设中的 ARMS 监测体系，可以提升用户体验洞察和故障定位能力，这一点是不可缺失的。