雲設計模式和Service Mesh

內容來源：2017 年 12 月 17 日，華爲高級軟件工程師馬博文在「辭舊迎新的第七屆西安DevOps MeetUp」進行《雲設計模式和Service Mesh》演講分享。IT 大咖說（微信ID：itdakashuo）做爲獨家視頻合做方，經主辦方和講者審閱受權發佈。

閱讀字數：3817 | 10分鐘閱讀

嘉賓演講視頻回顧及PPT： t.cn/RrgjG0q

摘要

隨着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是用來處理服務間通訊的基礎設施層，在服務拓撲間實現請求可靠傳遞，一般實現爲一組和應用程序部署在一塊兒的輕量級的網絡代理，但對應用程序來講是透明的。Service Mesh的網絡代理可以實現不少功能，好比服務發現、負載均衡等，對比微服務框架它讓開發者可以更專一於業務開發。而之因此被叫作服務網格，是因爲sidecar（單個服務調用）鏈接起來相似網格。

Istio

Istio是Service Mesh的一個實現，它分爲控制面和數據面。數據面就是代理，經過sidecar挎鬥模式接入服務，因爲和服務自己沒有關係，因此可使用HTTP二、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自己的成熟以及團隊成員進一步的總結學習，是能夠解決的。