2019年最值得關注的五大微服務發展趨勢
2018年對於DevOps社群來說無疑是重要的一年。Kubernetes成為第一個從雲原生計算基金會（簡稱CNCF）畢業的專案；Pivotal公司完成了首輪公開募股；HashiCorp以19億美元成為獨角獸公司；VMware以近6億美元價碼收購Heptio等等。這一系列事件的出現，再次強調了DevOps浪潮的重要意義。
去年1月，我們 釋出的微服務發展趨勢預測 涵蓋了Service Meshes、事件驅動型架構、容器原生安全、GraphQL以及混沌工程等議題。雖然這些技術越來越受到歡迎，但我們在隨後的這一年中也觀察到了其它一些新興趨勢：1）測試自動化；2）持續部署/驗證（簡稱CD/CV）；3）事件響應；4）雲服務費用管理（簡稱CSEM）；5）Kubernetes面向機器學習（簡稱ML）的擴充套件等。
1. 方興未艾的測試自動化
從傳統角度講，由個人設計的測試用例主要用於確定軟體是否能夠在不同情況下正確執行。在通常情況下，質量保證（簡稱QA）工程師負責建立並執行此類測試用例。但到現在，由於測試驅動開發的興盛，軟體工程師正在逐漸接過傳統QA團隊的測試職責。換言之，開發人員開始在整個持續整合（簡稱CI）流程中執行測試。很明顯，測試會給開發人員帶來新的負擔，進而降低其生產效率水平。
我們相信企業需要一種能夠自動設計、執行並報告結果的軟體測試解決方案。通過對接持續整合系統，實時檢查新程式碼以及新增與人類工程師類似的註釋內容，這類解決方案需要有能力實現無摩擦介入。另外根據我們的觀察，這類測試解決方案還應通過使用者介面（簡稱UI）進行測試，以確保工程師能夠通過UI查詢問題並減少漏報機率。
軟體測試自動化的實現將有助於減少修復錯誤所需要的資源。一旦自動化軟體識別出錯誤，其即可自動生成錯誤修復程式。簡單的錯誤可以通過自動補丁修復，而複雜的錯誤則可利用人工設計的模板或者“基於異常的修復”解決——這些修復機制會對程式碼進行小幅更改，直到問題徹底消失。此外，推薦引擎能夠利用先前工程師修復的資料進行訓練，並在人工批准之前預先測試以提供明智的建議。
我們相信，軟體測試應該是人工智慧技術的一大重要應用方向，能夠幫助業界顯著提高生產力、改善成本、覆蓋範圍與準確性。我們之前已經表達過對於機器學習支援型軟體測試方案的興奮之情，現在我們仍然堅信這將是一個巨大的市場（總價值約32億美元），且正在逐步走向成熟。
2. 通過持續部署/驗證提高生產力
企業將繼續感受到軟體釋出週期加速要求帶來的壓力。持續部署（簡稱CD）允許我們將測試完畢的程式碼自動部署至生產環境當中。與持續交付這套用於確保程式碼快速安全部署至生產環境的一整套設計實踐不同，持續部署僅關注其中與部署相關的管理任務，旨在為下一步工作提供堅實的基礎。
持續部署將取代DevOps工程師的手動操作。根據我們瞭解到的情況，在一部分金融機構當中，每十位DevOps員工中就有一位負責面向生產環境的軟體部署任務。假設持續部署軟體能夠幫助其擺脫這些繁瑣的工作，即意味著將全球DevOps員工的價值提升10%，我們認為這部分市場的總規模將接近20億美元。
持續驗證（簡稱CV）在持續部署之上進一步新增智慧層。持續驗證負責從日誌及APM當中收集事件資料，並應用機器學習技術以瞭解導致部署成功及失敗的相關因素。持續驗證應該具備人機迴圈元件，確保工程師能夠提供反饋以提高模型準確性，同時逐步建立起對系統的信任度。持續驗證通常能夠安全地對失敗部署進行回滾操作。我們相信未來的持續驗證方案將幫助持續部署成為多雲環境內的智慧控制點，提供預測功能，面向雲、區域以及配置提供最佳洞察見解，並根據具體特徵實施部署服務調整。
雖然目前已經存在諸多持續部署解決方案，但我們還是在下圖當中列出了其中最受歡迎的十四款。其中包括閉源與開源專案，以及由公有云服務供應商提供的託管服務。這一領域中最為著名的解決方案當數Spinnaker，這個開源專案目前已經在GitHub上得到超過5600顆星。
3. 恢復性事件響應
站點可靠性工程師（簡稱SRE）主要負責管理複雜分散式系統的響應工作，此類系統往往面對彈性方面的實際挑戰。根據谷歌公司釋出的《站點可靠性工程》一書所言，站點可靠性工程師需要負責以自動化方式執行以往需要由系統管理員手動執行的流程。他們負責建立起面向“可用性、延遲、效能、效率、變更管理、監控、緊急響應以及服務的容量規劃方案”。很明顯，應急/事件響應亦是站點可靠性工程師份內的關鍵任務之一。
停機時間是一類具有重大財務影響的事件，因此加快問題解決速度變顯得非常重要。Gartner公司指出，由停機時間引起的平均營收損失高達每分鐘5.6萬美元。而像亞馬遜這樣的大型網路資產持有方每分鐘停機事故可能帶來22萬美元損失。在服務停止運營的每分每秒，企業都在蒙受鉅額經濟損失以及嚴重的品牌形象影響。
當服務發生故障時，擁有不同職能角色的響應團隊（包括事件指揮官）將收到警報，進而啟動一系列工作流程。事件指揮官負責維護一份涵蓋事件描述、狀況走向與修復結果的“事件狀態檔案”。每一位團隊成員都應針對預先定義的模板化程式執行問題解決流程。一旦問題得到解決，團隊還應參與事後分析，從而瞭解事件情況並儘可能避免其再次發生。谷歌公司建議團隊應記錄“事件本身、相關影響、為了緩解或解決事件所採取的行動、引發事件的根本原因以及有助於防止事件再次發生的事後行動”等，這將成為重要的後續指導素材。
我們經常聽到站點可靠性工程團隊利用PagerDuty、Slack、Jira、谷歌文件以及知識庫等載體進行事件響應處理。我們相信這些精確的解決方案能夠在端到端SaaS平臺中被繫結在一起，從而支撐起自動化修復行動並貫徹最佳實踐指導。這套統一的平臺還將加速平均恢復時間（簡稱MTTR）、協作與知識共享的實施速度。
我們已經確定了五種能夠提供現代事件響應功能的解決方案。這些集中式平臺不僅能夠分解職能角色並啟動工作流程，同時亦應說明事件的潛在影響、當前狀態、事件時間表以及超時後果。我們相信，這些平臺可以作為混沌工程的有力補充（混沌工程是一種彈性測試最佳實踐方案）。著眼於未來，這些平臺還有望將事件資訊輸入至混沌工程解決方案（例如Gremlin）當中，從而告知應對哪些服務進行預防性測試。這類平臺的持續完善將顯著提高後端彈性水平，最終幫助運營工程師們更安心地享受晚間時光。
4. 雲服務費用管理（簡稱CSEM）助力成本節約
時至今日，公有云成本管理已經成為少數不僅給工程與IT團隊帶來深刻影響，更在整個公司內得到高度關注的挑戰之一。大多數企業目前都採用混合雲方法，但單純使用公有云方案的客戶正在快速增加。根據Gartner公司的統計，IaaS與PaaS全球收入將由2018年的462億美元增長至2018年的907億美元，年均複合增長率高達25%。Rightscale公司釋出的報告亦指出，在接受調查的997名IT專業人員當中，有92%正在使用公有云，81%在使用多雲策略。事實上，公有云確實能夠帶來一系列重要收益，包括安全性與可用性提升，降低運營及公共資源的支出與成本等等。隨著公有云的進一步普及以及採用度的快速提高，我們認為成本管理與預測能力的重要性將得到進一步凸顯。
由於種種原因的共同作用，雲成本管理成為一項極具挑戰的工作。有不少團隊已經開始使用公有云服務，但監督機制還沒有跟上，於是把雲方案強行變成了某種影子IT產物。這種治理缺失可能導致服務蔓延。面對來自上級的“快速行動”與績效要求壓力，開發人員可能會在個人評估過程中忽視成本問題。服務的廣度與頻繁的價格變化同樣使得雲開支追蹤變得極為困難。一部分雲賬單中包含超過10億條支出線，這意味著一般的企業幾乎不可能對其做出準確解析。面對這一系列挑戰，Gartner公司做出總結，表示“到2020年，將有80%的組織遭遇雲IaaS預算超標的問題。”
在下圖當中，我們整理出十八種代表公有云與第三方服務的雲服務費用管理解決方案選項。其中VMware拿出了CloudHealth，後者於2018年8月接受了虛擬巨頭5億美元的收購開價。Azure於2018年以5000萬到7000萬美元的價格買下Cloudyn，並將其產品重新命名為Azure Cost Management。2019年1月初，亞馬遜公司收購TSO Logic用以充實自家產品組合。2018年，Forrester公司釋出的《 雲成本監控與優化 》報告對九大供應商進行了分析，其中VMware CloudHealth與Rightscale佔據領先位置。
儘管目前雲成本管理解決方案的數量已經相當可觀，但成本控制仍是一個難以解決的痛點。運營人員經常向我們抱怨稱，雲服務費用管理工具應該實現跨平臺結果規範化，並將雲資源對映至特定的所有者及團隊處，以確保財務部門能夠將支出與特定產品或業務單位對應起來。Gartner公司表示，如果缺少這種有效的管理能力，雲服務的綜合利用率很可能會長期低於35%。另外，此類解決方案還應確定出優化空間，例如由雲服務費用管理工具識別過度配置或者長期空閒的資源。該軟體需要支援保留與競價例項、例項規模持續調整、退單、設定自定義折扣功能以及標記異常支出等等。此外，其還需要根據增加的流量、資料儲存要求以及服務利用率來預測特定時間段內的支出水平。隨著公有云資源使用量的不斷增加，我們預計成本管理與預測的重要性也將同步提升。
5. Kubernetes面向機器學習的擴充套件
Kubernetes正風靡整個DevOps世界，並已經成為當前容器領域的首選編排解決方案。其適用範圍不斷擴大，而我們也希望其能夠成為機器學習平臺堆疊中的組成部分。舉例來說，谷歌公司釋出了開源Kuberflow，其通過向叢集之內新增定製化資源定義（簡稱CRD）的方式擴充套件Kubernetes API，從而提高機器學習工作負載的執行優先順序。在KubeCon西雅圖2018大會期間，Kubeflow成為最受關注的雲原生專案之一。事實上，谷歌並非唯一一家做出探索的廠商。Lyft也在利用Kubernetes構建起自己的機器學習平臺。我們聽說，亦有其它獨角獸企業嘗試對Kubernetes進行標準化，從而將其作為機器學習與分析工作負載的處理平臺。
我們將在明年的這個時候繼續關注測試自動化、持續部署/持續驗證、事件響應、雲服務費用管理以及Kubernetes面向機器學習的擴充套件等議題。如果您自己或者朋友供職於探索這些領域的開源專案或初創企業，也期待著您能夠結合自身體會談談看法。最後，期待看到您的評論，包括我們可能沒有談到的重要內容或者是您對於上述問題的不同觀點。感謝閱讀！