方案一 简易前后端分离
前后端分离原则，简单来讲就是前端和后端的代码分离，也就是技术上做分离，我们推荐的模式是最好直接采用物理分离的方式部署，进一步进行更彻底的分离。不要继续以前的服务端模板技术，比如JSP ，把Java JS HTML CSS 都堆到一个页面里，稍复杂的页面就无法维护。这种分离模式的方式有几个好处：
前后端技术分离，可以由各自的专家来对各自的领域进行优化，这样前端的用户体验优化效果会更好。
分离模式下，前后端交互界面更加清晰，就剩下了接口和模型，后端的接口简洁明了，更容易维护。
前端多渠道集成场景更容易实现，后端服务无需变更，采用统一的数据和模型，可以支撑前端的web UI和移动App等访问。
优缺点
优点：系统结构简单，部署方便，开发速度快。
缺点：没有解决大中型项目的代码解耦，没有解决系统安全稳定。
方案二 引入BFF层
把方案一的静态服务变成了应用服务器，把交互逻辑设计和业务逻辑设计分开、、。
无线App和内部微服务不耦合，通过引入BFF这层间接，使得两边可以独立变化：
后端如果发生变化，通过BFF屏蔽，前端设备可以做到不受影响。
前端如果发生变化，通过BFF屏蔽，后端微服务可以暂不变化。
当无线App有新的需求时，通过BFF的屏蔽，可以减少前后端团队的沟通协调开销，很多需求由前端团队在BFF上就可以自己搞定。
无线App只需要知道Mobile BFF的地址，并且服务接口是统一的，不需要知道内部复杂微服务的地址和细节。
聚合裁剪和适配逻辑在Mobile BFF上实现，无线App端可以大大简化瘦身（比较懒，用了别人的图）
优缺点
优点：结构清晰，系统易于维护，扩展方便。
缺点：开发量大，没有解决系统安全稳定。
方案三 引入BFF，网关
进一步解耦将路由，认证，监控，限流熔断，安全防爬等公共逻辑和业务逻辑交互逻辑分开，独立成网关层。
BFF按团队或业务线进行解耦拆分，拆分成若干个BFF微服务，每个业务线可以并行开发和交付各自负责的BFF微服务。
网关（一般由独立框架团队负责运维）专注跨横切面(Cross-Cutting Concerns)的功能，包括：
路由，将来自无线设备的请求路由到后端的某个微服务BFF集群。
认证，对涉及敏感数据的API访问进行集中认证鉴权。
监控，对API调用进行性能监控。
限流熔断，当出现流量洪峰，或者后端BFF/微服务出现延迟或故障，网关能够主动进行限流熔断，保护后端服务，并保持前端用户体验可以接受。
安全防爬，收集访问日志，通过后台分析出恶意行为，并阻断恶意请求。
网关在无线设备和BFF之间又引入了一层间接，让两边可以独立变化，特别是当后台BFF在升级或迁移时，可以做到用户端应用不受影响。
网关承担了重要的角色，它是解耦拆分和后续升级迁移的利器。在网关的配合下，单块BFF实现了解耦拆分，各业务线团队可以独立开发和交付各自的微服务，研发效率大大提升。另外，把跨横切面逻辑从BFF剥离到网关上去以后，BFF的开发人员可以更加专注业务逻辑交付，实现了架构上的关注分离(Separation of Concerns)。（比较懒，用了别人的图）
优缺点
优点：结构清晰，系统易于维护，扩展方便，较方案二前期开发量大，后期开发量减少。
缺点：系统复杂，运营成本高，不适合快速创新项目
