【p1】Spring：通过介入bean生命周期以及自定义注解来简化代码结构

（转载请注明作者和出处‘https://fourthringroad.com/’，请勿用于任何商业用途）

过去几年在不少项目里也用到了spring框架，主要使用的还是IoC和mvc框架的相关能力。使用的动力就是简单，快速：写几个restful的controller和业务逻辑处理器再套个ORM框架，就能够让服务跑起来。尤其对于一些非关键路径上的服务后端，能够在非常短时间内让服务上线。

我同意SpringMVC引入的一系列组件大大简化了我们对Servlet的开发，同时spring的生态系统确实功能完善，但是单独讲对于Bean的管理这块我是认为spring有些臃肿的，相比之下我更偏向使用一些更轻量级的DI框架，比如像Google的Guice。Spring对bean的生命周期管理太冗长了，它有很多的hook，有很强的定制化能力，但是伴随的是学习曲线高，同时代码复杂度也有可能变高，可读性差。这样带来的一个问题是，使用它可能违背我‘简单，快速’的初衷。我的代码可能需要一个不了解spring的人评审或者debug或者在未来接手，而我使用了一些不太好理解的hook，那么对于后者来说就是一个头疼的事情。

总结来讲，我认为对于偏业务的开发人员而言，他们需要的就是工具，如果需要他们去阅读源码，无法纯粹把工具当作黑盒使用，那么这个工具的顶层设计就有一些问题。所以我在做业务的时候基本上只使用spring常用的注解和基本的bean管理功能，用此将初始化过程与其他代码模块解耦。

但是如果我是给业务方服务的开发者呢，则情况会有所不同。我最近接手的一个项目是一个负责托管配置的中间件服务，公司内很多第三方服务都会调用，利用这个服务存储/获取自己的配置。类似的‘配置中心’在很多公司都存在，相比于hardcoded的配置（存在配置文件或者代码），显然这种集中化管理方式更好管理更易修改；同时相比Spring Cloud Config那种在应用启动阶段拉取一次配置的机制，多数配置中心也具备动态更新配置的能力。我之前在Amazon工作也接触过一个叫SDC的动态配置管理服务。当配置发生改变的时候，相关客户端可以观察到变动，具体可以是配置中心发布一个事件或者客户端周期性的检查拉取变动。假设采用后者，时序逻辑非常简单：

不考虑可靠性和性能的话，业务逻辑基本上可以抽象成简单的CRUD。如果服务只是提供REST接口，或者更进一步，一个会周期向Config Server发检查拉取请求的简单Client的话，我们来想想用户还额外需要做些什么？

假设用户以某一种格式在Config Server托管了一份配置文件（xml，properties，json，yaml或者其他常见格式），用户希望将它map到运行时的一个bean对象：

{"foo":"xxxx", "bar":123}
<=>
ConfigBean {
    String foo;
    Long bar; 
}

这个ConfigBean的配置内容在业务处理流程中会被使用到，比如foo可能是某个商品的title，bar代表某个商品的优惠策略。那么用户侧应用的启动过程则应该是：

同时，因为ConfigClient会后台周期同步最新的配置，所以当新配置被拉取后，需要注册回调函数去对ConfigBean实例的属性进行修改。

我们大部分用户都在使用spring/springboot构建业务应用，对于我们提供的client，上述是大多数用户都需要重复编写的逻辑，如何在将用户侧的代码进行简化？我们回到用户需求分析，用户的需求只是希望能够将ConfigBean和一份配置文件进行映射，至于是否采用C/S模式，http还是tcp，rest还是rpc都不重要，只要用小的开销给他同步就配置数据就ok了。

那么最简单的配置方案是否可以简化成这样：

1. 用户在spring config里面配置服务信息：

<配置中心标签 服务地址=“xx”应用ID=“xx” 配置仓库=“xx”.../>

2. 在代码里面通过注解建立ConfigBean与具体配置的映射

@配置专用Annotation（配置ID=“xx” 解析格式=“json/xml/yml...”）
@Component
ConfigBean {
    String foo;
    Long bar;
}

隐藏上面提到的流程中的所有细节，用户只是根据自己直接需求进行非常简单的配置。显然用户体验会得到了很大的优化。

这就需要利用spring预留的hook，介入相关bean的生命周期。