在开始先容网关之前，首先先容两个观点BFF（Backend For Frontend）和网关，这两个观点及其随意马虎稠浊，以是首先借用Netflix和SoundCloud两个公司的系统架构层次蜕变来解释一下。
Netflix微做事分层架构(2017以及以前)
Netflix 2017年
这个分层架构共分四个层次
用户体验层，听说Netflix要支持超过一千种的不同设备体验，这个对Netflix技能团队特殊是前端团队是一个巨大的寻衅。网关路由层，Netflix利用Zuul网关作为做事路由层，同时兼具安全认证，监控，限流熔断等跨横切面功能。Zuul网关无状态以集群办法支配，前面依赖AWS ELB做负载均衡。边界API层，Netflix的裁剪聚合和适配层，也便是BFF层，将后端微做事，适配到不同的前端体验。在Netflix体系中，该层也称Edge Service Layer。微做事层，Netflix的核心领域做事，也称中间层(Middle Tier)做事。网关+边界API层(BFF)+一些前端做事(如安全认证，Playback干系做事，DRM等)，统一由一个Netflix的前端团队卖力，该团队也称边界工程(Edge Engineering)团队。
由于Netflix要应对处理的设备类型巨多，以是它们在边界层投入了大量工程技能资源，2017年前Netflix的边界API层(BFF)具有下面架构特点：全体边界API层(BFF)住在一个PaaS平台里头，称为Edge PaaS。Edge PaaS实质上是一个动态脚本平台(Dyanmic Scripting Platform)，支持利用Groovy等JVM脚本措辞，方便前端团队快速聚合裁剪后端微做事，并向前端设备暴露友好的API。之以是利用动态脚本措辞Groovy，紧张是考虑脚本措辞对前端开拓的友好性和生产率。Edge PaaS里头同时预置后端微做事的Java客户端SDK，方便Groovy脚本调用后端做事，同时对客户端进行Hystrix埋点，保障对后台微做事调用的稳定性。由于前端需求变更比较频繁，以是Edge PaaS里头的脚本一样平常更新也比较频繁，前端团队可以按需逐日更新，上传动态脚本即可。如果后端微做事有升级更新，一样平常须要升级Edge PaaS里头的客户端SDK，但是这个不是频繁操作，一样平常以固定周期（比如两周一个full release）发生，但是集成回归测试本钱还是比较高的。Netflix微做事分层架构(2018)
上述的Edge PaaS实在是一个单块架构，随着Netflix的前端业务变得更加繁芜，Edge PaaS也逐渐遭遇康威法则的约束，暴露出如下问题：
Edge PaaS里头同时耦合了前端聚合裁剪适配和后端API/SDK逻辑，当后端API有升级，一样平常须要升级Edge PaaS里头的客户端SDK，这种升级可能因不兼容和测试不充分，造成前端业务代码出问题。总体上前后端团队因升级、集成测试而造成的沟通折衷本钱非常大。所有面向用户体验的脚本逻辑都住在一套Edge PaaS里头，缺少隔离性，当某个团队的脚本有bug，很随意马虎负面影响到其它脚本。全体Edge PaaS也是一个大单点(Single Point of Failure)，严重脚本毛病或者流量洪峰可致集群宕机。前端脚本有上传快和动态加载等上风，但是本地调试未便利，很多依赖的环境(Edge PaaS + API/SDK)难以在本地开拓环境复制，造成开拓反馈效率低下，涌现问题排障困难。为办理上述问题，Netflix边界工程团队对Edge PaaS的架构进行了调度，从单块一分为二，新的架构如下图所示：image.png紧张变革是将边界API层分成两个子层次：
API聚合层，专注对后端微做事进行聚合，供应前端友好、抽象统一的API。API聚合层紧张基于Java+后台做事的客户端SDK实现。API聚合层还按业务功能进行分集群支配(API Sharding)。
设备适配层BFF，专注对API聚合层的做事进行裁剪和适配，供应给不同的用户体验展示。
设备聚合层采取对前端开拓友好的Node.js框架，各个团队的做事可以独立支配在容器环境(Netflix的容器云Titus)中，利用容器机制进行隔离，避免相互滋扰。Node.js+容器在Netflix称为NodeQuark平台。NodeQuark环境在开拓职员本地可以搭建，方便开拓本地调试。经由拆分，当前Netflix蜕变出一个五层的微做事分层架构，前面三层(用户体验、网关路由和设备适配层)专表明决前端开拓职员生产率的问题；后端两层(API聚合层和微做事层)专表明决领域抽象和运维监控稳定性问题。全体体系架构层次职责分明，初步办理了之前单块Edge PaaS的诸多问题，解放了生产率。结论
Netflix采取经典的微做事分层架构，前端体验->网关路由->边界API层(BFF)->后端微做事。这个分层架构可供一线企业实践微做事参考。近年，为了进一步提升前端研发效率，Netflix又将边界API层(BFF)拆分成两个子层次，设备适配层BFF和API聚合层。总体蜕变出一个五层的微做事分层架构。增加新的层次对付Netflix这种体量的公司来说，有其架构合理性，但一样平常企业没必要细分5层，采取上述经典4层架构就OK了。BFF层也未必要采取脚本nodejs之类，java/.net等强类型措辞开拓也OK，毕竟一样平常企业没有Netflix那么多的用户设备要处理。从Netflix架构体系演化我们可以看出，为了提升研发效率，它的架构经由很多层细分，额外分层会带来一定的性能丢失。但是对付前沿大体量的互联网公司，性能一样平常并不是其架构的紧张考量，灵巧性、可管理性和研发效率才是它们的紧张考量。性能的丢失一样平常可以通过云打算+水平扩展+缓存等手段来填补。SoundCloud
下面连续以SoundCloud公司为案例，通过一系列架构视图，展示SoundCloud微做事架构的分层组织办法。如果你阅读并理解了前面两篇文章的内容，那么就比较随意马虎理解本文的内容，所有本文的剖析会相对大略一点。
注，SoundCloud是一家德国网站，供应音乐分享社区做事，发展很快，Alexa天下排名已进入200位以内。
SouldCloud采取经典的三层微做事架构，用户体验层->边界BFF层->后端微做事层SoundCloud的BFF紧张分为四类：面向主站的Api-V2 BFF面向移动真个Api-mobile BFF面向嵌入页面场景的Api-embeded BFF面向开放平台场景的Public API BFFSoundCloud没有像Netflix那样的独立的网关Gateway层，它的BFF层领悟了网关功能+做事聚合裁剪和适配功能SoundCloud的微做事分层架构也是为了应对业务和技能寻衅，不断蜕变出来的。关于其内部微做事的演进进程，以及BFF在演进中扮演的角色。image.png
总结
Netflix的微做事架构有独立的网关层，SoundCloud则没有独立网关层，它的网关和BFF层是领悟在一起的。我认为这个和两家公司的业务体量和团队规模不同有关，Netflix业务体量更大也更繁芜，须要独立的网关层实现架构上的关注分离，保障研发交付效率。SoundCloud则业务体量和团队规模相对小，暂时还没有分解那么细。将网关和BFF领悟的做法，在海内很多公司也是这么实践的。SoundCloud对其微做事还进行了一层细分，包括根本做事+增值做事，这个该当是架构师根据须要，额外定义的一种架构分层规范，有助于研发职员更清晰理解架构，并遵照架构规范开展研发。Netflix/SoundCloud等大公司的微做事分层架构仅供参考，各家做法有差异，但是背后事理相同。架构师要理解其背后的分布式事理，然后灵巧运用，不可拘泥照搬。SoundCloud还给出微做事架构的一种更抽象的描述，如下图所示，微做事架构实质上可以理解成是一种分布式的企业操作系统内核是一个企业的业务领域根本做事第二层是BFF，将根本做事聚合裁剪适配，暴露面向不同用户体验的API第三层是面向不同用户体验(无线PC\开放平台等)的客户运用最外层是利用这个企业操作系统的用户API网关观点先容
API网关是一个做事器，是系统的唯一入口。从面向工具设计的角度看，它与外不雅观模式类似。API网关封装了系统内部架构，为每个客户端供应一个定制的API。它可能还具有其它职责，如身份验证、监控、负载均衡、缓存、要求分片与管理、静态相应处理。
API网关办法的核心要点是，所有的客户端和消费端都通过统一的网关接入微做事，在网关层处理所有的非业务功能。常日，网关也是供应REST/HTTP的访问API。做事端通过API-GW注册和管理做事。
常日情形下， API 网关要做很多事情，它作为一个别系的后端总入口，承载着所有做事的组合路由转换等事情，除此之外，我们一样平常也会把安全，限流，缓存，日志，监控，重试，熔断等放到 API 网关来做，那么可以试想在高并发的情形下，这里可能会涌现一个性能瓶颈。
其余，如果没有开源项目的支撑条件下，自己来做这样一套东西，是非常大的一个事情量，而且还要做 API 网关本身的高可用等，如果一旦做不好，有可能最先挂掉的不是你的其他做事，而便是这个API网关。
作者：介鬼
链接：https://www.jianshu.com/p/a8b0ca4932e1
