2018 微服務 5 大趨勢

2018-10-11 16:57

對於DevOps來說,2017年是重要的一年,因爲生態系統參與者數量大幅增長,CNCF項目增加了兩倍。展望未來一年,我們預計創新和市場變化將進一步加速。以下是我們對2018年微服務趨勢的總結:服務網格、事件驅動架構、容器原生安全性、GraphQL和chaos engineering。

 

我們將關注這些趨勢,以及在未來一年圍繞這些趨勢開展業務的公司。你看到了什麼趨勢?在下面的評論讓我們知道我們遺漏了什麼,或者如果你同意/不同意我們在這裏概述的觀點。

 

 

1.服務網格很流行!

 

服務網格是一個專用的基礎設施層,用於改善服務到服務的通信,是目前最熱門的關於雲的本地類別。隨着容器變得越來越流行,服務拓撲變得越來越動態,需要改進的網絡功能。服務網格可以通過服務發現,路由,負載平衡,運行狀況檢查和可觀察性來幫助管理流量。服務網格試圖馴服不守規矩的容器複雜性。

 

很明顯,服務網絡越來越受歡迎,因爲像HAProxy,traefik和NGINX這樣的負載均衡器已經開始將自己重新定位爲數據平面。我們還沒有看到廣泛的部署,但我們知道在生產中運行服務網格的企業。此外,服務網格不是微服務或Kubernetes環境專有的,也可以應用於VM和無服務器環境。例如,國家生物技術信息中心沒有運行容器,但它正在使用Linkerd。

 

服務網格也可以用於混沌工程,“在分佈式系統上進行實驗的學科,以建立對系統承受湍流條件的能力的信心。”而不是安裝在每個主機上運行的守護進程,服務網格可以注入延遲和進入環境的失敗。Istio和Buoyant 的 Linkerd 是該領域最引人注目的產品。請注意,Buoyant去年12月發佈了針對Kubernetes的開源服務網絡Conduit v0.1。

 

 

 

 

2.事件驅動架構的崛起。

 

隨着對業務敏捷性的需求的增加,我們開始看到向“推送”或基於事件的架構的轉變,其中一個服務發送一個事件,一個或多個觀察該事件的觀察器容器通過異步運行邏輯來響應而沒有事件生產者意識到。與請求 - 響應體系結構不同,在事件驅動系統中,啓動容器中的功能流程和事務負載不依賴於下游容器中遠程進程的可用性和完成。這樣做的另一個優點是開發人員在設計各自的服務時可以更加獨立。

 

雖然開發人員可以將容器環境設計爲事件驅動,但函數即服務(FaaS)本質上體現了這種質量。在FaaS體系結構中,函數作爲文本存儲在數據庫中,並由事件觸發。調用該函數後,API控制器接收消息並通過負載均衡器將其發送到消息總線,消息總線將其排隊等待調度並配置到調用程序容器。執行後,結果存儲在數據庫中,用戶將被髮送結果,並且該函數將被解除,直到再次觸發爲止。

 

FaaS的好處包括:1)縮短從編寫代碼到運行服務的時間,因爲沒有工件可以創建或超越源代碼,2)由於函數由AWS Lambda等FaaS平臺管理和擴展,所以開銷減少。然而,FaaS並非沒有挑戰。由於FaaS需要將每個服務分離,因此可能存在大量函數,這些函數很難發現,管理,協調和監控。最後,如果沒有包括依賴關係在內的全面可見性,很難調試FaaS系統,並且可能會出現無限循環。

 

目前,FaaS不適合需要更長調用,大量數據加載到內存以及一致性能的進程。雖然開發人員將FaaS用於後臺作業和時間事件,但我們相信隨着存儲層的加速和平臺性能的提高,用例將隨着時間的推移而擴展。

 

2017年秋季,雲原生計算基金會(CNCF)調查了550人,其中31%使用無服務器技術,28%計劃在未來18個月內使用無服務器。調查隨後詢問正在使用哪個特定的無服務器平臺。在使用無服務器技術的169箇中,77%表示他們使用AWS Lambda。雖然Lambda可能是領先的無服務器平臺,但我們相信可能會有一些有趣的機會。Edgecompute對於物聯網和AR / VR使用場景尤爲強大。

 

 

3.安全需求正在發生變化。

 

由於內核訪問,默認情況下,打包在容器中的應用程序基本上更安全。在VM環境中,唯一的可見性點是虛擬設備驅動程序。現在轉移到容器環境,操作系統具有系統調用和語義含義。這是一個更豐富的信號。以前,運營商可以通過將代理放入虛擬機來實現這一信號,但這很複雜且需要管理很多。容器提供更清晰的可見性,與VM環境相比,容器環境中的集成是微不足道的。

 

考慮到這一點,451 Research調查顯示,安全性是容器採用的最大障礙 - 挑戰仍然存在!最初,漏洞是容器環境中的主要安全問題。隨着公共註冊表中即用型容器圖像的數量成倍增加,確保它們也沒有漏洞變得非常重要。超時,圖像掃描和身份驗證已經成爲一種商品。

 

與虛擬機管理程序作爲訪問和控制點的虛擬化環境不同,任何可訪問內核根目錄的容器最終都可以訪問內核上的所有容器。反過來,組織必須保護容器與主機的交互方式,以及哪些容器可以執行某些操作或系統調用。強化主機以確保正確配置組和命名空間對於維護安全性也很重要。

 

最後,傳統防火牆依靠IP地址規則來允許網絡流量。此技術無法擴展到容器環境,因爲動態協調器會重用IP。運行時威脅檢測和響應對於生產環境至關重要,並通過對容器環境進行指紋識別併爲行爲基線構建詳細圖片來實現,因此很容易檢測到異常行爲並對攻擊者進行沙箱處理。451研究報告指出,52%接受調查的公司正在生產集裝箱,這表明企業採用容器本地運行時威脅檢測解決方案的速度加快。

 

 

4.從REST遷移到GraphQL。

 

GraphQL於2012年由Facebook創建,於2015年開源,是一種API規範,它是一種查詢語言和用於完成查詢的運行時。GraphQL類型系統允許開發人員定義數據模式。可以添加新字段,並且可以在不影響現有查詢或重構客戶端應用程序的情況下老化字段。GraphQL功能強大,因爲它不依賴於特定的數據庫或存儲引擎。

 

GraphQL服務器作爲單個HTTP端點運行,表示服務的全部功能。通過在類型和字段(而不是像REST這樣的端點)方面定義資源之間的關係,GraphQL可以遵循屬性之間的引用,因此服務可以使用單個查詢從多個資源接收數據。或者,REST API需要爲單個請求加載多個URL,從而增加網絡躍點,從而減慢查詢速度。通過減少往返次數,GraphQL減少了每個數據請求所需的資源數量。返回的數據通常格式爲JSON。

 

使用GraphQL而不是REST還有其他好處。首先,客戶端和服務器是分離的,因此可以單獨維護它們。與REST不同,GraphQL使用類似的語言在客戶端和服務器之間進行通信,因此調試更容易。查詢的形狀完全匹配從服務器獲取的數據的形狀,與其他語言(如SQL或Gremlin)相比,使GraphQL高效且有效。查詢反映其響應的形狀,因此可以檢測到偏差,並且可以識別未正確解析的字段。由於查詢更簡單,因此整個過程更加穩定。衆所周知,該規範支持外部API,但我們發現它也被用於內部API。

 

GraphQL用戶包括Amplitude,Credit Karma,KLM,NY Times,Twitch,Yelp等。11月,亞馬遜通過推出包含GraphQL支持的AWS AppSync驗證了GraphQL的流行程度。看看GraphQL如何在諸如Twitch的Twirp RPC框架之類的gRPC和替代方案中發展,將會很有趣。

 

 

5.Chaos工程變得越來越出名。

 

最初由Netflix推廣,後來由亞馬遜(Amazon)、谷歌、微軟(Microsoft)和Facebook進行實踐,Chaos工程在一個系統上進行實驗,以提高其抵禦生產問題的能力。Chaos工程在過去十年中不斷髮展。它從關閉生產環境中的服務的Chaos monkey開始,並通過故障注入測試(FIT)和用於更大環境的Chaos Kong擴展了其規模。

 

從表面上看,Chaos工程只不過是注入混亂。雖然破壞系統可能很有趣,但它可能並不總是富有成效或提供有用的信息。Chaos engineering包含更廣泛的範圍,不僅包括注入失敗,還包括其他一些症狀,如交通阻塞、不尋常的請求組合等,以發現存在的問題。除了驗證假設,它還應該揭示系統的新特性。通過挖掘系統弱點,團隊可以幫助提高彈性,防止客戶體驗差。

 

像神經網絡和深度學習這樣的新技術是如此的複雜,以至於決定某物如何工作可能變得不如證明它是否正常運作那麼重要。Chaos工程通過對系統進行整體測試來識別不穩定性,從而幫助解決這一難題。隨着工程師們努力使他們日益複雜的系統更加健壯,這可能會成爲一種更爲普遍接受的做法。

 

隨着chaos工程變得更加主流,它可以採用現有的開源項目、商業產品,或者如上所述,通過服務網格實現。

 

英文原文:5 Microservices Trends to Watch in 2018

原文:开源中国://www.oschina.net/translate/5-microservices-trends-to-watch-in-2018?lang=chs&p=1

翻譯:硅谷課堂、liyue李月