內容來源：2017 年 12 月 17 日，華為高階軟體工程師馬博文在“辭舊迎新的第七屆西安DevOps MeetUp”進行《雲設計模式和Service Mesh》演講分享。IT 大咖說（微信ID：itdakashuo）作為獨家視訊合作方，經主辦方和講者審閱授權釋出。
閱讀字數：3817 | 10分鐘閱讀
摘要
隨著IT技術的快速發展，擴充套件性越來越成為企業關注的焦點。從應用架構上表現為微服務化，基礎設施架構上表現為雲化，組織結構去中心化，開發流程敏捷/DevOps化。這其中，企業應用雲化是最不被質疑的趨勢。然而，現實情況是企業大量的存量應用系統架構不加修改直接移植到雲上的可能性比較低，雖然我們可以採用服務的拆分策略（按照功能、資料或者DDD的原則等）來將拆分應用，使其更適於在雲上部署。但是在實際的實施過程中，還是會面臨很多問題。本次話題將嘗試從微軟Azure總結雲設計模式的角度來看待應用雲化、微服務以及被稱為可能是下一代微服務的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
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本身的成熟以及團隊成員進一步的總結學習，是可以解決的。