對於DevOps來說，2017年是重要的一年，不僅生態系統玩家的數量大幅增加，而且CNCF專案增加了兩倍。展望未來一年，我們期待創新和市場變化進一步加速。以下是我們對2018年微服務趨勢的看法：服務網格、事件驅動架構、容器本地安全、GraphQL和混沌工程。
我們將關註這些趨勢，以及未來一年將圍繞它們建立業務的公司。你看到了什麼趨勢？在下麵留言讓我們知道哪些被遺漏了，或者如果你同意/不同意我們概述的內容。
服務網格是一個用於改進服務與服務之間的通訊的基礎架構層[1]，也是目前最流行的原生雲類別。隨著容器變得越來越普遍，服務拓撲變得越來越動態，需要更先進的網路功能。服務網格可以透過服務發現、路由、負載均衡、健康檢查和可觀察性來幫助管理流量。服務網格試圖馴服難以控制的容器複雜性。
隨著像HAProxy、Træfik和NGINX這樣的負載均衡器開始重新定位為資料平面，它的服務網格變得越來越受歡迎。我們還沒有看到廣泛的部署，但確實知道在生產環境中執行服務網格的業務。此外，服務網格並不僅限於微服務或Kubernetes環境，還可以應用於VM和Serverless環境。例如，國家生物技術資訊中心不是執行容器，而是使用Linkerd。
服務網格也可用於混沌工程，“在分散式系統上進行實驗的規程，以建立對系統抵禦混亂狀況能力的信心[2]。”服務網格不需要在每個主機上安裝一個守護行程，而是將延遲和失敗註入到環境中。
Istio和Buoyant Linkerd是該領域最引人註目的產品。請註意，Buoyant在去年12月為Kubernetes提供的一個開源服務網格 Conduit v0.1。
隨著業務敏捷性需求的增加，我們開始看到一個向“推送”架構或者基於事件體系結構的發展趨勢，即：一個服務傳送一個事件，一個或多個觀察者容器非同步地執行邏輯來響應該事件，而不需要通知事件生產者。與請求-響應架構不同，在事件驅動的系統中，啟動容器中的功能流程和事務負載並不依賴於下游容器中遠端行程的可用性和完成情況。另一個好處是，在設計各自的服務時，開發人員可以更加獨立。
雖然開發人員可以將容器環境構建為事件驅動架構，但功能即服務（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用例尤其有效。
由於核心訪問控制，打包在容器中的應用程式從根本上更安全。在VM環境中，唯一可見的點是虛擬裝置驅動程式。現在應用程式移動到容器環境，作業系統具有syscalls和semantic含義。這是一個更加豐富的訊號。以前的運運算元透過將代理放入VM來實現某些訊號，但它比較複雜並且需要很多管理工作。容器環境下要提供清晰的視覺化和整合功能，而這些工作量與VM環境工作量相比是微不足道的。
考慮到這一點，451研究調查報告[3]說，安全是容器應用的最大障礙——挑戰依然存在！ 最初，漏洞是容器環境中的主要安全問題。隨著公共註冊中心中隨時可用的容器映像的數量成倍增加，確保它們沒有漏洞變得非常重要。人工處理、映象掃描和授權認證已經成為一種常態處理方式。
與虛擬機器管理程式作為訪問和控制點的虛擬化環境不同，任何具有訪問核心根的容器最終都可以訪問核心上的所有容器。反過來，組織必須確保容器如何與宿主機互動，哪些容器可以執行某些操作或系統命令。增強主機控制以確保正確配置cgroups和namespace對於維護安全性也很重要。
最後，傳統防火牆依靠IP地址規則來把關網路流。這種技術無法擴充套件到容器環境，因為動態編排器會復用IP地址。
執行時威脅檢測和響應對生產環境至關重要，透過對容器環境進行指紋識別，並構建詳細的行為基線影象，可以容易地檢測到異常行為和攻擊者的沙箱。一份451的研究報告指出，52%的被調查公司在生產環境中執行容器，這表明容器的執行時威脅檢測解決方案正在加速發展。
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框架這樣的替代環境中發展，將會非常有趣。
最初由Netflix推廣，後來被亞馬遜（Amazon）、谷歌、微軟（Microsoft）和Facebook應用，在系統上進行混沌工程實驗，以提高其在生產問題上的確定性。混沌工程在過去的十年裡不斷發展。它從Chaos Monkeys開始，它們在生產環境中關閉了服務，並且擴充套件到更大的環境中使用失敗註入測試（FIT）和Chaos Kong。
錶面上看來，混亂工程僅僅是為了註入混亂。雖然破壞系統可能很有趣，但它並不總是有效或提供有用的資訊。混沌工程包含了更廣泛的範圍，不僅僅是註入故障，還包括其他場景，如流量峰值、異常請求組合等，以發現現存的問題。除了驗證假設之外，它還應該顯示系統的新屬性。透過發掘系統的弱點，團隊可以幫助提高彈性，預防糟糕的客戶體驗。
像神經網路和深度學習這樣的複雜的新技術，相比證明它們的有效性，理清它們的工作原理可能會變得不那麼重要。混沌工程透過對系統進行整體測試來識別不穩定性，從而幫助應對這一挑戰。隨著工程師們努力使他們日益複雜的系統變得更加健壯，這可能會成為一種更為普遍的做法。
隨著混沌工程變得越來越主流，它可以採用現有的開源專案、商業產品的形式，或者用上文提到的服務網格形式實現。
-
https://buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one/
-
https://www.oreilly.com/ideas/chaos-engineering
-
https://coreos.com/blog/451-research-container-survey-results
原文連結：https://medium.com/memory-leak/5-microservices-trends-to-watch-in-2018-aed135f70e51
本次培訓包含：Kubernetes核心概念；Kubernetes叢集的安裝配置、運維管理、架構規劃；Kubernetes元件、監控、網路；針對於Kubernetes API介面的二次開發；DevOps基本理念；微服務架構；微服務的容器化等，點選識別下方二維碼加微信好友瞭解具體培訓內容。
長按二維碼向我轉賬
![]()
受蘋果公司新規定影響，微信 iOS 版的贊賞功能被關閉，可透過二維碼轉賬支援公眾號。
知識星球