微服務與網格架構最佳化實踐
你們導入微服務了嗎？導入了！那架構如何編排呢？
微服務的架構不僅僅只有一種模式，依照環境的差異也會有不同的實踐方式，本文不深入探究底層採用的IaaS是虛擬機(Virutal-Machine)、容器(Container)亦或是實體機(Bare Metal)，僅討論這幾年微服務盛行後最常耳聞且不可或缺的兩個角色 — 服務網格(Service Mesh)以及API閘道(API Gateway)如何增益我們的微服務架構。
什麼是Service Mesh？什麼是API Gateway？簡單說明Service Mesh是負責服務與服務之間東西向的溝通，而API Gateway則是客戶端與服務間南北向流量溝通的橋樑，其餘更多的概念細節在網路上已有許多資源可以閱讀，本文就不再贅述。
微服務切了好幾刀，怎麼管理連接？
先不論傳統單體式(Monolithic Architecture)的架構與微服務的優劣，開始擁抱微服務的我們總會遇到第一道難題，服務拆分後怎麼連接通訊？原本單體式的架構相對較少情境會需要考慮這些問題，大多時候只需要提供一個端口對外，而服務碎片化後是不是需要增加維護成本來管理更多端口？答案是肯定的！因此不可或缺的第一個角色就派上用場了 — API Gateway！我們可以透過它來管理所有的服務端口，再藉由其路由的方式達到對外只需一個端口便可以提供多個服務的連線通訊，大大地減少客戶端調用服務API的成本。
服務數量一直增長，怎麼有效建立關聯
解決對外連線端口問題後，接著我們想起擁抱微服務架構的初衷不就是為了易擴展高可用！同樣的服務可以因應需求不斷地擴展做負載平衡才能最大化體現出微服務的價值，然而隨著數量的增長，服務的端口也跟著增加，對外或許API Gateway可以解決，而服務與服務之間的通訊呢？因此Service Mesh被提出來解決這個問題，成為了微服務的要角之一，Service Mesh的概念是藉由每個服務啟動時會伴隨一個小的網路代理(Sidecar Proxy)，Sidecar除了綁定自身的服務外，也與其他的Sidecar在同一個網路層下結成一個網狀架構，撇除Sidecar實作的查找機制不談，我們知道的是藉由Sidecar的作用下，服務數量不管被擴展多少份都可以在此網路下尋找到彼此進而通訊，解決了我們服務之間多量且複雜的通訊問題。
動動手來實作架構吧
如前言所述，本文不探討IaaS不同之下的架構案例，先以Kubernetes(K8s)平台作為應用範例。當我們採用K8s容器管理平台來實踐微服務架構時，首先除了內建提供的NodePort、LoadBalancer等基本管理服務外部通訊連入的功能之外，我們也可以藉由建置其它第三方工具來達到一樣效果，甚至能提供更多細粒度的控管，例如：Nginx Ingress、Istio Gateway等。跟著前述的思路走，僅憑藉著K8s平台功能就得以解決南北向流量的問題，而東西向的連接呢？果然K8s不會讓我們失望的，它也支援了！可以透過其提供的Cluster IP跟Kubenetes DNS輕鬆完成服務之間的通訊。看來只需要將服務遷移到K8s平台就完美實現微服務架構了！本文結束…(誤。
K8s還不夠？
K8s雖然滿足了大部分基本的使用需求，但距離理想的微服務架構還遠遠不及，因此我們要導入在實踐過程的其中一個重要角色 — Istio，Istio是一套Open Source的Service Mesh實踐工具，它實作了Sidecar的機制，在每個服務啟動時自動注入Sidecar提供了整個微服務架構中的網格網路，進而實現了服務自動發現(Service Discovery)功能，讓服務之間更容易找到彼此，換句話說相較於原本K8s提供的功能之外，可以更有效地監看整個服務之間通訊的網路狀態，不僅能提供開發者更容易地掌握服務端點自動化連接，更有利於維運人員監控排錯。因此光以Sidecar達到Mesh網路這個功能就很值得將其導入使用，更別提其它還有服務健康檢測(Health Checking)、斷路(Circuit Breaking)以及服務間連線加密(TLS)等在生產環境不可或缺的好用功能。其中Istio服務架構也包含了Ingress Gateway，可以管理服務對外南北向的流量，如此一來是不是導入Istio後就達到理想的架構了呢？別忘了還有另外一個神器 — API Gateway，讓我們繼續往下看。
為什麼需要API Gateway
一個標準的API Gateway軟體具備的不僅僅只有南北向流量代理的功能，其中還須包含一些基礎的功能，例如：認證授權、路由管理、流量管控、安全防護以及請求轉換(Request/Response Transformation)等，這些功能在以往單體式架構下往往我們只需要實作在Application內，而當套用到微服務架構時我們需要為每個服務各自打造嗎？或是說這些功能也成為其中一個微服務時，以認證模組舉例，每一個服務都需要再個別去向其請求認證嗎？很明顯地這些都不是好方法，因此在理想的微服務架構下API Gateway的導入可以有效地減少架構的複雜度，甚至於降低請求的延遲時間，讓服務可以更專注於服務本身的邏輯，減少依賴，做到真正的無狀態服務(Stateless Services)，如此一來更無後顧之憂，可隨用量的增長恣意擴展服務數量得以應付更高的流量負載。說了這麼多API Gateway的優點，實務上不免俗的也要推薦一個極具代表性Open Source的API Gateway工具 — Kong來佐以我們的微服務架構。
繼續邁向我們最佳架構實踐之路
在我們追求理想中最佳實踐的路上，當然是盡可能地發揮架構的最大效益，既然Istio Service Mesh與Kong API Gateway在東西及南北向各自領域都表現的如此優異，何不將其整合以應付各種場景。接著我們以實務的角度來說明如何將其結合，下圖為Istio架構下流量運作的示意圖：
我們可以看到外部的流量統一交由Istio Ingress Gateway管理，因此我們要做的其實就是使用Kong API Gateway來取代Istio Ingress Gateway，如下圖所示：
實作的方法很簡單，我們利用Istio的架構將Kong也當作是其下管理的服務之一，讓Kong可以藉由Sidecar來發現Mesh Network下的所有服務並進行通信，再把Kong當作外對內唯一的端口，如此一來就可以同時擁有Kong帶來的更多強大管理功能，以及Istio全方位的服務監管，讓架構有更高的覆蓋率可以應付各種不同的場景需求，進而達成我們的最佳化實踐的目標。
結語
其實只要符合自身的需求就是最佳的架構實踐，本文雖以各種問題跟工具來體現出面臨不同場景時解決方案的優點，但熟悉工具及工具本身佔用的系統資源也是一種隱性成本，沒有絕對的優劣，架構還是需考量自身服務的相性，若一昧地追求工具帶來的便捷或許容易適得其反，反而造就更多的無形負擔，最後希望大家都可以針對自己的場景打造出心中理想的最佳化架構。
雙子星雲端身為雲原生計算基金會所認證的Kubernetes服務提供商，提供了自有的API Gateway產品，搭配我們的容器多雲專業服務，能為您設計最適合您的微服務最佳實踐。
