本文主要是對過去的2018年曾經的微服務發展趨勢的回顧，依然有一定的思考價值。各位讀者可結合當下，自行感受一下2019可能的發展趨勢，本文不對微服務做進一步發展預測，歡迎各位給出自己的發展趨勢的觀點。

原文：http://dockone.io/article/3070

【編者的話】在2017年，DevOps領域中增加了大量的生態系統玩家，那麼2018年會有哪些變化呢？本文展望了微服務在2018年可能的5個發展趨勢，並對各個趨勢進行了詳細的介紹。

對於DevOps來說，2017年是重要的一年，不僅生態系統玩家的數量大幅增加，而且CNCF項目增加了兩倍。展望未來一年，我們期待創新和市場變化進一步加速。以下是我們對2018年微服務趨勢的看法：服務網格、事件驅動架構、容器本地安全、GraphQL和混沌工程。

我們將關注這些趨勢，以及未來一年將圍繞它們建立業務的公司。你看到了什麼趨勢？在下面留言讓我們知道哪些被遺漏了，或者如果你同意/不同意我們概述的內容。

1. 服務網格非常熱門

服務網格是一個用於改進服務與服務之間的通信的基礎架構層，也是目前最流行的原生雲類別。隨著容器變得越來越普遍，服務拓撲變得越來越動態，需要更先進的網絡功能。服務網格可以通過服務發現、路由、負載均衡、健康檢查和可觀察性來幫助管理流量。服務網格試圖馴服難以控制的容器複雜性。

隨著像HAProxy、Træfik和NGINX這樣的負載均衡器開始重新定位為數據平面，它的服務網格變得越來越受歡迎。我們還沒有看到廣泛的部署，但確實知道在生產環境中運行服務網格的業務。此外，服務網格並不僅限於微服務或Kubernetes環境，還可以應用於VM和Serverless環境。例如，國家生物技術信息中心不是運行容器，而是使用Linkerd。

服務網格也可用於混沌工程，“在分佈式系統上進行實驗的規程，以建立對系統抵禦混亂狀況能力的信心。”服務網格不需要在每個主機上安裝一個守護進程，而是將延遲和失敗注入到環境中。

Istio和Buoyant Linkerd是該領域最引人注目的產品。請注意，Buoyant在去年12月為Kubernetes提供的一個開源服務網格 Conduit v0.1。

2. 事件驅動架構的崛起

隨著業務敏捷性需求的增加，我們開始看到一個向“推送”架構或者基於事件體系結構的發展趨勢，即：一個服務發送一個事件，一個或多個觀察者容器異步地運行邏輯來響應該事件，而不需要通知事件生產者。與請求-響應架構不同，在事件驅動的系統中，啟動容器中的功能流程和事務負載並不依賴於下游容器中遠程進程的可用性和完成情況。另一個好處是，在設計各自的服務時，開發人員可以更加獨立。

雖然開發人員可以將容器環境構建為事件驅動架構，但功能即服務（FaaS）本身就體現了這種能力。在FaaS架構中，函數作為文本存儲在數據庫中，並通過事件觸發。一旦調用了該函數，API控制器就會接收消息並通過負載均衡器將其發送到消息總線，消息總線將其排入計劃並提供給一個調用容器。執行完後，結果存儲在數據庫中，併發送給用戶，然後函數被分解，直到再次觸發。

FaaS的好處包括：1）從編寫代碼到運行服務的時間縮短了，因為創建或push源碼之後不需要做額外操作。2）當函數由FaaS平臺（如AWS）管理和縮放時，開銷會減少。然而，FaaS並非沒有自身的挑戰。由於FaaS要求將服務的每個部分解耦，因此可能會出現難以發現、管理、編排和監視的函數的擴散。最後，如果沒有依賴項的全面可視化工作，就很難調試FaaS系統，可能會出現無限循環。

目前，FaaS不適合需要長調用、加載大量數據到內存和強一致性能要求的進程。雖然開發人員使用FaaS進行後臺工作和臨時事件，但我們認為隨著存儲層加速和平臺性能的提高，用例將隨著時間的推移而擴展。

在2017年秋季，雲計算基金會（CNCF）對550人進行了調查，其中31%使用serverless技術，28%計劃在未來18個月內使用Serverless。接下來的調查是詢問哪個特定的服務器平臺正在被使用。在使用Serverless技術的169項中，有77%表示他們使用了AWS。雖然Lambda可能是領先的Serverless平臺，但我們相信在邊緣需求中可能會有其他的機會。邊緣計算對於物聯網和AR/VR用例尤其有效。

3. 安全需要改變

由於內核訪問控制，打包在容器中的應用程序從根本上更安全。在VM環境中，唯一可見的點是虛擬設備驅動程序。現在應用程序移動到容器環境，操作系統具有syscalls和semantic含義。這是一個更加豐富的信號。以前的操作符通過將代理放入VM來實現某些信號，但它比較複雜並且需要很多管理工作。容器環境下要提供清晰的可視化和集成功能，而這些工作量與VM環境工作量相比是微不足道的。

考慮到這一點，在451研究調查報告說，安全是容器應用的最大障礙——挑戰依然存在！ 最初，漏洞是容器環境中的主要安全問題。隨著公共註冊中心中隨時可用的容器映像的數量成倍增加，確保它們沒有漏洞變得非常重要。人工處理、鏡像掃描和授權認證已經成為一種常態處理方式。

與虛擬機管理程序作為訪問和控制點的虛擬化環境不同，任何具有訪問內核根的容器最終都可以訪問內核上的所有容器。反過來，組織必須確保容器如何與宿主機交互，哪些容器可以執行某些操作或系統命令。增強主機控制以確保正確配置cgroups和namespace對於維護安全性也很重要。

最後，傳統防火牆依靠IP地址規則來把關網絡流。這種技術無法擴展到容器環境，因為動態編排器會複用IP地址。

運行時威脅檢測和響應對生產環境至關重要，通過對容器環境進行指紋識別，並構建詳細的行為基線圖像，可以容易地檢測到異常行為和攻擊者的沙箱。一份451的研究報告指出，52%的被調查公司在生產環境中運行容器，這表明容器的運行時威脅檢測解決方案正在加速發展。

4. 從REST轉變到GraphQL

GraphQL是一種API規範，它是一種查詢語言和一個運行時的查詢執行操作。它由Facebook在2012年創建，並於2015年開源。GraphQL類型系統允許開發人員自定義數據模式。可以隨時添加新的字段，並可以在不影響現有查詢或重構客戶端應用程序的情況下對字段進行更新。GraphQL是功能強大的，因為它沒有綁定到特定的數據庫或存儲引擎。

GraphQL服務器作為一個單獨的HTTP端點運行，它表示服務的全部功能。通過在類型和字段之間定義資源之間的關係（而不是像REST一樣的端點），GraphQL可以遵循屬性之間的引用，因此服務可以使用單個查詢從多個資源中接收數據。此外，REST api需要為單個請求加載多個url，這導致網絡跳數增多，降低了查詢速度。通過較少的通信次數，GraphQL減少了每個數據請求所需的資源數量，並且返回的數據通常格式化為JSON。

使用GraphQL可以獲得比REST額外的好處。首先，客戶端和服務器是解耦的，於是可以單獨維護它們。與REST不同，GraphQL在客戶機和服務器之間使用的語言非常類似，使得調試更容易。查詢語句的數據形狀與從服務器獲取的數據的形狀完全匹配，使得GraphQL比SQL或Gremlin等其他語言更加高效和有效。查詢語句反映了它們的響應的形狀，因此可以檢測到偏差，並且不能正確解析的字段可以被識別。由於查詢更簡單，使得整個過程的穩定性更強。該規範最廣為人知的是支持外部api，而我們發現它也被用於內部api。

GraphQL的用戶包括 Amplitude、Credit Karma、KLM、NY Times、Twitch、Yelp等。在11月，Amazon通過推出AWS AppSync（包括GraphQL支持）證明了GraphQL的流行程度。觀察GraphQL將如何在gRPC和諸如Twitch的Twirp RPC框架這樣的替代環境中發展，將會非常有趣。

5. 混沌工程變得更加廣為人知

最初由Netflix推廣，後來被亞馬遜（Amazon）、谷歌、微軟（Microsoft）和Facebook應用，在系統上進行混沌工程實驗，以提高其在生產問題上的確定性。混沌工程在過去的十年裡不斷髮展。它從Chaos Monkeys開始，它們在生產環境中關閉了服務，並且擴展到更大的環境中使用失敗注入測試（FIT）和Chaos Kong。

表面上看來，混亂工程僅僅是為了注入混亂。雖然破壞系統可能很有趣，但它並不總是有效或提供有用的信息。混沌工程包含了更廣泛的範圍，不僅僅是注入故障，還包括其他場景，如流量峰值、異常請求組合等，以發現現存的問題。除了驗證假設之外，它還應該顯示系統的新屬性。通過發掘系統的弱點，團隊可以幫助提高彈性，預防糟糕的客戶體驗。

像神經網絡和深度學習這樣的複雜的新技術，相比證明它們的有效性，理清它們的工作原理可能會變得不那麼重要。混沌工程通過對系統進行整體測試來識別不穩定性，從而幫助應對這一挑戰。隨著工程師們努力使他們日益複雜的系統變得更加健壯，這可能會成為一種更為普遍的做法。

隨著混沌工程變得越來越主流，它可以採用現有的開源項目、商業產品的形式，或者用上文提到的服務網格形式實現。

原文鏈接：5 Microservices Trends to Watch in 2018（翻譯：陳杰）

=======================================================

譯者介紹

陳杰，阿里巴巴數據庫團隊算法專家，工作重心為利用深度學習技術優化數據庫場景中的性能問題，平時也樂於去實現一些突發的想法。在疲於配置系統環境時發現了Docker，跟大家一起學習、使用和研究Docker。