2018年5大微服務發展趨勢

 

1. 服務網格白熱化

服務網格是一個專一於服務間通訊的基礎設施層，也是目前最受關注的與雲原生有關的話題。隨着容器的普及，服務拓撲變得愈來愈動態化，這對網絡功能提出了更多的要求。服務網格經過服務發現、路由、負載均衡、健康檢測和可觀察性來管理流量，簡化容器與生俱來的複雜性。

隨着 HAProxy、traefik 和 NGINX 逐步把本身定位成數據平面，服務網格也變得愈來愈流行。儘管服務網格尚未獲得大規模部署，但確實有些企業已經在生產環境中運行服務網格。另外，服務網格不只能夠用在微服務或 Kubernetes 環境中，也能夠被用在 VM 和無服務器架構的環境中。例如，美國國家生物技術信息中心雖然沒有使用容器，但他們使用了 Linkerd。

服務網格還能夠用在混沌工程中。服務網格能夠給系統注入延遲和故障，這樣就不須要在每臺主機上安裝後臺進程。

Istio 和 Buoyant 的 Linkerd 是目前最爲流行的服務網格框架。另外，Buoyant 在去年 12 月份開源了用於 Kubernetes 的服務網格框架 Conduit V0.1。

 

 

2. 事件驅動架構的崛起

隨着業務場景的不斷變化，咱們已經看到了基於推送或事件的架構正在成爲一種趨勢。服務向訂閱事件的觀察者容器發送事件，容器異步作出響應，事件發送者可能對此一無所知。與請求響應式架構不一樣的是，在基於事件的系統架構中，發起事件的容器並不依賴下游的容器，它們的處理過程和加載的事務與下游容器的可用性或完成狀況無關。這種架構的另外一個好處是，開發者能夠更加獨立地設計各自的服務。

在容器環境中使用基於事件的架構時，功能即服務（FaaS）能夠助他們一臂之力。在 FaaS 架構中，功能以文本的形式保存在數據庫中，而後由事件來觸發它們。在調用一個功能時，API 控制器會收到一個消息，並將它經過負載均衡器發送到消息總線，調用者容器負責處理隊列中的消息。消息處理完畢後，結果被保存在數據庫中，併發送給用戶，而功能暫時退役，等待下一次觸發。

FaaS 有兩大好處。首先，縮短了服務開發時間，由於除了源代碼，不須要建立其餘任何東西。其次，下降了開銷，由於功能的管理和伸縮一般是由 FaaS 平臺（好比 AWS Lambda）來完成的。固然，採用 FaaS 自己也存在一些挑戰。FaaS 要求解耦每個服務，那麼就會存在大量的服務須要發現、管理、編配和監控。由於缺少對服務依賴鏈的全盤瞭解，FaaS 系統難以調試，並且可能會出現無限循環依賴問題。

在目前看來，FaaS 並不適用於某些場景，好比那些須要較長處理時間、須要往內存里加載大量數據或須要穩定性能的場景。開發者主要使用 FaaS 來運行後臺做業和處理臨時事件，不過咱們相信，隨着存儲層速度的加快和平臺性能的提高，FaaS 的應用場景會愈來愈多。

2017 年秋天，CNCF 對 550 名用戶進行了問卷調查，其中 31% 的人正在使用無服務器架構技術，28% 的人打算在將來 18 個月使用無服務器架構技術。而在使用無服務器架構技術的 169 人當中，有 77% 使用的是 AWS Lambda。雖然說 Lambda 或許是領先的無服務器架構平臺，但咱們相信邊緣計算仍然有機會。邊緣計算將在物聯網和 AR/VR 領域大展拳腳。

3. 安全模型的變化

由於對內核訪問方面的限制，部署在容器中的應用程序相對安全。在 VM 環境中，虛擬設備驅動器是惟一暴露可見性的地方。而在容器環境裏，操做系統提供了系統調用，信號源也變得更加豐富。以前，管理員須要在 VM 中安裝代理，但那樣太複雜了，須要管理太多的東西。容器提供了更清晰的可見性，相比 VM，與容器的集成會更加容易。

451 Research 公司發佈的一份調查報告代表，安全性是影響容器普及的最大障礙。在一開始，安全漏洞就已成爲容器環境最主要的問題。隨着愈來愈多的容器鏡像的發佈，確保這些鏡像不含有漏洞便成爲當務之急。隨着時間的推移，容器鏡像掃描和認證成爲了一種有利可圖的生意。

在 VM 環境中，hypervisor 扮演着訪問控制點的角色，而對於一個具有內核訪問權限的容器來講，它能夠訪問內核上的其餘全部容器。所以，使用容器的企業必須限制容器與宿主機之間的交互行爲以及容器將會執行的系統調用。確保宿主機的 cgroup 和 namespace 配置穩當也是很是重要的一點。

傳統的防火牆經過 IP 地址規則來控制網絡流量。不過，這種技術沒法在容器環境中使用，由於動態編配須要重用 IP。在生產環境，運行時攻擊檢測是很是關鍵的安全手段，經過構建容器指紋和定義行爲基準，就能夠很容易檢測出異常行爲，並把攻擊者隔離在沙箱中。451 Research 公司的報告指出，受調的 52% 企業在生產環境中使用了容器，可見，在容器環境中使用運行時攻擊檢測十分有必要。

4. 從 REST 到 GraphQL

GraphQL 是 Facebook 於 2012 年建立並於 2015 年開源的一套查詢語言 API 規範。GraphQL 的類型系統容許開發者本身定義數據 schema，能夠增長新字段，也能夠刪除舊字段，這些都不會影響已有的查詢，也不須要修改客戶端。GraphQL 很是強大，由於它沒有與特定的數據庫或存儲引擎綁定在一塊兒。

GraphQL 服務器使用一個單獨的端點來提供全部的功能。只要定義好資源之間類型和字段的關係（這個與 REST 端點不太同樣），GraphQL 就能夠跟蹤屬性之間的關係，在單個查詢中從多個資源獲取數據。在使用 REST 時，可能須要爲單個請求加載多個 URL，這樣不只增長了網絡跳轉，還拖慢了查詢速度。經過減小網絡跳轉，GraphQL 下降了單個數據請求所要耗費的資源。GraphQL 返回的數據一般是 JSON 格式。

使用 GraphQL 還有其餘好處。首先，客戶端和服務器端之間解耦開了，這樣就能夠分開維護。GraphQL 使用類似的語言進行客戶端與服務器端之間的通訊，因此調試更加容易了。查詢結構與服務器端返回的數據結構徹底匹配，所以，相比其餘語言，如 SQL 或 Gremlin，GraphQL 更加高效。查詢自己就反映了響應消息的結構，因此能夠很容易地檢測出差別，若是沒有正確處理某些字段也能夠很容易識別出來。由於查詢更簡單了，整個流程也變得更穩定。雖說 GraphQL 規範主打支持外部 API，但咱們發現將它用在內部 API 中也很不錯。

GraphQL 的用戶包括 Amplitude、Credit Karma、KLM、紐約時報、Twitch、Yelp 等。去年 11 月，亞馬遜推出的 AppSync 就提供了 GraphQL 支持，可見它有多麼流行。在存在 gRPC 和 Twitch Twirp 這些 RPC 框架的前提下，看着 GraphQL 的發展真是一件有趣的事情。

5. 混沌工程浮出水面

混沌工程最初由 Netflix 發起，後來亞馬遜、谷歌、微軟和 Facebook 也開始實踐。混沌工程的目的在於改進系統的肯定性，以便應對生產環境的各類問題。混沌工程經歷了十年的發展。最初，Netflix 開發了 Chaos Monkeys，用它在生產環境關閉部分服務，後來演變成故障注入測試和 Chaos Kong，用在更大規模的環境中。

從表面上看，混沌工程只是爲了向系統注入混亂。儘管經過破壞系統來發現問題是件有趣的事情，但這樣作並不必定會帶來生產力的提高或者給咱們提供有用的信息。實際上，混沌工程不僅是注入故障那麼簡單，它還能夠製造流量高峯、非正常的請求等，用以發現已經存在的問題。除了能夠用它驗證假設，還可用它來發現系統的新屬性。經過發現系統弱點來改進系統彈性，以避免形成糟糕的用戶體驗。

混沌工程經過對系統進行全面的測試來改善穩定性。隨着工程師們在提高系統健壯性方面所作的工做愈來愈多，混沌工程彷佛會變得愈來愈爲人們所接受。

隨着混沌工程成爲主流，它可能會以開源項目的形式、商業的形式甚至是服務網格的形式來實現。