大家好，又见面了，我是你们的朋友全栈君。如果您正在找激活码,请点击查看最新教程,关注关注公众号 “全栈程序员社区” 获取激活教程,可能之前旧版本教程已经失效.最新Idea2022.1教程亲测有效,一键激活。
Jetbrains全系列IDE稳定放心使用
一、序章
一般的工程师接触到的是 应用架构 ，传统的MVC分层架构、事件驱动架构、微内核等等。第一次接触业务架构这个概念是在来到商品发布团队之后。商品发布是一个业务属性很重的系统，承载了诸多业务（业务多的围起来可以绕地球一圈）的商品发布功能。头半年对“业务架构”还是很懵逼的，随着慢慢的熟悉业务，研究框架代码，才对我们的业务架构框架有了清晰的认识。
二、单体应用的痛点
在***框架(我们团队的业务架构框架)诞生前，上述的所有业务都在一个单体应用里承载。每新加一个业务，我们的应用工程就会变得更加的臃肿，软件熵变大，代码难以维护，不少类都有几千行以上。不同的业务代码都杂糅在一个类或者一个方法里。
以商品上架时间组件为例，当我们承接教育行业时，我们的代码会做如下的改动（为了方便理解，我把源码改成了伪代码）：
private int initStartTime(){
if("业务身份" == "**"){
return “放入仓库”;
}else {
return “立刻上架”;
}
}
每承接一个新的业务，我们都要添加很多if else式的打补丁代码。严重违反了开闭原则，这种写法是典型的代码坏味道。当承接的业务越来越多时，系统变的越来越庞大。不管是承接新的业务还是对老的业务进行改动，都越来越麻烦。马老师说：
抱怨越多的地方，机会也越多。
这句话对软件工程同样适用。为了解决单体应用架构的痛点:新增业务就给老代码打补丁。实现业务代码给力功能的***框架面世。
新架构的核心诉求：业务隔离。更加具体一点，代码隔离，配置文件隔离，运行时流程隔离。围绕业务隔离这个核心诉求，其实我们做了更多的事情，这个后面讲。
三、如何做到业务隔离
我们给每个业务身份建立一个模型，并配一个业务id。业务模型包含这个业务要用到的组件，扩展点，流程配置。所有业务身份构成一个业务身份列表。每个业务模型都有一个业务识别逻辑——当前用户请求是否命中该业务。用户请求进来时，都会走一遍这个路由算法，以确定唯一的业务身份。
唯一的业务身份id确定后，对应的组件集合，扩展点集合，流程配置也就确定了。
1. 组件
每个业务的发布页都由十几个到几十个组件构成。这其中有平台通用的组件，比如说商品标题，商品条形码，类目属性，销售属性，sku等全行业都需要的业务组件。垂直业务有垂直业务的定制组件，比如说公益业务有捐赠金额的组件，除了公益业务，其他业务不可能用到这个组件；盒马业务有商品所属门店，管理机构等新零售行业特征的组件。
业务需要的组件 = 业务定制组件 + 需要的平台通用组件
2. 扩展点
这里的扩展点可以理解为插件（plugin）
- 扩展点
- 组件扩展点
- 流程扩展点
扩展点同组件一样，也是有平台通用扩展点和业务定制扩展点构成。
业务需要的扩展点 = 业务定制扩展点 + 需要的平台通用扩展点
3. 隔离方案
通过上述可以发现，平台通用的扩展点和组件是代码复用的！并没有达到之前的代码隔离要求。解决方法也简单：系统初始化时，每个业务身份id都会new一份通用组件和扩展点，并merge自己的定制组件和扩展点。于是，内存里，每个业务身份id都会有一套运行时的独立且完整的组件和扩展点集合。系统真正运行的时候，取到的是组件和扩展点的对象，并不是代码。这样，代码复用，业务数据隔离。这才是最合理的方案。
四、如何做到灵活易接入的中台化产品
仅仅达到业务代码解耦并不够，商品发布系统要做一个中台化的产品。能够快速的支持新业务接入，让新的业务一起共建甚至新业务的同学独立的在XPF框架上接入他们的业务，是我们的目标之一。要做到高扩展，快速接入新业务，这里不得不提到“微内核 + 插件化”技术。
微内核技术：
微内核是内核的一种精简形式。将通常与内核集成在一起的系统服务层被分离出来，变成可以根据需求加入插件 这样就可提供更好的可扩展性和更加有效的应用环境。使用微内核设计，对系统进行升级，只要用新模块替换旧模块，不需要改变整个操作系统。
微内核技术源于操作系统，但是在互联网产品“平台化”的大浪潮之下，这个技术得到了广泛的应用。
XPF微内核会暴露一系列的SPI(Service Provider Interface)接口，不同的业务按需去实现这些插件接口。系统启动时，程序扫描出所有实现了SPI接口的插件，并集成到系统中对外提供服务。当新业务需要接入时，定义好一个业务身份，同时实现需要的SPI接口，即可完成业务的接入，同时做到业务的隔离。
五、框架与业务：相辅相成
我们总希望框架有一天能稳定下来。分层架构和事件驱动架构都可以做到，唯独业务架构做不到。因为业务架构支撑的是一个平台，平台会不断的有新的业务进来。新业务有新的特点，有些新业务特性是是共性需求，我们把共性需求下沉到框架层面。具备相同业务特性的新业务再进行接入时，工作量就小了。同时，随着业务的不断反哺架构，架构从最初只能接入单薄业务逐渐壮大，可以轻松应对新业务的接入。于是，前端应用试错的耗时和人力成本都得以降低。“业务不稳定” 是造成 “业务架构不稳定” 的根本原因。如果某一天业务架构稳定了，也就意味着这个架构可以退出历史舞台了。
普通的架构，业务是单方向依赖框架的。唯独业务架构不一样，业务反向滋养框架，相互成就。XPF(General Publish Framework)框架目前已经是第三个大版本，XPF4, XPF5一定在路上。集团还有很多的商品发布业务（围起来可以绕地球两圈）等着我们去支撑。
六、 结语
架构不是设计出来的，是演进而来的。演进式架构才有顽强的生命力。从Xsell 到 XPF1 XPF2 XPF3, 每个版本我们都解决了前一个版本的痛点同时往前看半步。一个产品要走平台化道路，业务架构一定是标配。
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/183694.html原文链接：https://javaforall.net
