架构实战案例解析_11_10_可复用架构案例三中台是如何炼成的
你好，我是王庆友。
在第八讲中呢，我通过一个实际的订单服务案例和你介绍了如何设计一个基础服务。
那今天呢我就带你继续了解如何在实际的业务场景中，通过一步步的架构升级，最后落地一个中台，实现企业级能力的复用。
通过前面的介绍，我们已经很清楚了共享服务和中台的价值。
但在实践中啊要不要对系统做这样的升级，我们还需要结合业务来判断。
比如说业务上有什么重大变化，导致当前系统的弊端已经很明显不能适应业务发展了呢？还有啊在做架构改造时，如何在业务系统和资源三者之间做平衡，对系统进行分布式的改造呢？那我们知道架构没有最好，只有最合适的。
随着业务的发展，系统需要不断的升级，这是一个螺旋式上升的过程。
那如何结合当前的业务发展阶段，适时的推进架构改造，并且能够比较接地气的落地，这个是我们要追求的目标。
那接下来呢我以实际的订单系统改造为例，结合订单业务的发展和系统的痛点，为你介绍如何推进架构，从单体到共享服务，再到中台的改造过程。
那保证系统呢能够不断适配业务的升级。
这里先说一下项目背景，公司作为供应商，为许多大型餐饮连锁企业打造o to交易平台，包括三方聚合外卖、自由小程序、爱p点餐等服务。
这些线上用户的订单最终会落到门店的收银系统，由门店进行捋单。
那公司的业务发展它有个变化过程。
一开始呢只提供聚合外卖服务，后来进一步提供了小程序和爱p下单服务。
那你也可以发现整个订单业务处理的架构，它也是随着业务的不断变化而不断演变的。
下面呢我就为你具体介绍，一开始呢我们提供的是聚合外卖服务。
这里呢我放了一张架构图，你可以到文稿中去看一下。
这里一共有三个系统，分别是三方外卖平台，门店的收银系统以及外卖系统。
其中呢外卖系统是我们开发的，其他两个都是我们要对接的外部系统。
接下来呢我说一下系统具体的交互过程。
首后呢用户在三方外卖平台，比如美团、饿了么下单。
然后我们的外卖系统通过外卖平台的API拉取用户的订单，并且把订单落到本地数据库里面。
最后呢用店的收银系统会访问外卖系统，提供的接口取取订在门店内部完成履单过程。
当然门店履单后收银系统会反过来同步订单状态，给外卖系统、外卖系统再同步订单状态，到第三方外卖平台。
在这里呢你可以看到外卖系统，它是个单体应用，内部包含了外卖同步接口和pos接口进个模块。
其中外卖同步接口负责和第三方外卖平台对接。
它主要是针对不同的外卖平台做接口的适配。
而pos接口呢，它负责和门店的收银系统进行对接。
这两个模块呢底下都是使用同一个外卖订单数据库。
那从数据模型上看，系统的订单模型是完全按照外卖订单的需求设计的那订单状态管理也相对比较简单。
因为这些订单都是用户已经在三方外卖平台完成支付的。
所以我们的外卖系统主要是负责管理门店履单过程中带来的订单平态变化。
那从系统架构上看，外卖系统从外卖平台接单，然后呢把订单推送给后面的收银系统。
这样只需要一个应用，一个数据库，两套接口就可以支持。
那使用单体架构就能很好的满足外卖的接单需求。
那接下来呢随着公司业务的升级，这了提供聚合外卖服务之外，公司还提供自由小程序的下单服务。
这样子呢，消费者既可以在三方外卖平台下单，也可以在品牌自由的小程序里面下单。
那不同于三方外卖订单，小程序下单平台，它是个完整的业务，包含了小程序的用户注册、商品和菜单浏览商品加购物车、在线支付等功能。
相应的呢这里会有多个技术服务，对应具体业务的处理。
比如说商品服务，提供前台的商品浏览功能，支付服务，提供用户的支付功能。
这些技术服务都是由独立的小程序服务端负责整合。
然后提供接口，供小程序前端访问。
那当用户在小程序提交订单后，小程序前端会调用服务端的下单接口，然后服务端调用订单服务。
在小程序的订单库里落地订单。
好，现在我们已经完成了前台用户的下单，但后台的订单履行怎么处理呢？这里呢有两种选择。
那第一种方式呢，小程序订单和外卖订单呢处理整合收银系统，除了对接外卖系统，同时也对接小程序的订单服务。
但这样子一来，收银系统就需要同时对接两套订单接口，它需要做比较大的改造。
那由于收银系统是第三方的系统，我们在实践中呢很难落地。
第二种方式呢，我们把小程序订单当做一个特殊的外卖渠道，把小程序订单推送到外卖的订单库里。
那最终呢还是由外卖系统来对接收银系统，也就是说相当于小程序订单直接借用了外卖订单的履单通道。
那在当时呢，由于项目上线时间比较紧急，同时从系统的稳定性角度出发，避免对收银系统做大的改造。
那我们采取第二种方式，那小程序的订单处理呢就嫁接在已有的外卖系统的。
我这里呢放了一张架构图，你可以到文稿中看一下。
在这里呢你可以看到小程序的下单平台和外卖系统呢它是相对独立的那同时我们为了更好的解耦小程序订单服务和外卖系统之间呢是通过消息系统同步订单数据的那这个方案呢在当时看来是个比较务实的选择哦。
通过复用外卖订单的履单通路，我们也实现了小程序订单来闭环处理。
那表面上看呢，我们节省了重新搭建系统的成本，也快速落地了小程序交易这条新业务线。
但这样的架构啊实际上是一种妥协。
在后续的系统运行过程中，也给我们带来了很多的问题。
第一个问题，这里有两套订单系统一套针对小程序订单，一套针对外卖订单。
那我们知道这两套订单，他们的字段属性和订单装的定义都有不同的地方。
那我们是把小程序的订单啊，硬生生的套在了外卖订单的模型里面。
这样就限制了小程序订单能力的扩展。
啊，第二个问题呢是小程序订单处理链路太长了。
那我们从小程序的服务端开始到订单服务，再到小程序订单数据库，再到消息系统，再到外卖同步接口，再到外卖的订单数据库，再到pos接口，最后到收银系统。
这一共包含了八个处理环节，系统整体的性能和可用性都存在很大的问题。
比如说取餐码已经从收银系统同步给外卖系统，但由于消息队列堵塞，外卖系统不能及时同步给小程序的订单服务，这样导致了小程序用户呢不能及时的看到取餐码。
那最后为了使两套订单系统解耦，我们使用了消息队列这两个库之间同步订单数据，这降低了系统整体的稳定性。
实践中呢也发生过多起。
因为消息队列故障导致的线上系统。
另你可以发现出现这些问题的根源呢是我们把小程序订单硬塞给外卖系统，一方面订单数据模型不匹配。
另外一方面，由于这是两个系统简单的拼接，导致系统调用链路很长，从而影响了业务的扩展和系统的稳定性。
那有没有更好的办法能够把这两个系统有机的结合起来呢？那接下来我们就来看一下，如何通过一个统一的订单服务对这两个系统进行深度的融合，从而灵活的支持多种订单业务。
那这里呢我们把小程序的订单服务提升为统一的共享的订单服务，由他来落地所有类型的订单。
对于这个统一的订单服务来说，外卖订单、小程序订单或者说其他的新订单，那都是它的下单来源，所有订单汇总的订单服务里，然后统一提供给收银系统进行捋单。
这里呢我也放了一张具体的架构图，你可以到文化中看一下。
那系统架构经过调整后有两个大的变化。
那原来呢外卖和小程序各自有个订单库，现在合并为一个订单库，由这个订单服务呢统一对外提供订单数据的访问和状态管理。
那原来外卖系统有两个模块，外卖同步接口和pos接口，现在呢升级成为两个独立的应用。
那外卖同步接口变成外卖同步的服务，它对接外卖平台。
那pos接口它变成pos的服务，对接门店的收银系统，他们都是通过统一的订单服务存取订单数据。
那经过升级新的架构具备了明显的层次结构。
从上到下，它分为三层，首先是各个渠道端，包括三方外卖平台、小程序、前端和pos收银系统。
然后呢每个端都有相应的服务来对接。
那要外卖同步服务对接外卖平台、小程序、服务端对接小程序、pos服务对接收银系统。
最后呢这些服务端都统一调用底层的订单服务。
那在这个架构里面，如果我们要增加新的下单渠道，就非常方便。
比如说要支持apple下单，我们提供一个apple服务端就可以。
那要新增加后台的履单方式也非常方便。
比如对新的电子卡券类订单，它不需要经过收银系统，可以直接由企业内部的OMS系统进行处理。
那要实现这样的业务，我们只需要增加一个和OMS系统的适配应用就可以了。
所以这里不仅仅是一个外卖订单和小程序订单的处理平台，而是升级成为一个完整的全渠道交易平台。
那同时呢订单处现链路大大缩短了，从小程序服务端开始到订单服务，再到订单数据库到pos服务这到收银系统。
那它只有五个节点，相比之前呢减少了三个节点。
那系统的可用性和端到端的性能得到了大幅度的提升。
最后呢统一订单服务，它实现了统一的订单属性定义、统一的订单状态管理以及订单数据的集中存储。
这对后续的BI分析和数据中台建设都非常有帮助。
他们在处理订单数据时，只需要从一个订单库拉取数据解析，一个订单数据模型就可以了。
那我们可以看到前面的同一订单服务，它整合了外卖和小程序的订单，并且为新的下单渠道预留扩展。
那按照同样的思路呢，我们可以构建统一的商品服务，它可以同时满足外卖和小程序上的商品管理。
那我们可以构建统一的促销服动，同时支持线上和线下的促销活动。
那我们也可以构建统一的库存服务，实现线上和线下库存的同步和共享等等。
那么通过构建这样一系列的共享服务，我们就实现了各个渠道业务规则和业务数据的统一管理。
最终我们就落地这个强大的商务中台，它可以很方便的扩展业务业务。
最终企业整体业务能力的服用。
那最后呢我放了一张实际项目的中台架构图啊，你可以到文稿中看一下。
在这个架构中呢，前端它有三个业务场景，分别是小程序点单、app商城下单、外卖平台下单。
那每个业务场景它都有对应的服务端负责对接。
那在这个服务端下面还有一些辅助的应用，比如说购物车秒杀拼盘等等。
同时呢这里还有一个订单控制服务，它负责订单逻辑的编排，以及前后台之间订单状态的同步。
那你可以把它看作是基础服务之上的一个聚合服务。
最底下呢就是核心的业务中台，它有九大服务中心组成置业中心和商户内部的系统进行对接。
其中商品中心和库存中心对接的是压配系统，通过系统对接的是CM系统，订单中心对接的是pos收银系统。
这里的对接呢分分别对应应的配配插件，负责通过这个订单业务改造落地后的中台架构。
那这里你可以看到中台由各个通用的基础服务组成，它是相对标准的。
而插件呢它是定制的，具体和每个企业的基础系统组成。
那这样子呢，通过共享服务和中台，我们就把企业内部的基础设施和线上的业务场景有效的打通了。
那从系统架构的层面呢，为企业的业数数字转型打下了良好的基础。
那最后我总结一下今天讲的内容。
今天我从一个企业的订单业务变化出发，为你介绍了为什么要落地一个统一的订单服务，以及如何落地。
并且通过打造一系列类似的共享服务，逐渐升级系统到中台架构。
相信通过这个实际案例，你进一步了解了如何通过共享服务和中台实现业务能力的复用。
并且根据公司的业务发展阶段，选择合适的时机、合适的架构，以比较接地气的方式对系统进行逐步的改造。
那最后给你留一道思考题，目前你的公司有没有落地共享服务，它是怎么逐步演变过来的呢？欢迎在留言区和大家分享你的答案。
如果你在学习和实际的过程中有什么问题或者思考，也欢迎给我留言，我们一起讨论，感谢收听，我们下一期再见。