面临的问题
架构模型
一般的互联网公司的架构都是一层层向上支撑的，最底层的技术架构是上面所有层的基础，而中间件是技术架构向上支撑的一块基石。
虽然从宏观架构看，几乎找不到中间件的位置，但实际架构实现的过程中几乎都离不开中间件的支撑。因为技术向上支撑需要不同的解决方案，这些解决方案通过不断的提炼并经由代码具象化后所得到的就是中间件。
理想中落地的样子
理想的情况下我们希望架构完成后研发能够尽快的接入和上线，且运行时所有的一切都在掌握中不会出现漏洞，后续还能够着手思考下次升级。
但是实际情况下业务研发会被PR、原型以及需求等约束，第一次接入可能还没什么问题，但是后续的架构升级在业务爆发时期研发就难以理会了。
就拿找刚来说，2014年的时候我们技术开发团队还只有20多人，相互之间有什么问题都可以快速解决，但是随着之后公司的发展技术团队规模越发庞大，同时业务规模的高速发展使得研发疲于应对，很难再去配合架构的接入。
面对这种情况，我们认为两个解决方案，第一是在组织上以行政命令的方式推进。第二就是微服务，在机器上部署各种“服务”。
观测工具用法
寻找领域内潜在的问题
经过与其他公司的同行沟通调研后，我们发现所有的公司在这方面的问题主要有两点。
首先就是有大半的时间在等待接入发布，因为每个应用的发布时间完全不可控，少则两周，多达一月，也有稳定无发布的。
另外还要花费一定时间在人员沟通上，这是个很实际的问题，就像之前提到的一开始人员较少时沟通起来还是很方便的，一旦成员增加沟通难度会逐步增大，而且构成层级也会越来越深，可能要从经理到组长再到开发，甚至还有测试。
最后就会发现只剩下了很少的时间在常规工作上，来关注运行情况、收集运行数据以及依据数据继续迭代改进。
铺路爪Pavepaws
Pavepaws是一款中间件产品，用来彻底解决技术架构的升级和落地问题。它有这样几个特点，首先是无感升级，能够进行自动化部署以及动态加载。其次是三方依赖隔离，能让多版本依赖共存无冲突。最后是运行时可控，可以随时升降级和bug热修复。
铺路爪核心组件
铺路爪有4个核心组件，Java Runtime，利用Java本身的一些特性来完成类的替换和监听等机制，然后是类加载的必经之路Class Loader。接下来是字节码转换器，用来在类被实际Runtime解析前对字段、方法等进行编辑修改，它其实也是Java Runtime提供的特性。最后是影子加载器，用来挂钩ClassLoader，拦截loadClass等方法实现自由的类加载逻辑。
具体实现
正常的类加载逻辑是先由Java Runtime发起loadClass，然后再到ClassLoader。一般ClassLoader都会有自己的加载逻辑，所以需要通过ClassFileTransFormer对ClassLoader进行基于字节码的方法切面，更改原先的加载逻辑，这样的做法不仅几乎没有性能损失，还可以对任意非原生类任意方法操作。
之前的类加载中loadClass会到达ClassLoader，而现在则是到自己的加载器。我们会在服务器上设置一个专门的目录，然后配合运维提供的文件推送服务把文件推送到服务器上专用的目录中，最后由影子加载器在该目录中寻找类，一旦找到就让自身加载器处理，否则交给ClassLoader处理。这样就优先实现了自己的资源查找逻辑，同时解决了前面提到的升级问题，这时只需要让运维配合就行了。
虽然基本实现了需求，但是还存在一个问题，即第三方包的版本选择。比如针对某个第三方包我们采用了一个版本，研发方面又是另一个版本，接入时就会发生冲突，总有一方会挂掉。解决这个问题最简单的做法是遵循基本的设计原则，让实现与接口分离。
进程内的微服务
前面提到过要解决接入的各种问题可以采用微服务的方式，为此我们实现了进程内的微服务，这不仅解决了因服务器上部署的微服务过多而产生的服务治理问题，同时让研发只需使用接口而不用关心内部实现。
配置实施流程，形成闭合
到目前为止通过技术手段已经解决了一半的问题，但是还存在人员的沟通问题没有搞定。所以为此一定要有配套实施流程，首先要与QA制定中间件升级流程，将中间件升级发布与业务应用升级发布隔开。其次与运维方面做好培训，用于在突发风险时，即时关停或组件降级。然后做好流控系统为了在风险发生时，能够即时通过调整策略进行止损。最后在有了QA流程后，研发这块主要在升级前做到沟通，协调时间避免与大项目冲突。
大路朝边，各走一边
最终我们实现了业务系统与中间件发布的独立，中间件升级不在受制与业务系统的发布周期，在任何环境都可以批量进行组件升级更新操作，而让研发无感知，同时众多的应用系统能够提供更全更多的运行测试，发现未知问题。
不再需要“脸”的时代
现在我们的时间分配已经发生了变化，首先要花费5%的时间来避开大项目发布，毕竟大项目上线时，人员比较紧张，不适合操作，万一发现问题也容易影响研发人员排查。其次在人员的沟通推进上的时间减少，不在需要重复解释各种问题，只要和业务线经理沟通确认好时间，最后统一邮件告知即可。这样算下来剩下的90%的时间就能用来进行常规工作了。