服務網格

　　Service Mesh，服務網格，也有人翻譯為”服務嚙合層”。這貌似是今年才出來的新名詞？在2017年之前沒有聽過，雖然類似的產品已經存在挺長時間。

　　什么是Service Mesh（服務網格）？

　　Service Mesh是專用的基礎設施層，輕量級高性能網絡代理。提供安全的、快速的、可靠地服務間通訊，與實際應用部署一起，但對應用透明。

　　為了幫助理解， 下圖展示了服務網格的典型邊車部署方式：

　　圖中應用作為服務的發起方，只需要用最簡單的方式將請求發送給本地的服務網格代理，然后網格代理會進行后續的操作，如服務發現，負載均衡，最后將請求轉發給目標服務。當有大量服務相互調用時，它們之間的服務調用關系就會形成網格，如下圖所示：

　　在上圖中綠色方塊為服務，藍色方塊為邊車部署的服務網格，藍色線條為服務間通訊。可以看到藍色的方塊和線條組成了整個網格，我們將這個圖片旋轉90°，就更加明顯了：服務網格呈現出一個完整的支撐態勢，將所有的服務”架”在網格之上：

　　服務網格的細節我們今天不詳細展開， 詳細內容大家可以參考網上資料。或者稍后我將會推出一個服務網格的專題，單獨深入介紹服務網格。

　　Istio也可以視為是一種服務網格， 在Istio網站上詳細解釋了這一概念：

　　如果我們可以在架構中的服務和網絡間透明地注入一層，那么該層將賦予運維人員對所需功能的控制，同時將開發人員從編碼實現分布式系統問題中解放出來。通常將這個統一的架構層與服務部署在一起，統稱為“服務嚙合層”。由于微服務有助于分離各個功能團隊，因此服務嚙合層有助于將運維人員從應用特性開發和發布過程中分離出來。通過系統地注入代理到微服務間的網絡路徑中，Istio將迥異的微服務轉變成一個集成的服務嚙合層。

　　Istio能做什么？

　　Istio力圖解決前面列出的微服務實施后需要面對的問題。Istio 首先是一個服務網絡，但是Istio又不僅僅是服務網格： 在 Linkerd， Envoy 這樣的典型服務網格之上，Istio提供了一個完整的解決方案，為整個服務網格提供行為洞察和操作控制，以滿足微服務應用程序的多樣化需求。

　　Istio在服務網絡中統一提供了許多關鍵功能（以下內容來自官方文檔）：

　　流量管理：控制服務之間的流量和API調用的流向，使得調用更可靠，并使網絡在惡劣情況下更加健壯。

　　可觀察性：了解服務之間的依賴關系，以及它們之間流量的本質和流向，從而提供快速識別問題的能力。

　　策略執行：將組織策略應用于服務之間的互動，確保訪問策略得以執行，資源在消費者之間良好分配。策略的更改是通過配置網格而不是修改應用程序代碼。

　　服務身份和安全：為網格中的服務提供可驗證身份，并提供保護服務流量的能力，使其可以在不同可信度的網絡上流轉。

　　除此之外，Istio針對可擴展性進行了設計，以滿足不同的部署需要：

　　平臺支持：Istio旨在在各種環境中運行，包括跨云， 預置，Kubernetes，Mesos等。最初專注于Kubernetes，但很快將支持其他環境。

　　集成和定制：策略執行組件可以擴展和定制，以便與現有的ACL，日志，監控，配額，審核等解決方案集成。

　　這些功能極大的減少了應用程序代碼，底層平臺和策略之間的耦合，使微服務更容易實現。

　　Istio的真正價值

　　上面摘抄了Istio官方的大段文檔說明，洋洋灑灑的列出了Istio的大把大把高大上的功能。但是這些都不是重點！理論上說，任何微服務框架，只要愿意往上面堆功能，早晚都可以實現這些。那，關鍵在哪里？

　　不妨設想一下，在平時理解的微服務開發過程中，在沒有Istio這樣的服務網格的情況下，要如何開發我們的應用程序，才可以做到前面列出的這些豐富多彩的功能？ 這數以幾十記的各種特性，如何才可以加入到應用程序？

　　無外乎，找個Spring Cloud或者Dubbo的成熟框架，直接搞定服務注冊，服務發現，負載均衡，熔斷等基礎功能。然后自己開發服務路由等高級功能， 接入Zipkin等Apm做全鏈路監控，自己做加密、認證、授權。 想辦法搞定灰度方案，用Redis等實現限速、配額。 諸如此類，一大堆的事情， 都需要自己做，無論是找開源項目還是自己操刀，最后整出一個帶有一大堆功能的應用程序，上線部署。然后給個配置說明到運維，告訴他說如何需要灰度，要如何如何， 如果要限速，配置哪里哪里。

　　這些工作，相信做微服務落地的公司，基本都跑不掉，需求是現實存在的，無非能否實現，以及實現多少的問題，但是毫無疑問的是，要做到這些，絕對不是一件容易的事情。

相關電子資料下載