容器技術越來越成熟，應用領域也越來越廣，容器的應用促進了微服務的快速發展，也使旨在提升效率和融合開發運維的DevOps迅速落地。容器、微服務、DevOps就像孿生兄弟，相互依存，相互融合和發展。隨著容器平臺的建設落地，微服務越來越火，越來越多的公司已經開始采用或者正在考慮采用微服務架構。但微服務架構應用通常是分布式的，一個業務應用通常是由眾多的微服務編排而成，服務之間的調用、通信、安全認證、訪問控制、負載均衡、限流限額等需求也帶來了運維的復雜性，實現微服務治理是個不小的難題。如果再把微服務部署于容器云平臺，則會更加復雜。目前也有不少的廠商或者公司嘗試開發微服務治理平臺，不管基于gRPC或者Istio等，都不是一個成熟的方案。基于我們銀河證券容器云平臺建設和微服務管理治理的實踐研究，我們提出了使用成熟的API網關產品來實現容器云平臺微服務治理的方案，更快、更便利的實現微服務的治理，特別對于傳統行業IT技術實力相對有限的情況下，避免投入大量的人力財力去做基礎平臺的研發，更可避免項目失敗所導致的時間、發展機遇的錯失。

微服務治理當前面臨的問題

微服務化帶來了很多好處，比如通過將復雜單體系統切分為若干個微服務來分解和降低耦合性，而且每個微服務功能單一，實現快捷，使得這些微服務易于被小型的開發團隊所理解和維護，相對于單體系統降低了復雜度。然而微服務也帶來了很多挑戰，微服務架構是分布式架構，單個微服務簡單，眾多的微服務分布式應用的復雜性難以回避，眾多微服務之間的通信、微服務事務處理、微服務的拆分、服務注冊、服務發現、負載均衡、路由、監控、AB測試、金絲雀發布、限流、訪問控制等等都帶來了挑戰。特別微服務部署于容器云平臺，基于當前現狀如何治理好微服務是一個棘手的具有挑戰性的問題。

1. 常用方案的不足

服務治理的問題由來已久，服務治理也是一個很大的話題。在SOA ESB的時代就有很多探討，微服務化盛行之后顯得尤為重要。目前比較流行的微服務開發框架是SpringCloud，國內也有用Dubbo的，但Dubbo遠遠達不到實際的要求。SpringCloud雖然提供了很多組件，但都是半成品，作為開發人員還有很多工作需要做，最終服務組件的質量往往取決于開發人員的能力，不同開發人員所實現的微服務可能千差萬別；其次，SpringCloud對代碼有侵入性，如果以后要更換開發框架，需要重寫很多東西，甚至可能不得不推倒重來，代價高昂；再者，Java語言的特異性，如果要采用其他開發語言如Go/Python等開發的微服務或者不全是Java微服務，SpringCloud可能就無能為力，無法統一管控。微服務治理更是難以實現。

2. 服務網格（Service Mesh）的不成熟

Service Mesh服務網格目前是很火熱的存在。很多人鼓吹其為第二代微服務，不過在我們看來更多是概念炒作，Service Mesh服務網格描述的是微服務網絡，所實現的是服務治理能力而不是微服務。其定義是一個用來連接、保護、控制和觀察微服務的工具。Service Mesh 服務網格的核心思想就是“流量代理”，通過一個個SideCar“代理（Envoy）” 來為微服務轉發和接收所有流量，而不用去修改微服務代碼，通過控制這些SideCar代理，就可以實現微服務連接、訪問控制、注冊發現、安全認證、負載均衡、限流熔斷、監控等等一系列服務治理相關功能，使微服務的代碼不再需要去實現服務治理邏輯，簡化了開發并提高了敏捷效率。說到底其是服務治理工具，談不上第二代微服務。
作為Service Mesh的一種實現，Istio 1.0剛剛GA（General Availability）,雖然鼓吹說可以上生產，但依然需要時間和實踐的檢驗。服務網格會隨著微服務數量的增加而成倍的增加復雜度，這也是需要進一步檢驗的方面。

3. 微服務治理的復雜性

微服務架構一定程度上是為了解決伸縮性問題、運行效率問題和開發效率問題。

單體應用功能是集中式的，難以滿足伸縮性、也就是擴展要求。微服務是分布式的，伸縮性是其最重要價值所在；

單體應用隨著功能的累積，越來越難以更新和維護，而微服務專注于只提供一種功能，可以橫向和縱向兩個維度伸縮，開發簡單，開發速度也會大幅提升，與其他微服務共同編排組成一個或多各業務應用系統，形成微服務生態系統；

單體應用包含了所有的功能，這些功能往往是緊耦合的，缺乏彈性，運行效率往往也不高，微服務則獨立自治而輕量，運行簡單而快捷。把一個單體應用拆分為微服務往往是處于伸縮性和效率方面的考慮。每個微服務的效率提升帶來整個業務應用的效率提升。但隨著微服務量的增加，比如何管理好這些微服務并使其高效則并不容易。

另外其彈性伸縮要求非常適合容器云平臺的彈性伸縮特性，因此往往和容器平臺結合，部署于容器云平臺，這也更增加了微服務治理的難度，涉及的東西越多，復雜性越大，需要考慮如何更好的利用容器平臺的優點來簡化復雜性。

以微服務架構實現的業務應用，通常是分布式的，有眾多的微服務組件，彼此有依賴性。一個微服務簡單，但有眾多的微服務相互關聯就復雜化了，每個業務應用可能有多個服務編排而成，每個服務又可能部署不同數量的服務實例。單體應用不存在的微服務治理問題也由于微服務生態系統中眾多的微服務和微服務實例，以及承載微服務的基礎設施容器云平臺，隨著微服務量的增加而使其運營和運維復雜化，使微服務治理復雜化。

4. 敏捷性需求

引入任何一個產品或者一種技術或者一種方法，目的都是為了快速的解決面臨的問題，也就是要求敏捷性。新產品新技術新方法如果無法作到敏捷，也就失去了采用其的重要價值。采用微服務一個重要的原因也效率問題。在應用微服務提高開發效率和運行效率的同時，不能帶來服務治理等的復雜化。雖然微服務分布式架構和部署于容器云平臺增加了運維的復雜性，復雜性同時帶來了風險，但復雜性并非我們設計的初衷，風險更不是我們想要的。化繁為簡、簡化運維、控制風險、提高效率、實現敏捷是基礎的要求。
常用的開發框架都是半成品，需要很多的工作量，如果能實現通過規則或策略配置就可以實現微服務的大部分治理能力，比用SpringCloud等去實現要敏捷的多。微服務實現關注的應是業務邏輯，不應該去關注服務治理的問題。所有非業務邏輯的功能盡可能的交給服務治理層來實現，這樣才能具有敏捷性。所謂術業有專攻，做到因為專業，所以敏捷！

5. 安全挑戰

速度和敏捷不應該損害安全性，任何時候安全都是第一位的。安全也是微服務可用性的一個重要指標。如果客戶端直接以非安全和非管理的方式連接和調用實現的后端微服務，那是存在嚴重的安全隱患的。要訪問這些后端的微服務需要以受管理的方式訪問，不能無序，需要保證安全。
微服務生態系統擁有眾多的組件微服務，這些組件服務相互依存，微服務與微服務生態就像一個人之于人類社會，接觸面越大、關系網越復雜、接觸量越多，安全挑戰就越大。

要保證安全，就像人類一樣筑座城池，把自己保護起來。但完全保護起來不跟外面接觸也不行，需要開個城門，建個關口，實現對外交流。每個城池就是一個微服務，城門就是API，在城門口實現進出安全檢查、管控，就類似于我們說的微服務API網關。一個國家可能有很多座城池，是一個小生態，要保護整個國家可能需要建立起一條長城，對外交流也是開個關口，這就實現了統一的微服務安全管控。多個國家形成一個大生態，就是整個微服務生態系統，通過API網關來實現安全管控。

6. 服務接口標準化要求

微服務架構的挑戰是實現服務的標準化，以及保證服務的可靠性和可用性。車同轍、書同文、量同器、貨同幣。微服務實現可以是不同的語言、不同的協議、不同的名稱、不同的字段類型等，這些微服務之間如果要交互，就面臨著眾多的轉換問題，類似于曾經的系統集成問題，所以后來出現了ESB，但ESB并沒有從根本上解決問題。所以不管微服務是怎么實現的，微服務接口API需要標準化。
一種實現方式是在微服務前面加個Adapter適配器，由Adapter來實現轉換。對微服務來說它有了API網關，其可以承擔其Adapter的職責，因此API網關層是可以提供標準化的接口的。

7. 擴展性、負載均衡、路由、限流等需求

成功的可伸縮微服務生態系統需要完善且穩定的基礎設施的支撐。微服務的彈性擴展性通常是基于完善的容器云平臺基礎設施服務。彈性并不是我們說起來這么簡單。微服務的彈性依賴于基礎資源的彈性，依賴于資源調度的能力，依賴于服務伸縮的策略等。微服務的彈性伸縮可以基于容器平臺的彈性伸縮能力，但伸縮策略并不是固定的，不同場景需要配置不同的伸縮策略，特別是在收縮時，需要保證業務請求已經被處理完成且不會有新的業務請求到來。這就需要靠負載均衡路由策略等實現。每個微服務對于不同的用戶可能會采用不同的服務策略，提供不同的業務流量，這面臨這限流限額等需求。另外在微服務出現異常情況下，能實現異常遷移、錯誤修復、容錯等，或者達到某種熔斷閥值暫停服務。
這些能力固然可以在容器云平臺上和其他工具集成來實現，但會使整個平臺運維復雜化。復雜化不是我們設計的初衷，所以需要換個思路。

微服務治理思路

SpringCloud等微服務治理涉及眾多的組件需要自己開發搭建，這是一個挺大的工作量。為每個微服務都實現一個API網關，來對外提供統一的接口，實現注冊、轉換、路由、限流、負載均衡等能力又使API網關職責過重，使微服務生態復雜化。如果把每個微服務的這些非業務邏輯能力要求都提取出來，放在一個公用的API網關上去實現，使每個微服務專注于其業務邏輯的開發，就會簡化開發，提升敏捷性。公用的統一的API網關上實現微服務的注冊、轉換、路由、流控等，映射為一個標準的API對外提供服務。這樣既滿足了微服務開發敏捷性的要求，也是簡化微服務治理的需求。微服務所有的安全認證、訪問控制等從微服務本身剝離出來，通過統一的API網關組件定義策略配置來實現微服務的安全管控和服務治理能力。

我們希望微服務不會隨著量的增加而帶來運維和治理的復雜性，也希望能快捷的接入不同協議不同格式不同類型的微服務業務應用和業務服務，這就可能需要一個統一的層次來完成這些能力，而不用每個微服務都實現一個sidecar Gateway；也可以容易的使用新技術替代舊技術。這就是統一的API網關服務。如果我們滿足了這些要求，微服務架構將會帶來敏捷、可靠和高可用，提升效率，并減少風險。

API網關

實施微服務可能不可或缺的一個很重要的組件就是服務網關。網關，顧名思義，網絡關口，擔負著安全檢查、認證授權、路由分發、流量控制、熔斷保護等重要的職責。API網關，那就是API的網絡關口、通道，是整個微服務平臺的咽喉，API請求應答必經之路。為了利用容器云彈性伸縮等特性，結合微服務的優點，部署微服務于容器云平臺，則API網關的實施部署則會顯得更復雜些。
API網關（API Gateway）是一個服務器，是調用服務的唯一節點和請求應答出入口。API Gateway封裝內部系統的架構，并且提供API給各個客戶端。通常情況下它還需要實現其他功能，如認證授權、訪問控制、路由、負載均衡、緩存、日志、限流限額、轉換、映射、過濾、熔斷、注冊、服務編排、API管理、監控、統計分析等等。
從API網關的能力來看，我們可以理解其重要性。一夫當關，萬夫莫開。其不但是整個服務系統的安全屏障，也承擔著很多服務治理的能力。所以實現或者選擇一個好的API網關，是建設容器云和微服務體系中一個至關重要的事項。這也決定了API網關的部署，要盡可能的減少接觸面。
微服務對外可以提供統一的接口API，可以在API網關層通過對API的治理實現對微服務的治理。

API網關在微服務治理中的價值

很多人對于微服務API網關也都有比較深入的介紹。一個重要的原因是微服務通信、微服務重構、協議轉換等的需要，API網關還可以提供更多能力實現微服務治理。

1. API網關提供了一個穩定可重用接口層

API網關首先隔離了內部和外部服務，所有外部服務通過API網關所暴露的標準API訪問內部服務，提供了相對穩定的API接口，隱藏了服務的內部實現細節，保障后臺服務的安全性。
這方面有眾多的應用場景：
（1）. 一個服務可以在API網關映射為不同的API接口，相當于提供了多種的服務能力。也就是提供了接口便利的重用能力。
一個后臺服務通過API網關可以映射為多個不同的API接口，以滿足不同的客戶端調用需求，比如有個服務實現了按照業務類型查詢業務數據，可能某個客戶就是特定的業務類型，在API網關就可以映射一個API，使用固定的業務類型值，服務于特定用戶。

不同API可以滿足不同SLA需求，節約后端開發成本。
（2）.只要API不變，對應的服務只要是兼容性的更新，都不影響客戶端對該API的調用，提供了接口的穩定性。

API相對穩定，API實現是不固定的，Client /Server都可能是不固定的，但API層是穩定的。API（Application Programming Interface，應用編程接口）則提供了一個穩定的接口層。接口的實現可以變，只要接口不變，調用接口的應用就不需要改變。
同時對外訪問控制由網絡層面轉換成網關應用層面，減少變更流程和錯誤成本
（3）.不同服務定義為不同的API，非兼容更新的服務定義不同的API。不影響原來的接口版本。

（4）.隔離內部和外部服務，隱藏了服務實現細節。業務應用只需要關注API，不管API對應的服務是什么，由誰提供。

實現內外隔離，隱藏了服務的內部實現細節，保障后臺服務的安全性。也降低客戶端和服務的耦合度，阻斷服務依賴，服務獨立運行，通過網關層實現按服務映射，服務編排，縮減外部調用頻次，提升訪問效率。
隔離內外部服務，也為微服務的擴展提供了便利，在應用層面可以利用容器的伸縮特性實現應用服務實例的自動彈性伸縮，實現應用服務的高可用。

2. API網關是平臺的安全屏障

API網關提供安全和保護能力，阻止客戶端應用以非安全和非管理的方式直接訪問API，保護開放的應用。這是API網關最重要的能力之一。隔離內外服務也就減少對外暴露的服務可能，以增加系統安全性。在API接口層實現授權認證、訪問控制、防范威脅和OWASP漏洞、防御性緩存、通過SSO和統一身份管理來等來提高安全性，為應用程序、移動和IoT提供端到端的安全機制。也可能需要在API網關實現流量控制、限額、過濾、熔斷、服務優先級控制、超時處理、負載均衡等機制來保護應用服務的安全。
安全第一，就像我們的社會交通一樣，第一要保證安全的條件下快速通過。這也是在實現或選擇API網關時首先要考慮的問題。
安全涉及的問題也比較多，API網關層通常要實現身份統一認證，可對接統一認證中心、權限中心，實現授權認證、訪問控制等功能。為了最小化延遲，API網關層邏輯要盡可能的薄。安全的前提下實現快速通過。不能堵塞，所以需要盡可能的減少延遲。另外考慮采用安全傳輸，防止數據包被其他人篡改、偽造，防止非公共數據被其他人竊聽。可能還需要考慮服務基礎設施安全以及第三方應用/內容安全。

API網關是微服務平臺的安全屏障。不管私有服務或者開放服務，其安全性都是一個時刻都需要認真面對的課題。

3. 敏捷-簡化開發

在API網關層實現這些安全機制，不但提高安全性，也簡化了應用服務的開發。使開發人員專注于業務應用、業務服務的研發，不再考慮基礎能力基礎組件，提升開發部署的效率，從而提升收益率。
將安全、訪問控制等非業務邏輯功能從微服務中分離出來，也使微服務的設計和實現簡化。使微服務更輕盈，更敏捷。
通過對 API服務的分類分級，簡化和控制開發人員對數據和服務的訪問；服務的開放和共享，可以構建更大范圍內的協作和開發人員生態體系。加快業務服務業務應用的交付。

4. 標準化接口，統一入口

API網關提供統一對外接口以實現開放性、標準化和規范化。當實現新的業務應用時或者需要集成不同系統或者服務之間的功能，調用不同服務提供的能力時，利用API網關可以讓用戶在不感知服務邊緣的情況下，利用統一的接口編排組裝服務。對于一個公司內部不同的服務，由于歷史原因提供的接口可能有不小的差異，通過API網關可以消除這種差異，統一對外提供標準化的接口，比如Restful接口。 當內部服務更新時，也可以通過API網關進行適配轉換，對客戶端透明，不需要調用方進行調整。
標準化是微服務化面對的一個很大挑戰。雖然我們也強調微服務的價值在于重構，但重構需要很長的路要走，剛開始可能需要類似于ESB的集成，首先實現互連互通，資源共享。但ESB服務往往比較重，無法滿足低延遲的要求，所以還需要逐步的重構業務應用。不同微服務的開發語言、協議、接口類型等可能不一樣，所以需要API網關來實現轉換，提供統一的標準化API對外開放，最為統一的入口。

5. 監控分析，明確各部分工作業績

日志監控等能力也是API網關的重要能力之一。通過對API訪問日志和運行監控數據的統計分析，可以了解業務服務的調用情況、調用趨勢、運行情況等等。一方面是業務服務評價的指標，另一方面也是助力智能決策的數據來源。哪些API服務調用的多，哪些API服務調用的少，哪個客戶調用的多，以及高峰流量時刻、平均流量、響應時間等等都是需要監控和統計分析的。這些數據將有助于我們對提供API的服務進行運維運營或重構，有助于我們做出合理決策。更為智能決策提供必須的數據支持。也是服務開發和擁有者的業績參考。

使用API網關實現微服務治理

微服務治理涉及的方面很多，但大體上包含微服務生命周期管理、微服務注冊發現、微服務日志監控、微服務安全、微服務訪問控制、微服務編排、微服務負載擴展、微服務流量控制、容錯熔斷等。這其中的大部分能力都可以在API網關層來實現，同時可以結合容器云平臺來實現完善的微服務治理能力。
從API網關的定位和能力來看，我們主要可以在網關層實現微服務的安全認證及訪問控制（包括路由、轉換、流量控制等），同時API網關也提供注冊發現、日志監控、服務編排、負載均衡等能力。利用這些能力，可以便利的實現微服務的治理，天然融合，無需再開發或部署一套微服務治理平臺，也不用為不同平臺之間的集成花費人力財力和珍貴的時間。
目前API網關產品眾多，商用的產品功能相對完善，可以很好的滿足微服務治理的需求。