一、序章
典型的工程师接触到的包括APP应用程序体系结构、传统的MVC分层体系结构和事件驱动体系结构。 这是我第一次接触业务体系结构这一概念，是在来到商品发布团队之后。 产品发布是一个业务属性很重的系统，内容包括淘宝、天猫、盒马、魅力惠、汽车、虚拟、SCM自营、苹果、村淘、公益
、教育等多项业务(业务多的可以包围地球一周)的商品发布功能。 前半年对“业务结构”还很陌生，随着逐渐熟悉业务，我们研究了框架代码，对我们的业务结构框架有了清晰的认识。
二、单体应用的痛点
在GPF框架(我们团队的业务体系结构框架)诞生之前，上述所有业务都安装在单个APP应用程序中。 每次增加业务，我们的应用工程就更加庞大，软件熵变大，代码维护变得困难，很多类都有几千多行。 不同的业务代码混合在一个类或一种方法中。
以商品陈列时间的组件为例，当我们承办教育行业时，我们的代码会做如下更改(为了清楚起见，我们将源代码改为了伪代码)。
每次接受新业务，都会添加很多if else式的补丁代码。 严重违反了开闭原则。 这个写法是典型的代码不好的味道。 承担的业务越来越长，系统就越来越庞大。 无论是承接新业务还是对旧业务进行变更，都会越来越麻烦。 马老师说：
“抱怨的地方越多，机会也就越多”。
这句话也适用于软件工程。 修补旧代码，以解决单个APP应用程序体系结构的弱点：新业务。 实现业务代码强大功能的GPF框架问世。
新体系结构的核心主张：业务隔离。 更具体地说，代码隔离、轮廓隔离、运行时过程隔离。 围绕业务隔离这一核心诉求，其实我们做了更多。 这将在后面叙述。
三、如何做到业务隔离
为每个业务id创建模型并分配业务id。 业务模型包括用于此业务的组件、扩展点和流程部署。 所有业务id构成业务id列表。 每个业务模型都有业务标识逻辑——中的当前用户请求是否命中业务。 当用户进来时，重复此路由算法以确定唯一的业务id。
的业务身份id确定后，还将确定相应组件的集合、扩展点的集合和流程的放置。
1. 组件
每个业务的发行页面由十几个到几十个组件组成。 它具有平台通用的组件，如商品标题、商品条形码、类别属性、销售属性和sku。 垂直业务有垂直业务的定制组件，例如公益业务有捐赠金额的组件，公益业务以外的业务不能使用该组件。盒马业务有商品所属的店、管理机构等新零售行业的特征组件。
“业务所需的组件=业务定制组件所需的平台通用组件”
2. 扩展点
这里的扩展点可以理解为插件(plugin )
扩展点
组件扩展点
流程扩展点
扩展点与组件一样，是一种具有平台通用扩展点和业务定制扩展点的配置。
'业务所需的扩展点=业务定制扩展点所需的平台通用扩展点'
3. 隔离方案
综上所述，可以看到平台通用的扩展点和组件是代码复用的，不满足以前的代码隔离要求。 解决方法也很简单。 在系统初始化期间，为每个业务id新建通用组件和扩展点，并创建merge自己的自定义组件和扩展点。 因此，在内存中，每个业务id都有一组运行时独立的完整组件和扩展点。 当系统实际运行时，它获取组件和扩展点对象，而不是代码。 这样，代码被复用，业务数据被隔离。 这是最合理的方案。
四、如何做到灵活易接入的中台化产品
仅仅实现业务代码去耦是不够的，商品发布系统必须制作台湾化的产品。 我们的目标之一是快速支持新业务的访问，让新业务一起建设，让新业务的同学独立通过GPF框架访问他们的业务。 为了实现高可扩展性并快速访问新业务，这里必须提到“微内核插件化”技术。
微内核技术：
微内核是内核的紧凑形式。 通常，与内核集成的系统服务层是分离的，可以根据需要添加插件，从而提供可扩展性和高效的APP应用环境。 使用微内核设计升级系统。 只需用新模块替换旧模块，无需更改整个操作系统。
微内核技术源于操作系统，但在互联网产品“平台化”的轩然大波下，该技术得到了广泛的应用。
GPF微内核暴露了一系列服务提供商接口(SPI )，根据不同的业务需要实现这些插件接口。 系统启动时，程序将扫描所有实现SPI接口的插件，并集成到系统中向外部提供服务。 如果需要访问新业务，可以通过定义业务id和实现所需的SPI接口来完成业务访问并实现业务隔离。
**
五、结语*
体系结构不是设计出来的，而是进化出来的。 进化型架构才有生命力。 从Xsell到GPF1 GPF2 GPF3，每个版本都在解决上一版本的痛点的同时前进了半步。 一个产品要走平台化的道路，业务体系结构必须是标准的。