網關和 BFF（Backend for Frontend）是微服務架構中的兩個重要的角色。我們先看一個公司的構架演進歷史。（攜程進化歷程）
第一階段這種調用直接用ngnix直接暴露，是有一定問題的卿城。
第二階段暴露的還有無限APP端還有聚合裁剪+邏輯適配的問題，就是說需要同時調用多個后端的接口，結果進行聚合隔节，要顯示產品分類和細節(jié)，就必須要調用2次接口胡桨，不能一次完成官帘。裁剪針對的是頁面窗口的大小瞬雹，手機和平板顯示的不同就需要去除一些東西昧谊。還有消息格式的適配，有xml酗捌、json各種呢诬。
bff是前端人員開發(fā)的后端服務。代理適配胖缤。bff架構有自己的優(yōu)點尚镰，也有缺點。
針對上述bff的缺點哪廓，演變出來網關和bff集群狗唉。
網關是解耦拆分的關鍵。這種跨橫切面的功能的抽離涡真，使得bff的開發(fā)也可以分業(yè)務流水線分俯，提供效率。
最后的一個架構哆料，逐漸廢棄了nginx這種不可編輯的反向代理的功能（這部分跟網關重疊）缸剪，全部由可編程的網關代替。
總結
1东亦、網關也是微服務嗎杏节？
網關是構建微服務基礎設施的一個核心組件，網關部署以后也可以說對外提供服務(反向路由，安全認證奋渔，日志監(jiān)控等)镊逝，它屬于技術基礎服務，但不屬于業(yè)務服務嫉鲸。
2蹋半、網關 、openresty或者kong充坑、Nginx之間的關系减江？
kong可以認為是專門針對API網關場景的升級版的Nginx，openresty是對Nginx的一種擴展捻爷，kong其實也是基于openrest擴展的辈灼。Nginx歷史悠久，成熟穩(wěn)定也榄，應用場景豐富巡莹。這些產品總體是互補的，不能簡單理解為替代關系甜紫。Openresty/kong都屬于可編程網關降宅。
3、服務分層具體是怎么理解的囚霸？
服務分層一般按照職能劃分：微服務層：提供基礎業(yè)務和技術服務腰根；BFF:聚合裁剪適配服務，面向各種端用戶體驗(PC, mobile, 第三方接入等)拓型；網關層：負責反向路由额嘿，安全，監(jiān)控等跨橫切面功能劣挫。
實際每一層和具體協(xié)議沒有嚴格對應關系册养，微服務可以用rpc，也可以http/rest压固，BFF和網關也可以支持rpc或者http/rest球拦。當然，微服務用dubbo rpc框架帐我，BFF轉成http/rest坎炼，網關再暴露http，也是一種架構方式焚刚。
4点弯、BFF 現(xiàn)在流行的說法是FaaS，網關可以由是 servless 方式實現(xiàn)矿咕，弱化 devOps抢肛？
BFF有很多玩法狼钮，之前看到過用動態(tài)腳本(可在運行時上傳動態(tài)運行)做BFF，也有嘗試用GraphQL做BFF捡絮，F(xiàn)aaS/serless做BFF還沒有怎么聽說熬芜，可能是一種新的嘗試，anyway福稳，BFF目標是幫助前端快速迭代涎拉。
5、是不是應該在bff與微服務層之間再加一個網關層?如何發(fā)現(xiàn)服務的圆？
?BFF層可以直接調微服務鼓拧，走基于注冊中心的服務發(fā)現(xiàn)即可。如果在BFF和微服務之間再加一層網關(或者nginx反向代理)越妈，相當于集中式負載均衡+反向路由季俩，也不是不可以，只是性能損耗會變大梅掠，而且維護成本會變高酌住。
比較典型的微服務分層方式：外部client -> 網關GW -> BFF -> Microservices。GW如何發(fā)現(xiàn)BFF阎抒？BFF如何發(fā)現(xiàn)Microservices酪我？這個可以借助注冊中心，例如Eureka且叁。如果在k8s環(huán)境中都哭，可以不需要注冊中心，因為k8s平臺本身就支持服務發(fā)現(xiàn)谴古。
BFF是聚合服務層质涛，是介于后臺基礎服務和外部端設備之間的一層稠歉，也能算中臺的一部分掰担，但只能算偏前端的一小部分。
6怒炸、使用nginx作為服務入口带饱，后端微服務為什么還需要很多域名呢，如果只暴露Nginx的ip阅羹，那么內部服務也不會暴露在公網上勺疼？
在v2版本中，nginx可以只暴露統(tǒng)一ip和域名捏鱼，然后根據請求path或者參數(shù)再轉發(fā)到后臺服務执庐，這樣nginx就相當于是一個網關。但再互聯(lián)網研發(fā)早期导梆，很多公司沒有把nginx當網關用轨淌，運維通常規(guī)定所有對外暴露服務必須獨立申請公網域名迂烁。
