IBPS V2与IBPS V3框架对比
一、V2单体架构局限性
- JSP开发模式，必须是全栈开发工程师才能胜任。对于人员要求较高，成本太高了；
- 开发无法专注业务，需要解决前端样式又要做后端业务控制，会对后期的维护造成很大风险；
- 表单模块是没有办法模块化的，扩展性太差，无法多人并行扩展表单控件；
- 集群、负载方案支持相对比较困难；
- 模块耦合性较高，无法对单独的业务扩容增加负载能力，比如流程用得较多，需要整个应用扩容；
- 对外发布接口时还必须重新写一套接口，增大开发/维护工作量；
二、V3分布式架构优势
1)前后端分离模式
1. 为优质产品打造精益团队
术业有专攻，通过前后端分离，让前后端工程师只需要专注于前端或者后端的开发工作，有利于编写出高质量的代码，培养开发工程师独特的技术特性，然后构建出一个全栈式的精益开发团队。
2. 提高工作效率，分工更加明确
前后端分离的工作流程可以使得前端专心前端，后端关心后端，两者开发同时进行，提高开发效率，页面的增加和路由的修改也不必再去麻烦后端，开发更加灵活。
前端可以借助mock系统模拟接口完成前端开发。
3. 降低服务器负载，系统性能提升
通过前端路由的配置，我们可以实现页面的按需加载，无需一开始加载首页便加载网站的所有资源，服务器也不再需要解析前端页面，在页面交互及用户体验上有所提升。
4. 增强代码的可维护性
前后端分离后，应用的代码不再是前后端混合，只有在运行期才会调用依赖关系，并且分层明确，应用代码变得整洁清晰。
前端代码全面模块化，所有功能代码都是独立的，且抽离很多公用组件，可快速实现特定功能。
后端接口只需维护一套，即可适应各端的调用要求，无需重复维护接口。
5. 增强应用的吞吐能力
前端使用nginx静态容器，后端每个微服务都是原生支持集群，可动态扩容，大大增强了应用的负载/吞吐能力。
2)后端分布式架构
1. 后端业务独立
后端按业务模块划分应用（代码、数据库），每个应用独立维护（更专注），集群原生支持，扩容特别方便（同机扩容只需改端口即可、不同机扩容直接复制部署文件即可启动），大大提升吞吐能力，更好的保证系统的稳定性；
2. 增强运维可行性
配置中心组件的出现，可支持在线动态修改应用配置并及时生效，还支持环境、版本等高级功能，再也不需要忍受修改一个配置项就得重启应用的痛苦。
日志监控组件，可以让查日志、定位问题更便捷，不需要到服务器拷贝日志再查阅。
链路监控组件，可以让我们更了解我的应用健康状况，为我们提升性能提供非常必要的数据支持。
灰度发布（金丝雀），可以实现接口逐步上线，大大降低了风险。
3. 增强数据安全性
引入了网关这个组件，非内部后端应用都需要从网关去访问数据，未授权的调用都是不允许对数据进行访问/操作。
数据控制粒度到接口级别。
