??對于DevOps來說，2017年是重要的一年，在這一年中，DevOps生態(tài)的參與者人數(shù)持續(xù)增長，CNCF（云原生計算基金會）的項目增加了兩倍。我們預(yù)計，在接下來的一年中，創(chuàng)新和市場調(diào)整能進一步加速這種增長趨勢。以下是我們對2018年微服務(wù)趨勢的總結(jié)：服務(wù)網(wǎng)格、事件驅(qū)動架構(gòu)、容器原生安全性、GraphQL和混沌工程（Chaos Engineering）。
1. 服務(wù)網(wǎng)格很熱門！
??服務(wù)網(wǎng)格作為一個改善服務(wù)到服務(wù)通信的專用基礎(chǔ)設(shè)施層，是云原生范疇中最熱門的話題。隨著容器愈加流行，服務(wù)拓撲也頻繁變動，這就需要更好的網(wǎng)絡(luò)性能。服務(wù)網(wǎng)格能夠通過服務(wù)發(fā)現(xiàn)、路由、負載均衡、心跳檢測和支持可觀測性，幫助我們管理網(wǎng)絡(luò)流量。服務(wù)網(wǎng)格試圖為無規(guī)則的復(fù)雜的容器問題提供規(guī)范化的解決方案。
??像HAproxy、Traefik和Nginx一類的負載均衡器已經(jīng)開始將自己重新定位，作為Web應(yīng)用中的數(shù)據(jù)層，由此顯而易見，服務(wù)網(wǎng)格正越來越受歡迎。雖然至今我們還沒有發(fā)現(xiàn)服務(wù)網(wǎng)格被廣泛的部署，但我們明確的知道許多公司正在產(chǎn)品中使用服務(wù)網(wǎng)格這種技術(shù)。此外，服務(wù)網(wǎng)格并不是微服務(wù)或者Kubernetes環(huán)境專有的，它還可以應(yīng)用到虛擬機和無服務(wù)器環(huán)境中。例如，美國國家生物技術(shù)信息中心并沒有運行容器，但它仍可以使用Linkerd。
??服務(wù)網(wǎng)格也可以用于混沌工程——“一門在分布式系統(tǒng)上進行實驗的學(xué)科，目的是構(gòu)建能夠應(yīng)對極端條件的可靠系統(tǒng)”。服務(wù)網(wǎng)格能夠?qū)⒀舆t和錯誤注入到環(huán)境中，而不需要在每個主機上安裝一個守護進程。
??Istio和Buoyant 的 Linkerd 是該領(lǐng)域最引人注目的產(chǎn)品。值得注意的是，Buoyant去年12月份發(fā)布了針對Kubernetes的開源服務(wù)網(wǎng)格Conduit v0.1。
2. 事件驅(qū)動架構(gòu)的崛起
??隨著對業(yè)務(wù)敏捷性需求的增加，我們開始看到向“推送”或者事件驅(qū)動架構(gòu)轉(zhuǎn)變的趨勢——由一個服務(wù)發(fā)送事件，一個或多個觀察者容器異步地響應(yīng)事件，而不需要通知事件的生產(chǎn)者。與請求-響應(yīng)架構(gòu)不同，在事件驅(qū)動系統(tǒng)中，啟動容器中的功能流程和事務(wù)不依賴于下游容器的遠程進程的可用性和完成情況。這樣做的另一個優(yōu)點是，開發(fā)人員在設(shè)計各自的服務(wù)時可以更加獨立。
??雖然開發(fā)人員可以將容器環(huán)境設(shè)計為事件驅(qū)動，但本質(zhì)上是FaaS（函數(shù)即服務(wù)）體現(xiàn)了事件驅(qū)動這一性質(zhì)。在FaaS架構(gòu)中，一個函數(shù)被作為文本保存在數(shù)據(jù)庫中，等待被某一個事件觸發(fā)。當函數(shù)被調(diào)用后，API controller接收消息，并通過負載均衡器將其發(fā)送到消息總線，消息總線將其放進隊列中等待被調(diào)度并配置到調(diào)用者容器。執(zhí)行完成后，結(jié)果被存儲到數(shù)據(jù)庫中，并發(fā)送給用戶，與此同時，該函數(shù)被解除，直到被再次觸發(fā)。
??FaaS的好處包括：（1）縮短從編寫代碼到運行服務(wù)的時間，因為除了源碼之外，不需要創(chuàng)建或推送任何組件，（2）開銷減少，得益于像AWS Lambda這樣的FaaS平臺管理和擴展著函數(shù)。然而，F(xiàn)aaS也不是一顆完美的銀彈。由于FaaS需要將每個服務(wù)解耦，因此可能存在大量函數(shù)難以被發(fā)現(xiàn)、管理、協(xié)調(diào)和監(jiān)控。最終，如果沒有包括依賴關(guān)系在內(nèi)的全面可視化，調(diào)試FaaS系統(tǒng)將很困難，并且可能會出現(xiàn)死循環(huán)。
??目前，在使用過長的調(diào)用鏈，需要將大量數(shù)據(jù)加載到內(nèi)存中以及需要滿足一致性的進程等這些場景中，F(xiàn)aaS并不適用。盡管開發(fā)人員通常只在后臺作業(yè)和時間事件中使用FaaS，我們?nèi)韵嘈烹S著存儲層的加速和平臺性能的提高，F(xiàn)aaS的適用范圍將隨著時間的推移得到拓展。
??2017年秋季，CNCF調(diào)查了550余人，其中31%使用無服務(wù)器技術(shù)，28%計劃在未來18個月內(nèi)使用無服務(wù)器技術(shù)。調(diào)查隨后提到使用何種無服務(wù)器平臺，77%回答是AWS Lambda。AWS Lambda可能是領(lǐng)先的無服務(wù)平臺，然而，我們?nèi)韵嘈趴赡苡泻芏嘤腥さ臋C會。邊緣計算（Edge Compute）對于物聯(lián)網(wǎng)和AR/VR使用場景尤為重要。
3. 安全需求發(fā)生變化
??由于內(nèi)核訪問控制，在默認情況下，容器中的應(yīng)用基本上很安全。在虛擬機環(huán)境中，唯一可見的點是虛擬設(shè)備驅(qū)動程序。在容器環(huán)境中，操作系統(tǒng)擁有系統(tǒng)調(diào)用和語義。這意味著更加豐富的功能。在此之前，運營商通過向虛擬機中放置代理來完成其中某些功能，但這很復(fù)雜而且難于管理。容器提供了更清晰的可見性，并且與虛擬機環(huán)境相比，容器環(huán)境不需要集成多余的代理。
??盡管如此，據(jù)一項調(diào)查顯示，安全性是使用容器的最大障礙，也就是說，容器仍然存在安全問題。最初，漏洞是容器環(huán)境中的主要安全問題。隨著即用型容器鏡像數(shù)量的成倍增加，確保它們也沒有漏洞變得非常重要。隨著時間推移，掃描鏡像和身份認證已經(jīng)成為一種商品。
??與虛擬機管理程序作為訪問和控制點的虛擬化環(huán)境不同，任何可訪問內(nèi)核根目錄的容器基本上都可以訪問內(nèi)核上的所有容器。反過來，組織必須保證容器與主機的交互的安全，以及控制哪些容器可以執(zhí)行某些操作或系統(tǒng)調(diào)用。增強主機控制以確保正確配置組和命名空間對于維護安全性也很重要。
??最后，傳統(tǒng)的防火墻依賴IP地址規(guī)則來管理網(wǎng)絡(luò)流量。該技術(shù)無法被擴展到容器環(huán)境中，因為動態(tài)協(xié)調(diào)器會復(fù)用IP。運行時安全檢測和響應(yīng)對于生產(chǎn)環(huán)境至關(guān)重要，它通過對容器環(huán)境進行指紋識別并構(gòu)建詳細的行為基線圖像來實現(xiàn)，因此很容易檢測到異常行為并對攻擊者進行沙箱處理。上文提到的調(diào)查指出，52％接受調(diào)查的公司在生產(chǎn)環(huán)境中運行容器，這表明容器的運行時安全檢測解決方案的正在加速發(fā)展。
4. 從REST遷移到GraphQL
??GraphQL是一種滿足查詢需求的API規(guī)范，由Facebook在2012年創(chuàng)建，并于2015年開源。GraphQL類型系統(tǒng)允許開發(fā)人員自定義數(shù)據(jù)模式?？梢蕴砑有碌淖侄?，并可以在不影響現(xiàn)有查詢或重構(gòu)客戶端應(yīng)用程序的情況下對字段進行更新。GraphQL的強大在于它不需要綁定到特定的數(shù)據(jù)庫或存儲引擎。
??GraphQL服務(wù)器作為一個獨立的HTTP端點運行，能夠表達服務(wù)的全部功能。通過在類型和字段上定義資源之間的關(guān)系（而不是像REST一樣的端點），GraphQL可以追蹤屬性之間的引用，因此服務(wù)可以使用單個查詢從多個數(shù)據(jù)源中獲取數(shù)據(jù)。此外，REST API需要為單個請求加載多個URL，這導(dǎo)致網(wǎng)絡(luò)請求增多，降低了查詢速度。由于需要更少的通信次數(shù)，GraphQL減少了每個數(shù)據(jù)請求所需的資源數(shù)量。返回的數(shù)據(jù)通常格式化為JSON。
??與REST API相比，GraphQL還有很多其他優(yōu)點。首先，客戶端和服務(wù)器是解耦的，因此可以獨立地維護它們。與REST不同，GraphQL在客戶機和服務(wù)器之間使用的語言非常類似，這使得調(diào)試更容易。查詢語句的數(shù)據(jù)形式與從服務(wù)器獲取的數(shù)據(jù)形式完全匹配，這使得GraphQL與SQL或Gremlin等其他語言相比更加高效和有效。查詢語句反映了它們的響應(yīng)的形式，因此可以檢測到錯誤，并且可以識別出不能被正確解析的字段。更簡單的查詢使得整個進程的穩(wěn)定性更強。眾所周知，該規(guī)范支持外部api，而我們發(fā)現(xiàn)它也被用于內(nèi)部api。
??GraphQL的用戶包括 Amplitude、Credit Karma、KLM、NY Times、Twitch、Yelp等。去年11月，Amazon通過推出支持GraphQL的AWS AppSync證明了GraphQL的流行程度。觀察GraphQL將如何在gRPC和諸如Twitch的Twirp RPC框架這樣的替代環(huán)境中發(fā)展，將會非常有趣。
5. 混沌工程愈發(fā)出名
??混沌工程實驗最初由Netflix推廣，后來被亞馬遜、谷歌、微軟和Facebook實際應(yīng)用，它在系統(tǒng)上實驗，以提高解決生產(chǎn)問題的能力。混沌工程在過去的十年里不斷發(fā)展。最初是從Chaos Monkeys開始——在生產(chǎn)環(huán)境中隨機殺死某個服務(wù)，并且通過使用失敗注入測試（FIT）和Chaos Kong擴展到更大的環(huán)境中。
??表面上看來，混亂工程僅僅是注入故障。雖然破壞系統(tǒng)可能很有趣，但它并不總是有效或者能提供有用的信息?；煦绻こ贪烁鼜V泛的范圍，不僅僅是注入故障，還包括其他場景，如網(wǎng)絡(luò)擁堵、異常請求組合等，來發(fā)現(xiàn)存在的問題。除了驗證假設(shè)之外，它還應(yīng)該能夠揭示系統(tǒng)的新屬性。通過發(fā)掘系統(tǒng)的弱點，團隊可以提高系統(tǒng)的可伸縮性，防止客戶的體驗變差。
??像神經(jīng)網(wǎng)絡(luò)和深度學(xué)習這樣的復(fù)雜的新技術(shù)，與證明它們的有效性相比，證明它們?yōu)槭裁茨軌蛴行ё兊貌荒敲粗匾??；煦绻こ掏ㄟ^對系統(tǒng)進行整體測試來識別不穩(wěn)定性，從而幫助團隊應(yīng)對這一挑戰(zhàn)。隨著工程師們努力地使他們?nèi)找鎻?fù)雜的系統(tǒng)更加健壯，混沌工程可能會被普遍接受。
??隨著混沌工程變得越來越主流，它可以采用現(xiàn)有的開源項目、商業(yè)產(chǎn)品的形式，或者通過上文提到的服務(wù)網(wǎng)格來實現(xiàn)。
