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

语言: CN / TW / HK

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

IT 信息的发展规划

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

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

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

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

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

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

韵达业务中台建设的过程

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

在这里插入图片描述

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

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

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

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

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

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

云原生技术的支撑

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

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

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

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