所有框架..的微应用微服务最终会在框架启动中动态加载。
那么大家是否会有疑问，支付宝这么多工程师团队和工程量，微服务微应用之间仍需要协同配合，那么支付宝发布一个版本是不是很麻烦？
2
支付宝的敏捷发布与稳定性保障
传统的开发模式下大家势必互相影响，假如你提交的代码闪退了或者业务异常了，那么你业务关联的开发测试一定会受到影响，一般我们称这样的开发模式是「串行开发，互相等待」。而支付宝的工程解耦，代码解耦能给工程效能带来多大的效益？接下来我们来聊一聊支付宝的「并行开发模式」。
支付宝每次发布一个版本，都是由若干个 bundle 工程组成。若干个 bundle 工程合并在一起叫基线，每次发布版本之后，参与下一个版本迭代的同学都基于这个稳定的基线做独立的开发。而之所以能够支持独立开发，归功于我们介绍的工程解耦和代码解耦。
比如这张框架图，余额宝业务、ofo 小程序、蚂蚁森林、网络库等可以同时开发测试完成之后进入某一个大版本发布即可，如果存在依赖关系，，只需要找和自己相关同学一起进发布，正因为如此支付宝做到了每天都有很多业务进基线，每天都在同时迭代业务。
既然发布确保了效率，那么支付宝又是如何保证发布稳定性的？
传统的开发模式是：开发测试、全量发版，然后进入下个版本的迭代，继续开发测试修 bug、全量发版。这样做有几个缺点：
1、如果测试阶段未发现缺陷，很可能导致线上用户出现大规模异常；
2、出现大规模异常没有修复能力，造成用户损失；
3、随着业务的迭代，业务越来越多，功能越来越复杂，卡顿现象频出，用户体验变差；
