10 | 可复用架构案例（三）：中台是如何炼成的？
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文介绍了一个实际的订单服务案例，通过架构升级最终落地一个中台，实现企业级能力的复用。文章从聚合外卖订单架构和小程序下单架构两个方面展开，详细介绍了系统架构的演变和业务发展的变化。作者通过实际案例，阐述了在业务发展过程中，系统架构需要不断升级和改造，以适应业务的发展需求。同时，作者也指出了在架构升级过程中可能出现的问题和挑战，并提出了对系统进行深度融合的思路。 文章首先介绍了统一订单服务架构的升级，将小程序订单服务提升为统一共享的订单服务，实现各种订单类型的统一下单和履单。通过调整系统架构，实现了订单库的合并和外卖系统模块的升级，形成了明显的层次结构，大大缩短了订单处理链路，提升了系统的可用性和性能。统一订单服务实现了统一的订单属性定义、统一的订单状态管理，以及订单数据的集中存储，为后续的BI分析和数据中台建设提供了帮助。 接着，文章介绍了中台架构的落地，通过构建一系列共享服务，实现各个渠道业务规则和业务数据的统一管理，最终落地了一个强大的业务中台，可以方便地扩展各个业务，实现企业整体业务能力的复用。通过共享服务和中台，企业内部基础设施和线上业务场景得以有效打通，为企业的全面数字化转型打下了良好的基础。 总的来说，本文通过具体案例向读者展示了如何在实践中推进架构从单体到共享服务、再到中台的改造过程，以及如何保证系统能够不断适配业务的升级。读者可以从中了解到如何通过共享服务和中台，实现业务能力的复用，并根据公司的业务发展阶段，选择合适的时机、合适的架构，以接地气的方式对系统进行逐步改造。
《架构实战案例解析》，新⼈⾸单¥59
全部留言(26)
- 最新
- 精选
雨霖铃声声慢老师，请教一下在文中这套系统中，用户的数据结构应该是什么样子，因为这里有小程序用户，有外卖第三方平台用户，那么用户系统的数据表是不是一张大表，包含了所有小程序和外卖用户需要的信息？如果是这样，后面在对接其他新业务用户，那么就要修改数据表扩展新字段，这好像不是很好，那么是不是可以认为内部有多个表存储这这些用户数据，然后订单里面在关联不同的用户id？作者回复: 用户基本信息表就一张，同一个用户就一条记录。 然后有一个用户渠道表，一个用户一个渠道一条记录，比如小程序渠道，公众号渠道，支付宝渠道就有三条记录。用户基本信息表和用户渠道表1对多关联。
2020-03-15212
，我对老师这次重构的理解是这样的,不知道对不对: 最开始外卖系统只负责订单管理,像收银和用户等服务都在第三方平台处管理。 然而在做小程序下单服务时,因为他是一个完整的业务流程,需要用户平台,收银平台,商品平台,所以延续以前对接第三方的做法,将收银服务,用户服务,等都放在小程序下单服务里,相当于将小程序做成一个第三方,对接外卖系统的订单服务。 之后随着业务范围的扩大,逐渐出现了各渠道的业务体系,应用端从PC端到App再到小程序,他们分别有不同的业务流程,但业务域大同小异。为了减少重复开发,规范业务流程,快速上线新应用,于是决定下沉基础服务,基于面向对象的方式,建立通用的业务平台,于是就有了中台 同时中台的上线,还必须满足这些假设: 业务范围大,渠道足够多,但是业务域大同小异,如果任由其发展,不同渠道的服务将会出现重复开发的现象,这样才有做成中台的必要性作者回复: 是的
2020-07-096
粗线条Jackie仔细研读了老师的每一期课程，受益匪浅。我们团队现有的Ecommerce平台，由最初的电话下单一体式应用，逐步演化成支持了PC Web、小程序、企业App和第三方外卖平台的SOA服务化架构。比对了老师的文中介绍，感觉目前我们的服务模块更像是一个"应用平台"+"业务中台"的结合体，供前端应用直接调用，向下与连锁门店和POS打通，为了适配业务的快速变化，现有服务模块的更新频次过高和模块间的紧耦合是比较突出的问题。后续，打算梳理和界定好业务的领域模型边界，把"应用平台"+"业务中台"尝试分离独立。 有两个小问题，请教一下老师，望指点迷津: 1. 老师文中提到了OMS系统，但在架构图中没有模块与之映射，通常情况下这个OMS与业务中台中的订单中心是同一回事情吗？ 2.由问题(1)引申，我某位在零售公司做架构的朋友，他们出于在天猫/京东开店的需求，采购了某外部商用的OMS产品进行私有化部署(需商用OMS公司做实施和二开)，并通过阿里接口与企业供应链WMS进行了打通。他们目前围绕这个商用的OMS做了一些二次开发，调用OMS的开放API可以批量导入更多小平台订单和手工单。请问这种模式下，这个OMS可以理解为业务中台的订单中心吗？还是仅仅做为一个抓单汇集的工具，企业中台需要重新做订单中心的规划建设？ 3."业务中台"的边界划分，领域驱动设计(DDD)相关知识是否必需？老师后续课程是否有会有涉及呢？作者回复: 赞一个，能够结合实际做很深入的思考。试着回答你的问题： 1. OMS是一个很重要的概念，说下我理解的OMS职责。当订单生成后，OMS就开始工作，比如对订单进行审核，决定订单流转到哪个仓库履行，交给哪个配送商进行配送，OMS是一个决策和调度中心，自己不具体干活。它和订单中心还不是一回事，一般说它在订单中心后面，会通过订单中心读取数据，并修改订单的状态。 #2，这个OMS看起来更像一个订单中心，不知它有没有提供后续订单如何处理的决策。 #3 业务中台，共享服务划分和业务紧密相关，DDD是一种方法和工具，可以使用它来划分，DDD概念拆的很细，给我们提供很清晰的分析思路，但也是有点繁琐，如果能够参考而不是照搬它那就最好。
2020-03-136- Geek_741b0e为什么对接三方外卖平台，是主动拉取？而不是平台主动推送呢。如果是为了对接成本或通用性考虑，主动推送也可以做成只配置推送目标地址，推送数据结构固定的方式。 想请教老师，外卖第三方主要是基于什么考虑，设计成主动拉取第三方数据？
作者回复: 三方平台的主动推送目前看只有在支付情况下，会主动回调外部系统，保证业务及时可靠。 一般来说都是要外部系统主动查询平台方，不然平台要保证推送的时效和可靠性，外部系统的情况差异很大(比如经常挂掉)，三方平台不想由他自己来保证这点。另外，也不确定外部系统的需求，有可能一天只要查一次就可以。
2022-05-013 
Geek_kevin老师,请教业务中台的订单和ERP的订单有什么关系? 如果是b2c, 促销订单非常多，均会进入ERP吗？ERP是单体应用，有性能瓶颈作者回复: 业务中台的订单你可以认为面向C端的接单系统，ERP订单是面向企业B端的履单系统，用户下单后，中台订单同步给ERP，这个同步不需要实时；ERP履单后，订单状态同步给中台订单。
2020-04-243
J.Smile老师，从功能上看，第二层的应用平台层是否可以省掉，直接由前端比如小程序或者app等渠道直接发起request调用中台呢？第二层主要作用是什么？作者回复: 前端直接调中台的服务不合适，主要有两个原因: 1. 对于外部过来的请求，我们需要提供一些非业务性的功能，比如签名验证，协议和参数适配（外部的rest和内部的rpc） 2. 中台只是提供基础业务功能，前端过来的请求是代表一个业务场景，需要同时用到多个服务的功能，比如前台下单，需要用到用户服务，商品服务，库存服务，订单服务等，这不合适直接在前端做功能整合。
2020-03-1353
暮色晨春我感觉老师举的这个例子也可以通过SOA架构实现，如果微服务模块数量没有那么多，业务应用互相数据调用交互更加频繁的话。 中台的建立构建在更大，服务场景更为复杂的企业或者政府机构中才更具有意义。譬如数字政府这类。 不知道想法对不对，如果把中台仅仅理解成为共享服务，那就可大可小了。作者回复: 你的想法对的，中台把基础能力抽象化和通用化，支持之上复杂的业务场景，以有限的基础服务支持无限的业务场景。
2021-06-012
美美这个还不能算业务中台吧，叫共享服务比较Ok吧作者回复: 中台本质是共享复用，然后是连接前后台。
2020-08-302
风中舞者老师，中台中心内部的微服务架构是否需要设计聚合微服务，这样会不会产生链路开销？还是推荐将服务编排统一做到应用层。作者回复: 对于通用的聚合服务，比如下单服务和商品详情服务（涉及商品服务，库存服务，价格服务），中台要提供，方便上层使用，考虑链路开销和可用性，服务调用层次不要太多，一般最多不超过三层服务。 应用->聚合服务->基础服务->系统服务（如短信通知）
2020-04-132
AngryApe
王老师您好，前面能力复用讲到的业务实体、业务流程、产品，但是这篇的架构图中只画了业务实体，没有出现业务流程对应的服务。我的理解中台更多的是业务流程的复用，是我理解的不对吗？作者回复: 业务流程偏定制，很难实现这个粒度的复用。 对于典型的比较通用的流程，可以有对应的聚合服务实现流程，但一般这样的聚合服务数量不会很大，大部分流程的逻辑在应用里自己实现。
2020-03-172
