金融级IT架构:数字银行的云原生架构解密

4.8.1 基础开发框架 基础开发框架是一套用于分布式架构应用系统的快速、敏捷研发框架，拥有一整套全面的技术栈，能自动解决依赖下载、应用部署、健康检查、运维监控等研发效率相关问题。研发人员使用该基础开发框架，可将精力集中在业务代码编写上。基础开发框架还能实现对其他常用中间件的集成管理，通过独立可插拔的集成方式，对集成的中间件提供统一易用的编程接口，节约了开发时间，降低了后期维护成本。 开发框架在某种程度上也可以称为应用框架，或者一定程度上可以看作应用容器，当然这不一定完全正确。然而应用框架和应用容器总是成对出现的，比如早期的EJB（Enterprise Java Beans，企业Java Beans）技术，EJB可以看作开发框架，但是需要运行在对应的EJB容器之上，例如Jboss、WebLogic、WebSphere等。由于EJB技术的臃肿，后面出现了像Spring、Guice这样的优秀的轻量级应用框架，配套的也不再是重量级的EJB容器，而是像Tomcat、Jetty这样的轻量级Servlet容器。 从EJB到Spring、Guice的演进带来的是业务研发效率的极大提升，然而随着互联网的快速发展，业务的复杂度与日俱增，原本单一的应用架构开始向分布式架构演进，分布式架构转型过程中业务系统无可避免地需要去集成众多的分布式中间件，以达到分布式架构改造的目的。然而中间件的接入是存在一定复杂度和理解成本的，这会对研发效率造成一定的负面影响，原本提供单一IOC（Inversion of Control，控制反转）、AOP（Aspect Oriented Programming，面向切面编程）、MVC（Model View Controller，模型-视图-控制器）功能的Spring无法继续满足业务需求。面对挑战，Spring框架也在快速发展。近些年来产生的SpringBoot面对当前场景给出了不错的解决方案。与原先的Spring相比，SpringBoot省略了之前大量烦琐的XML配置，自动装配机制可以快速集成原本需要大量配置才可以支持的能力，而SpringBoot Starter的出现进一步扩展了这种自动化装配能力，大量的第三方中间件组件、框架以Starter形式提供相关能力支持，业务如果需要引入每个中间件产品对应的能力，只需要依赖对应产品的Starter即可，再也不需要繁杂的配置以及理解成本，而且可以形成统一的接入规范，可以对公司技术体系的演进和发展起到很好的促进作用。 那么一个优秀的应用框架到底是什么样的呢？这里提出一个说法——“技术价值观”，可以理解为，一个企业是否采纳某种技术的评判标准，技术价值观一定程度上左右了这家公司的技术发展和演进方向。和其他价值观不同，大部分企业的技术价值观都是一致或相似的，或者说有一个大家公认的标准，这个标准其实可以理解为每种技术在业界的主流发展和演进方向，比如SpringBoot、Kubernetes，它们代表了应用框架和调度的主流技术价值观。网商银行内部的应用框架同样也遵从这个主流的技术价值观，而且在这之上还有着大量的技术实践和创新。内部大量使用的开发框架一共有两个，一个是构建在OSGi（Open Service Gateway Initiative，开放服务网关协议）容器之上的框架技术，内部称之为SOFA 4，对应的运行容器内部称之为CloudEngine，另外一个开发框架称为SOFABoot，SOFABoot构建在SpringBoot之上，是对SpringBoot的有效扩展和优化，同时也是内部特定需求下的产物。这里重点介绍一下SOFABoot，因为流行的SpringBoot框架更为大家所熟知。 就像前面提到的，SpringBoot的自动装配机制和Starter扩展机制已经给研发效率带来了极大的提升，那为什么还要创造一个SOFABoot框架？它又有哪些优势？其实这里并没有从头创造一个全新的框架，本质上SOFABoot就是SpringBoot，但是进行了相关功能的丰富和扩展，这主要涉及以下几方面。 1. 类隔离的支持 类冲突无疑是Java开发者“*大的痛”，有过几年经验的Java开发人员应该都有较为丰富的类冲突解决经验，规范的第二方、第三方依赖可以通过releaseNote进行版本升级，而某些管理不善的依赖只能靠版本试错，或者逐个反编译精确查找版本。更有某些场景中的间接依赖和直接依赖产生了版本冲突，解决这种冲突往往需要耗费大量时间，甚至在某些场景中不得不去推动相关依赖方进行升级才能解决，严重阻碍了业务的迭代效率。而SOFABoot自身集成了强大的、轻量级的类隔离框架可以完美解决这类问题，通过简单的配置即可完成对冲突类的隔离，让你可以专注于业务代码的开发。 2. 多模块隔离 大型项目的开发需要有良好的模块划分方案，然而传统的模块划分均是以人为规约的形式进行的，而这在实际运行时是很难有约束力的。事实说明，在一个项目迭代的过程中很难长期遵守开发规约，因为一个长久的项目往往会经历多个研发人员，每个人对研发规约的理解又是存在差异的，久而久之，逻辑的模块划分将无法起到很好的作用。说到模块隔离，大家可能会想到OSGi，但是OSGi本身比较复杂，并不能为大部分互联网公司所接受，而SOFABoot提供了一种轻量级的模块隔离方案，每个模块都是单独的Spring上下文，每个模块可以暴露哪些服务能按照规范进行配置，未暴露的服务其他模块是无法进行调用的，而且独立的Spring上下文设计给后续服务拆分提供了极大的便利，当前的一个模块只需要少量的调整就可以作为一个单独的项目进行开发部署。想一想如果是以逻辑模块的方式进行划分，项目拆分会多么困难和复杂，因为内部服务也可能被多个其他模块所依赖，光拆分前的梳理和改造就要花费大量的时间，成本无法估计。 3. 部分功能扩展 这里主要说两点，一是SOFABoot提供了Readiness检查能力，SpringBoot提供的HealthCheck只能反映当前系统是否被监控，但是无法反映是否已经做好了可以接受请求的准备。这一点其实是很重要的，比如应用的平滑上下线就比较依赖这个功能，如果在应用还没达到可以接收请求的状态之前就把请求发过去，就会引起应用请求的报错，而对于一个拥有大量容器的应用而言，为了提升发布速度，单个发布批次会包含较多的容器，如果这里处理不好，就会引起服务调用方的抖动，甚至对业务造成影响。 二是支持了日志空间隔离，依赖日志空间隔离可以方便有效地对日志进行隔离管理，比如网商银行内部的中间件系统通过接入日志隔离把每个产品的日志都单独输出到指定的目录，有效防止了日志的相互污染，对问题排查和监控指标的接入都提供了极大的便利。 除了上面提到的两方面，SOFABoot为了支持内部的某些特殊场景，还增加了很多不错的功能，这里不再一一赘述。除了SOFABoot这样优秀的应用框架，开发框架还包含了很多高效的支持工具。比如拥有完善的IDEA研发插件，利用该插件可以快速生成各类型项目代码，安全快速地进行相关组件的升级，快速进行应用代码部署和自动化测试等。统一的技术栈维护了应用的基础软件依赖，让我们可以方便快捷地进行统一的版本升级和安全问题修复。 *后再回到SOFABoot框架本身，SOFABoot为应用集成内部的中间件能力提供了极大的便利，通过制定一套标准的注解和XML XSD规范，应用只需要使用标准的注解或者XML元素进行配置，即可集成相关产品能力，整个过程完全屏蔽了分布式和单元化架构的复杂度，让研发人员更加专注于业务逻辑，而不用关注底层框架的复杂性。所以说开发框架并不仅仅是应用框架和应用容器，也不仅仅是某一种技术，而是一整套用于提升业务研发效率的工具，是一个完整的研发生态圈。