5. 业务中台架构

1. 业务中台背景

      纵向布阵：互联网公司开始的团队架构做法，不用业务以相互纵向的独立线 保障各自快速发展。横向布局：但站在公司一号位整体横向看，觉得不同业务线有重复的能力或相似的业务玩法。于是从不同业务开发服务中，可以下沉一层组件能力叫业务中台，提供不同业务相互可以复用的技术组件和业务能力，帮助不同业务节省开发成本和快速创新。

2. 中台开发模式 

      首先业务中台框架: 不是一套技术框架而是一套业务框架, 为业务领域量身定制的框架，与业务领域的流程有紧密相关性。不同的业务领域可以设计出不同的业务中台框架，但思路大同小异。中台化框架设计的思路：沉淀共性组件和能力, 开放个性定制和扩展。分为下面几步:

2.1 业务流程化

在电商应用场景里, 一切业务场景皆可流程化, 例如：卖家发布商品场景，用户购物下单场景等。

a. 卖家商品发布:

商品发布流程简化分为: 包括 check、审核和发布上线等业务节点组成。

b. 买家交易下单:

      交易下单是最复杂的业务场景之一, 其几乎涉及到电商所有域的交互：卖家域、买家域、商品域、营销域、交易域和库存域和物流域等。交易流程简化分为：check、库存锁定、支付、库存扣减、履约发货等业务节点。

中台框架首先定义好流程，流程是由一系列上下游依赖关系的业务节点组成，其中业务节点之间可以是同步异步、多对一或一对多的驱动关系。在实现上每个业务节点有两个维度标识, 节点标识 id 和支持租户 id, 可以通过注解来标识，默认缺省值则表示支持所有租户。

另外，每个业务域都有自己标准的业务流程和节点, 可以沉淀了各个域标准的业务中台框架, 例如商品域 GPF 框架, 交易域 TMF 框架等；

2.2 节点标准化

      一套中台化框架,尽量是沉淀通用性的业务节点。当有新的业务租户需要接入时能直接复用。举个简单的商品发布流程: 主要包括 check 和发布持久化两个业务节点。check 业务节点: 由多个组件完成, 例如对商品核心属性价格、库存和标题、主图等多个组件 check 其合法性。

 a. 价格属性 check 组件: 校验商品价格的最小最大值准入值, 防止同类商品价格的市场恶意竞争；

 b. 标题属性 check 组件: 校验商品标题的合法性和商品相关性；

 c. 主图属性 check 组件: 审核商品图片的合法性，防暴防恐防黄防侵权等 ;

所以业务中台公共包: 定义了标准的业务流程和沉淀了标准的业务节点；例如如下的发布形式：

-gpf-sdk-1.0.jar    gpf-biz-flow-1.0.jar    gpf-shared-domain-1.0.jar    gpf-shared-node-1.0.jar

2.3 个性定制化

      对于新的电商国家站点的业务租户, 通用的业务能力仅用复用公共的标准节点和组件即可。但如有定制的业务节点，是如何开发的呢, 并且不会影响和污染现有的业务中台公共包。通常接口实现的形式对标准节点组件进行扩展开发。

例如: 不同政治宗教文化的国家, 对于文字的禁忌不同，导致标题属性 check 组件的黑词范畴不一致，需要进行定制扩展开发, 如下 lazada 泰国站商品 check 定制点:

a. 定制点开发：

@ExtensionProvider(key = "local-sku-check", tenantId = {"LAZADA_TH"})public class LZDQcCheckNodeExtImpl implements QcCheckNodeExt {    @Override    public ResultDO<Boolean> checkQC(ItemDO) {        #todo    }}

b. 业务流程调用: 

//商品check节点  ResultDO<Boolean> checkResult = ExtensionInvoker.find(tenantId, CheckNodeExt.class).checkQC(ItemDO);

业务流程的调用: 会屏蔽掉了不同租户的判断差异，根据租户名自动路由到各自租户的插件实现。

2.4 定制插件化

定制化开发的模式怎样的, 如何在全球多站点同时并行开发, 基础包与定制包, 定制包与定制包之间相互不影响的呢？每个站点(租户)以插件化的形式进行解耦性的开发。

所以在开发新的站点的商品发布时，仅需要实现一套定制的独立包，以插件化的形式集成和运行即可。例如如下不同国家站租户的站点插件包：

-gpf-apps-market-sdk      gpf-apps-lazada-1.0.jar    gpf-apps-taiwan-1.1.jar    gpf-apps-daraz-1.1.jar      gpf-apps-ae-1.2.jar

2.5 租户配置化

      同一个商品发布的应用名 gpf-i18n, 内部集成了数十种业务租户的扩展包(插件)时，在程序启动时, 又怎么知道需要加载和启动哪些租户的扩展包而线上生效呢？

答案: 配置化, 每个租户的流程和业务节点都是一套相互独立和可配置化的文件。中台业务框架在启动时，会识别配置的租户流程文件，进行加载对应租户的业务流程。

每个租户配置文件：定义了流程需要哪些节点及每个节点包含哪些定制组件。例如 TW 站商品发布流程配置样例:

a. 流程需要哪些节点

{    "name":"taiwan",    "submit":{        "nodes":[            "permitCheck",            "initAllCompDefaultValue",            "disableComp",            "check",            "submitProcess",            "commit",            "postcommit"        ]    }}

b. 节点需要哪些定制点

{    "name":"taiwan",    "comps":[        {            "compname":"sku",            "rules":[                {                    "key":"local-sku-check"                },                {                    "key":"sku-seller-sku-auto-generate-render",                    "desc":"页面sellerSku非必填"                }            ]        }        #省略    ]}

      当然上面的套台湾租户的定制配置, 也可以通过远程动态配置模板的方式进行开放化和商业化。各租户站点的运营仅需远程配置, 进程在启动时主动识别到各租户的配置，然后去找到对应的租户流程和节点扩展点包进行启动和加载。

3. 中台管理模式

3.1 管理问题

         当站在技术维度下沉业务中台，自然成立了业务中台部门，相对于业务前台。然后在同一个大的业务 OKR 框架下，和业务前台也会有各自的 OKR，中台部门侧重技术稳定性和横向扩展性，业务侧重快速迭代和小步快跑；所以实际实践中必定增加了隐形的协同成本。

        所以两个部门容易造成的关系：当业务需要快速发展时, 中台给业务的感觉需求永远在排期中；当业务稳定甚至停滞期时，业务多看业务中台部门一眼都是业务的不对。大家都是公司的人力成本部门, 但当业务出问题时，无法形成一股合力去破局创新, 雪花崩塌的时候觉得没有一片是无辜的。

3.2 管理解法

a. "低估"业务中台:  中台模式仅是一种新引入的开发模式和技术手段，可以规避传统多业务各自开发的烟囱式模式的复用和扩展难的问题。 不是一种组织架构和部门关系, 是一种生产力不是生产关系；不是创新的组织关系，仅是传统技术部门里面的新开发模式而已。 理想的中台模式：降低开发成本，同时减少协同成本。

b. L 型管理模式:

         技术和业务容易"打架", 特别是在业务稳定期或停滞期时，本质原因: 大家么有一起使力, 业务更在乎功能和效果, 效果出问题无法全身而退，而开发更在乎稳定性和效率也不会为此买单。

         人性角度：技术人本身也不想成为工具人，也有自己的业务态度和想法，希望参与业务发展的建议和决策。毕竟技术向上升的天花板也会走向业务架构。         规则设定：对业务技术同学做 L 型 OKR 的设定，横向对技术目标负责，同时纵向需要对各自负责的业务结果负责；L 型管理的设定对技术提出更高的要求，要求每位技术员工同时具备业务的 owner 意识，在跨部门合作时相互向前走一步。