序
本文主要通過虛擬一個公司的業務發展，來觀看微服務網關和BFF的演化
v1版本的soa服務
在2010年左右有個叫highShop的電商互聯網公司成立了，他有一定的業務規模，內部已經完成了單體應用拆分，soa服務化，採用的是瀏覽器–>nginx–>服務端web應用–>soa服務，這樣的架構幫助highShop公司度過一段時期。
時間轉眼來到2012年，智能手機發展越來越快，無線應用開始起風，爲了能夠儘快上線自己公司的原生app無線應用，開始也想和瀏覽器一樣的方式，讓app通過nginx直接去調用soa服務，經過架構評審，這個架構是存在問題的。所存在的問題：
一: 無線app和內部接口服務強耦合，耦合包括域名耦合和接口耦合，任何一方的變化都可能對另一邊產生影響
二：每個暴露的服務都需要提供新的域名
三：內部服務直接暴露在外網非常的不安全
四：無線app段需要開發大量的聚合裁剪和適配邏輯（比如手機和pad屏幕大小的不同，還有比如消息格式的轉化，老的服務只返回xml不返回json）
v2引入無線BFF
BFF就是爲前端開發的後端服務，就是爲了針對前面所說問題做的一個代理適配服務，可以進行聚合裁剪和邏輯適配，向無線端提供友好和格式統一的api，方便無線設備接入和訪問後端服務。優點包括
一：無線app和內部服務不再強耦合，引入BFF這層間接，可以使兩邊都變得獨立些，無線app只需要知道無線BFF提供的統一接口和域名，不需要知道內部微服務複雜的域名和細節
二：只需要一個無線BFF域名，開銷小
三：內部微服務躲在無線BFF後面，不會暴露在公網上，會更加安全
四：聚合裁剪和適配邏輯可以在BFF上統一實現，可以實現app端大大的瘦身
v2版本在app上線早期確實取得了一定的成功，但是隨着業務規模和開發團隊的日益擴大，v2版本漸漸也暴露出了一些問題，比如：
一：單塊無線BFF堆砌了大量的業務線邏輯，變得越來越臃腫，升級維護也變得越來越困難。
二：單線BFF和多團隊之間出現了不匹配
三：隨着時間推移，代碼變得越來越複雜，技術債越來越多，開發效率不斷下降
四：單線BFF集羣出現宕機的話會引起整個無線應用不可用
V3 引入新的角色—網關
首先針對不同的團隊業務，引入不同的BFF，在nginx和多個無線BFF中間引入網關，這個網關專門負責跨橫切面功能，網關所做的事情包括：路由，認證，監控，限流熔斷，防爬蟲等等。這樣BFF開發人員就可以只需要開發交付相關的實際業務即可。
V4 較完善的微服務架構
隨着業務的不斷髮展，highShop公司需要做一個開放平臺給第三方開發者接入，h5技術興起的單頁web應用（比如微信分享）也如火如荼，此時就需要更多的網關來拆分這些業務。並且nginx其實和網關的功能有重合，並且網關是可編程的，所以可以用網關直接代替nginx，每一個網關指向一個BFF，由BFF再去訪問微服務。
最終的架構就是：
端用戶–》網關–》BFF–》微服務
以上就是一個常規公司業務在發展的過程中網關和BFF的演化，所以通常來說，網關和BFF都是架構演化的產物，當然我們需要根據企業的實際業務需要靈活的設計分層微服務架構，沒有最好的架構，只有最合適的架構！