深度解密京东中台底层支撑框架
2、底层支撑框架分析3、前台包热部署设计原理4、前中台隔离原理5、前台业务身份设计原理6、思考本文大约1.7万字，阅读需要13分钟。
导读：近几年，除AIGC外，软件领域相关比较大的变化，就是各相关业务领域开始如火如荼地建设中台和去中台化了。本文不探讨中台对公司组织架构涉及的变化和影响，只是从中台化演进的思路，及使用的底层支撑技术框架进行分析探讨，重点对中台及前台协作涉及到的扩展点及热部署包的底层技术细节，结合京东实际落地情况，对涉及的核心技术框架进行源码初探分析，探讨技术框架的考虑点，拓宽大家的思路，欢迎大家审阅。1、序言
中台及其建设，区别于单体应用建设及微服务建设，最大的差异在于中台建设有一个较为独特的概念，即前台角色。中台建设并采用标准协议，开放了一系列标准丰富的能力供前台角色去编排、扩展使用。从外部的视角来看，其实看不到中台和前台，单纯还是功能交付，外界的感知没有太大的差异；从产研的视角来看，功能交付是中台能力叠加一系列前台个性化能力的结合物，职责上期望通过中台底层能力建设和前台个性化能力增强，两方独立开发，再通过底层技术支撑框架来将两方能力进行结合，期望达到中台、前台角色分工清晰，独立交付，提升交付速度的美好愿望。
分析前提：我们只聚焦与中台底层支撑框架，其他如中台的业务领域切分、领域建模等内容暂不涉及。需要注意的是，本次原理探究，是从使用人员及业务应用的角度出发，而非从真正对Matrix设计者的角度出发，对Matrix原理的探索难免会存在以偏概全的毛病，对其全貌也必然会存在描述不准确的情况。加之框架底层也在不断丰富和完善，很多技术内容存在不断变更和发展，本文描述的内容在短时间内也会存在描述不再准确的情况。但是好在基本原理应该是准确的，内容描述的过程中，如有错误，欢迎大家指正。
本文重点对底层支撑框架涉及的几个核心技术点进行展开：前台包热部署设计原理、前中台隔离原理、前台业务身份设计原理。3、前台包热部署设计原理
在中台化的实施路径上，伴随的节奏一般为：中台能力改造升级-->中台开放标准扩展能力-->前台使用标准扩展能力完成个性化开发-->前中台发布集成。其中发布集成有2种可选的方式，一种是中台和前台采用手工半自动化的方式进行集成，另外一种是中台和前台使用全自动的方式进行集成。全自动的方式，就免不了需要将前台的功能包，采用“热部署”的方式部署至中台相关的应用系统中。
本文对前台包发布、热部署的技术方案及思路进行探究，让我们的读者了解其设计理念。这样以后在工作中遇到类似前台包发布相关的问题，亦或者后续有机会使用并研究其他类似的技术框架，均可以做到举一反三，心中了然。【3.1、热部署基本原理】在开始介绍之前，假定我们作为底层框架的设计方，可以尝试回答下方的三个问题，并与后面给出的结果进行对比，看看与自己预判的答案是否一致。若不一致，本文应该对你有些帮助，可以细细品鉴；若一致，那么恭喜你，说明你的技术功底相当扎实，对相关的原理及实践了解透彻。问题：1）使用前台扩展包，在发布平台操作完成（完成推送、生效）后，应用端进行扩容上线，扩展点包是否可以自动拉取加载、自动挂载运行？2）使用前台扩展包，在发布平台操作完成（完成推送、生效）前，应用端进行扩容上线，扩展点包是否可以自动拉取加载、自动挂载运行？3）使用前台扩展包，在发布平台对部分容器完成前台包灰度推送，但没有触发生效，此时对这些容器执行重启操作，推送的前台包是否会挂载运行？4）在测试环境亦或是其他环境，一不小心删除了热部署包路径及对应的文件，会有什么问题？如何解决？在开始回答上面的问题之前，我们要先来给大家介绍下PaaS化下几个相关的名词，及这些名词背后的相互作用的关系。可以先看下如下的架构设计图（笔者自己理解，与官方理解可能存在一定的差异）：
前文介绍的热部署操作完毕后，前台扩展包，就可以正确在中台相关的容器中完成部署了加载了。那么此处问题来了，前台和中台会共用某些相关的类，如何保障执行的安全性及可靠性呢。那么就不得不提到了类隔离机制，和隔离机制背后的原理：双亲委派模型。
所谓“双亲委派模型”，从上述代码可以看到，先检查类是否被加载过（第6行），若没有加载则调用父加载器进行加载（第11行），若父加载器为空则默认使用启动类加载器进行加载（低13行）。可以看到，若都失败，则调用当前类加载器进行加载（第24行）。是不是和上述找“爸爸”的描述，比较契合？在Matrix框架下，中台相关的逻辑和前台相关的业务包，是由2个独立的ClassLoader类分开管理，其中前台相关的业务包，是由名为com.jd.matrix.core.classloader.BizClassLoader的类进行管理。我们先来看下这个类的具体逻辑：protected Class<?> loadClass(String name,boolean resolve)throwsClassNotFoundException{synchronized(getClassLoadingLock(name)){// First, check if the class has already been loadedClass<?> c =findLoadedClass(name);if(c ==null){long t0 =System.nanoTime();try{if(parent !=null){c = parent.loadClass(name,false);}else{c =findBootstrapClassOrNull(name);}}catch(ClassNotFoundException e){// ClassNotFoundException thrown if class not found// from the non-null parent class loader}if(c ==null){// If still not found, then invoke findClass in order// to find the class.long t1 =System.nanoTime();c =findClass(name);// this is the defining class loader; record the statssun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);sun.misc.PerfCounter.getFindClasses().increment();}}if(resolve){resolveClass(c);}return c;}}
从代码逻辑可以看到，Matrix提供的类加载器，其实是破坏了“双亲委派模型”，破坏点从13行开始，若当前类没有加载，没有调用父加载器进行加载，而是使用了jdkClassLoader去加载；同时若开启了Matrix包屏蔽的策略（21行），则会使用中台的ClassLoader去加载。此处破坏的妙处在于：前台包可以找到并使用中台包对应的相关类；但是中台包不可以找到并使用前台包对应的相关类。粗俗点可以描述为：大哥不知道小弟，但是小弟在大哥的开放区域，可以有限了解大哥。从此处也可以看到，Matrix对于类加载的管理与控制，与OSGI等标准规范相比，安全性等管控方面要松弛得多。从严格意义上来，此类管理的方式，安全性其实并不足，若中台开放的区域过大，加上前台包被有心人动手脚，其实是存在安全隐患，并防不胜防。我们可以看到，Matrix会结合容器侧的spring配置里的exportClassConfig属性，使用自定义的类加载器(BizClassLoader)去加载垂直业务包里的类，主要有两个核心内容：1、对于不同的前台业务包里的类，分别使用BizClassLoader的不同实例去加载，对于垂直业务包里的自己开发的业务类，即使不同的垂直业务包中存在全限定名相同的类，但因为加载他们的BizClassLoader实例不同，不会出现冲突问题，类隔离的要求能够得到满足。2、对于exportClassConfig这个属性配置的相关类（包含但不限于：中台提供的sdk包所包含的类、基础RPC框架类），不会由1里所提及的自定义的classLoader的实例去加载，只会由同一个类加载器（加载中台容器业务类的appClassLoader）去加载，以此来保证中台容器调用扩展点实现时参数类型校验的一致性。从上方的信息和代码中，我们可以看到， 假定前台和中台存在相同包名、相同类名的类，在执行前台扩展点的时候，分为前后2个步骤：1）执行前台包扩展点的业务身份匹配逻辑；2）执行前台包扩展点的实际业务逻辑。2者的区别，主要在于后者有一个主动切换当前类加载器的逻辑。也即在步骤1时，当前的类加载器为应用容器业务类的加载器；步骤2时，当前的类加载器切换为独立的类加载器。5、前台业务身份设计原理public class BizClassLoader extends URLClassLoader{public BizClassLoader(URL[] urls){super(urls);}protected Class<?>loadClass(String name,boolean resolve) throwsClassNotFoundException{Class<?> clazz =null;clazz =this.findLoadedClass(name);if(clazz !=null){return clazz;}else{try{ClassLoader jdkClassLoader =ClassLoaderFactory.getJDKClassLoader();clazz = jdkClassLoader.loadClass(name);if(clazz !=null){return clazz;}}catch(ClassNotFoundException exception){}if(ExportClassManager.match(name)){clazz =ClassLoaderFactory.getInternalClassLoader().loadClass(name);if(clazz !=null){return clazz;}}try{clazz =this.findClass(name);}catch(ClassNotFoundException exception){}if(clazz ==null){clazz =ClassLoaderFactory.getInternalClassLoader().loadClass(name);}return clazz;}}protected Class<?> findClass(String name) throws ClassNotFoundException{returnsuper.findClass(name);}}
中台和前台合作的巧妙之处，在于中台开放了多种标准的、可扩展的能力，前台基于自己的不同的业务身份实现多种个性化业务场景。即一种中台的能力，可对应多个前台扩展部署包。那么运行时，中台如何知道应该使用哪些前台包呢？
这里就不得不提业务身份这个概念了，在中台的建设思想中，每个前台包都有自己独立的业务身份。中台系统运行的时候，依次匹配前台部署包，并选择业务身份命中的前台包执行相关逻辑。业务身份的识别方式：Matrix业务身份有2种识别方式1、前台包手工编写识别业务身份。即在前台自己在元数据（Annotation）定义自己独立的parserClass ，识别方式，由前台业务系统手工编写识别。这种方式的好处是纯手写代码，加上前中台组合review的时候，一般不会出现功能问题及性能瓶颈。但是也会存在很大一个弊端，即对某个业务而言，是不是属于自己的业务身份，是前台自己说了算，在一般情况下是没有问题的，但是如果前中台reivew的机制失效了，前台基于某些特定的原因，将前台的业务身份识别方式调整扩大或缩小，会导致影响的业务范围也会对应的增大或者缩小，影响范围非常不可控。从中台建设初期来看，本来预计这种方式，以后一定会废弃掉。从过去几年的实践经验来看，这个地方预判错了，这种形式目前仍然是主流的形式，只是不同的系统对同一个业务身份的识别，逻辑千差万别，在串联业务流程的过程，确实会存在较为痛苦的情况。
业务身份命中基本流程：此处其实无需多言，业务身份命中的逻辑其实隐含在前面介绍的前台包业务逻辑实际执行的地方，只是Matrix框架在执行逻辑前，创造了一个类似会话（Session）的概念，在会话中去对业务身份是否命中执行相关匹配逻辑，实际就是对相关的前台业务包执行fiter方法，判断评估业务身份命中。在会话（Session）中对前台包依次执行filter去匹配业务身份。存在的风险：1）部分前台包业务身份识别逻辑较重，会导致整体中台逻辑运行缓慢，存在性能风险；对应的建议解决方案：业务身份识别逻辑一定要轻量级；2）目前Matrix框架默认仍然只是捕获了Exception类别的异常，对于Throwable级别的异常仍然是没有捕获的。部分前台包业务逻辑存在偶发性问题，执行业务身份匹配filter逻辑时，若抛出Throwable级别的异常，会导致其余业务身份的前台包也无法执行。这真是一粒老鼠屎，搞坏一锅粥。业务身份基本原理：Matrix实际以业务身份来管理业务包与扩展点，同一个业务身份，可以命中一个垂直扩展点（代号为Y）和一些水平扩展点（代号为X）。针对同一个待识别的业务规则，比如同一个sku或者同一个订单而言，不可以命中多个业务身份，若实际命中了多个业务身份，Matrix会限制只会命中其中的某一个业务身份对应的扩展点方法。也即对这种业务场景，Matrix即使会命中多个业务身份的fiter方法，但是实际只会执行其中唯一的一个业务身份对应的扩展点方法，具体命中的业务身份，初看有一定的随机性，具体顺序参加下方的描述。业务身份的顺序：从Matrix遍历业务身份处理扩展点的业务逻辑来看，业务身份的顺序至关重要，排名靠前的业务身份，其对应的扩展点方法执行的几率会大于排期靠后的业务身份。经排查，Matrix对业务身份排名的逻辑由业务身份（App）的三个属性来共同确定，具体为：priority（由大到小）、version（由大到小）、code（由大到小）。在满足上述排序规则的前提下确定业务身份的优先级。假定业务上存在如下场景：对同一个订单或者同一个sku的场景，同时可命中二级业务身份和三级业务身份，理论上业务期望三级业务身份被命中到。但是很不巧，priority、versionSpec等值设置不合理，导致二级业务身份被命中到出现与预期不一致的情况。对于此类场景，我们就需要制定严格的代码规范，对前台业务侧限定其priority、version、code的数值，确保业务逻辑的正确性。重点提示：业务身份的定义与使用，是业务系统出现问题最多的地方。业务身份在Matrix中是一个很重要的概念，其设计理念期待整个业务身份是一颗节点互不交叉的树，但是在实际业务执行的时候，经常会存在业务身份重叠的情况。设计定义前台包的人员，属于两个不同的部门，属于两拨不同的人，2者很难意识到业务存在交叉重叠的情况，已经发生多次线上业务跑飞了出现与预期不一致的情况，后来花了大力气来解决的场景。常见出现问题的案例举例供大家参考：我们提供了一个扩展点供前台业务使用，其中一个前台包的业务身份是大家电，另外一个前台包的业务身份是五星。结果在实际业务上，同一个sku或者同一个订单，既是大家电的业务，也是五星的业务。对于这种场景，如何解决呢？这个问题留给大家来思考。Matrix对业务身份排名的具体代码如下所示，代码逻辑参见BizCodeSpec.compareTo方法：#{ClassStart}import java.util.*;#{Package}public class #{ClassName} {#{MethodInfo}}#{ClassEnd}#{PackageStart}import #{TypeName};#{PackageEnd}#{VarStart}#{Type} #{Var}=(#{Type})context.get("#{Var}");#{VarEnd}#{executeStart}public boolean execute(Map context){#{VarInfo}return #{Express};}#{executeEnd}#{allStart}private boolean all(#{Var} ){Iterator iterator =#{Collection}.iterator();while (iterator.hasNext()) {#{ItemType} #{ItemVar}=(#{ItemType})iterator.next();if(!(#{Right})){return false;}}return true;}#{allEnd}#{anyStart}private boolean any(#{Var} ){Iterator iterator = #{Collection}.iterator();while (iterator.hasNext()) {#{ItemType} #{ItemVar}=(#{ItemType})iterator.next();if((#{Right})){return true;}}return false;}#{anyEnd}
最佳实践：1、一般而言，我们在设计并编写前台包的时候，包名应该具有前台独立的业务属性，也即包名和中台的包名应该有一定的区隔。对于可能会和中台包冲突的业务场景，我们可以在框架中进行类名或者包名的排除。2、中台开放给前台的包名范围，应该尽量限定在最小范围，防止前台不经意的恶意行为。除这2点外，可能还存在其他各类场景对应的最佳实践，有待我们进一步探索。6、思考public int compareTo(BizCodeSpec o) {if (o == null) {return -1;} else if (this.priority != null && o.priority != null) {int ret = o.priority - this.priority;if (ret != 0) {return ret;} else if (this.versionSpec != null && o.versionSpec != null) {ret = this.versionSpec.compareTo(o.versionSpec);if (ret == 0) {ret = o.bizCode.compareTo(this.bizCode);}return ret;} else {return 0;}} else {return 0;}}
不管是中台化也好，还是去中台也好。核心思路，都在于如何以技术，服务好我们的业务。中台化，亦或者是品类差异化思路，均为交付过程中选择使用的差异化工具。但是工具背后，必然隐藏着对应的落地技术关键点，而这些关键点，道理都是相通的。作为技术人员，持续思考，如何从漫天繁花中，找到底层最核心的症结，不断打磨丰富我们的产品，提供优质的服务，值得我们持续探索。