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，用在更大規模的環境中。

從表面上看，混沌工程只是為了向系統注入混亂。盡管通過破壞系統來發現問題是件有趣的事情，但這樣做并不一定會帶來生產力的提升或者給我們提供有用的信息。實際上，混沌工程不只是注入故障那么簡單，它還可以制造流量高峰、非正常的請求等，用以發現已經存在的問題。除了可以用它驗證假設，還可用它來發現系統的新屬性。通過發現系統弱點來改進系統彈性，以免造成糟糕的用戶體驗。

混沌工程通過對系統進行全面的測試來改善穩定性。隨著工程師們在提升系統健壯性方面所做的工作越來越多，混沌工程似乎會變得越來越為人們所接受。

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

最后給大家 推薦一個 Java 架構方面的交流學習群： 698581634 ，里面會分享一些資深架構師錄制的視頻錄像：有 Spring ， MyBatis ， Netty 源碼分析，高并發、高性能、分布式、微服務架構的原理， JVM 性能優化這些成為架構師必備的知識體系，主要針對 Java 開發人員提升自己，突破瓶頸，相信你來學習，會有提升和收獲。在這個群里會有你需要的內容   朋友們請抓緊時間加入進來吧。