雲設計模式和Service Mesh

之後又發展出了面向服務的SOA架構。所謂服務指的是一個單獨的功能單元，可以遠端訪問並獨立執行和更新，例如線上檢索信用卡賬單。這套架構的基本原則是獨立於廠商、產品和技術，並通過網路上的通訊協議，應用程式元件將服務提供給其他元件。SOA在技術架構上有侷限性，雖然所有的服務都已解耦，但是部署還是在一起，維護起來依然很麻煩。

接下來出現的就是大家很熟悉的微服務架構，它將單體應用程式劃分成一組小的服務，服務之間鬆耦合，使用輕量級通訊協議（RPC/REST）進行服務間通訊。微服務架構與SOA架構最大的不同在於可以獨立部署。基於這些特性所帶來的好處不僅是可以更快上線，並且由於服務間使用通訊協議交流，所以能夠技術異構。另外從應用架構角度來看它的可擴充套件性和伸縮性也很好，同時它還有一個很好的特性API first，這使得架構對mobile應用很友好。

注：除了這些典型架構外，還有微核心架構以及事件驅動架構，這裡不再介紹，讀者可以檢視Oreilly的《軟體架構模式》。

在基礎設施演進的早期階段，最先使用的是大型機，再往後是x86小型機伺服器，一直到這一階段基礎設施的成本還是很高，所以後續才會發展出虛擬化和雲化。雲化使得基礎設施被外包出去，成本得以降低，可維護性得以保障，同時，雲服務通常具備可程式設計性，更容易自動化，很多服務還有著彈性和自恢復的特性。容器化有著平臺無關，標準化的特性，可以無縫的在雲平臺之間切換，由於對資源的利用率高，所以更適合部署微服務，同時還有易伸縮的特性。

基於架構、基礎設施、工程實踐以及組織結構這四個角度，雲原生的概念被提出來，它主要是為了讓服務或組織更適應雲上執行。在架構層面上微服務是雲原生推薦的標準架構，以及12factors應用的實踐，基礎設施層面主要涉及的是雲化和容器化，工程實踐層面上則是使用DevOps理念讓交付流程更順暢，組織結構上是去中心化，讓團隊自治。

不管是雲化還是微服務化都不是能夠簡單完成的，還要面臨諸多挑戰。首先是雲化的挑戰，主要有兩點，一是如何將遺留系統改造的更適合上雲，二是如何更加有效的利用已有的雲服務。

微服務化的挑戰有以下四點，一是較高的存量遺留系統改造成本，單就從微服務拆分角度來看，業務的複雜度越高拆分難度越大。二是微服務化開發框架方面的問題，目前的微服務框架僅有Java的Spring Cloud和GO的ServiceComb等少量幾個，另一方面這些框架雖然能夠提供熔斷和服務治理方面的能力，但是提高了團隊的學習成本和升級維護成本。三是微服務治理功能不完善。四是關於微服務的監控和運維，比如日誌、呼叫等。

雲設計模式由微軟Azure架構中心推出，提供了32個雲設計模式，是可重複的上雲方案。我們認為設計模式解決軟體的重複性，而云設計模式解決雲化的重複性。

Azure從可用性、資料管理、設計實現、訊息、管理和監控、效能和可擴充套件性、彈性、安全等角度抽象出了不同的雲設計模式，對於每個模式的描述都遵循模式描述、背景和問題、解決方案、問題和注意事項、何時使用、案例、相關模式和指南這樣的流程。下面將對其中的一些設計模式進行具體介紹。

我們一般採用的服務監控方式，不太適用在微服務化場景，一方面是時間滯後，另一方面則是準確性不夠。假設這樣一個場景，A服務依賴於B服務和某個資料庫，某一時刻收到了關於A服務響應慢的警告，這時我們可能無法判斷問題是出在B服務上還是資料庫上，只能通過檢視日誌系統才能發現問題。

針對上面的問題健康端點監控系統給出瞭解決方案，它在應用程式內部實現了檢查的功能，外部工具可以定期通過暴露出去的端點訪問，以幫助驗證應用程式和服務是否正常執行。

靜態內容託管模式是將靜態內容部署到雲端儲存服務，然後直接返回給瀏覽器（前後端分離就是使用這樣的模式），當要進行請求的時候，使用CDN來提升效能。這樣帶來的好處就是完全不用維護，因為這是一個託管服務，也不需要使用工具做監控，同時這樣對基礎設施的開銷也更低。

絞殺者模式是服務解耦常用的一種模式，簡單來說就是用新的應用程式和服務逐步替換特定的功能。 建立一個外層來攔截請求前往後端舊版系統。 外層可將這些請求路由到舊版應用程式或新服務。 現有功能可逐步遷移到新系統，使用者可繼續使用相同的介面，他們並不知道遷移已發生。

前後端分離中前端會請求很多的API資料，這不僅造成了網路和效能的損耗，同時也會給伺服器帶壓力。使用閘道器能夠減少客戶端與服務之間的通訊頻率。 閘道器會接收客戶端請求，將請求分派到不同的後端系統，然後聚合結果並將其返回給請求客戶端。

閘道器路由模式類似Nginx反向代理，在一組應用程式、服務或部署前放置閘道器。 使用應用層 7 路由將請求路由到相應例項。使用此模式，客戶端應用程式只需瞭解單個終結點並與之通訊。 如果服務進行合併或分解，客戶端不一定需要更新。 它可以繼續向閘道器發出請求，只有路由會更改。

Service Mesh是用來處理服務間通訊的基礎設施層，在服務拓撲間實現請求可靠傳遞，通常實現為一組和應用程式部署在一起的輕量級的網路代理，但對應用程式來說是透明的。Service Mesh的網路代理能夠實現很多功能，比如服務發現、負載均衡等，對比微服務框架它讓開發者能夠更專注於業務開發。而之所以被叫做服務網格，是由於sidecar（單個服務呼叫）連線起來類似網格。

Istio是Service Mesh的一個實現，它分為控制面和資料面。資料面就是代理，通過sidecar挎鬥模式接入服務，由於和服務本身沒有關係，所以可以使用HTTP2、gRPC不同協議等。控制面分為Pilot、Mixer、Istio-Auth三個部分，Pilot包含服務發現、路由、負載均衡等功能，Mixer可以做代理的訪問控制、遙測、監控、指標收集、限流等，Istio-Auth負責身份驗證、祕鑰管理、審計等。

Service Mesh帶來的好處顯而易見，首先是能夠0侵入接入遺留系統或者無微服務框架系統，其次應用層只需要關注業務邏輯，還解決了微服務監控、運維、治理等問題，最後Service Mesh本身的升級和運維是獨立的。

目前Service Mesh還是一個比較新的概念，所以還沒有能夠完全在生產環境中使用。它在資料面工具還算比較多，有Linkerd、Nginx、Envoy、Mesher、Conduit，控制面則寥寥無幾，現階段只有有Istio和CSE。這些工具由於都是容器化的，所以大部分都是執行在k8s上。

注：本話題分享時，Istio還處於比較早期的版本，在0.6以後，我們嘗試使用Istio，在生產環境上部署流量較少，不那麼重要的服務。從實際的使用過程來看，它在如下方面帶來的極大的好處：

1）開發可以專注業務程式碼開發，服務治理的任務交給Istio來完成。

2）可以根據服務特性，採用合適的語言開發，不用擔心服務註冊發現客戶端引入的問題。

3）使用很小的成本就可以實現0當機時間的自動化部署以及灰度釋出。

在目前的使用中，我們使用Istio遇到的問題主要是Kubenetes的維護上，以及Istio本身還不夠成熟，遇到的bug通常只能通過升級、重啟去解決，團隊缺乏Istio的經驗。當然這些隨著Istio本身的成熟以及團隊成員進一步的總結學習，是可以解決的。