摘要：劉超，網易云計算首席架構師，有多年的云計算架構與開發經歷，積累了豐富的企業級應用的微服務化，容器化實戰經驗。近日，記者對劉超進行了采訪，跟大家分享了微服務實戰的挑戰和一些常見的微服務誤解，以及他對微服務發展趨勢的判斷。

劉超，網易云計算首席架構師，有10多年的云計算架構與開發經歷，積累了豐富的企業級應用的微服務化，容器化實戰經驗。劉超將擔任今年 5 月份 QCon 全球軟件開發大會廣州站「微服務實戰」專題的出品人，為大家策劃幾場微服務相關的內容豐富的分享。

近日，InfoQ 記者對劉超進行了采訪，跟大家分享了微服務實戰的挑戰和一些常見的微服務誤解，以及他對微服務發展趨勢的判斷。歡迎關注網易云微信公眾號：Netease_Cloud，獲取更多微服務相關內容。

1、InfoQ：劉超老師，請先介紹一下自己吧。
劉超： 我是網易云的首席架構師，主要負責兩部分工作，對內支撐網易核心業務上云，例如考拉，云音樂，云課堂，對外輸出網易的微服務經驗，幫助客戶搞定容器化與微服務化架構，已經在銀行、證券、物流、視頻監控、智能制造等多個行業落地。

2、InfoQ：網易云在微服務方面的探索有哪些？落地過程中有哪些難點？
劉超： 網易云的技術團隊在博客時代就開始探索互聯網架構，是在支撐博客用戶量、訪問量就爆發式增長的過程中，構建了聚焦微服務的網易云輕舟微服務平臺，并支撐內部考拉、云音樂、云課堂等核心業務。
在實施微服務的過程中，難點層出不窮，可謂見山開路，遇水搭橋。
實施服務化架構之后，首先實現的功能是進行統一的注冊發現和 RPC 的透明封裝，但是服務拆分多了，在 應用層面 就遇到以下問題：

服務雪崩：即一個服務掛了，整個調用鏈路上的所有的服務都會受到影響；

大量請求堆積、故障恢復慢：即一個服務慢，卡住了，整個調用鏈路出現大量超時，要長時間等待慢的服務恢復到正常狀態；

在基礎設施層面，還有另外的問題：

服務器資源分配困難，服務器機型碎片化：服務多了，各個團隊都要申請服務器，規格不一，要求多樣，管理十分困難；

一臺服務器上多個進程互相影響、QoS 難以保障：采用虛擬機或者物理機的部署，往往會多個進程放在一臺服務器上，高峰期影響嚴重；

測試環境數量大增，環境管理、部署更新困難：每個團隊都有反復部署測試環境，手動部署或者腳本部署過于復雜。

為了解決這些問題，我們在應用層面實施了以下方案：

通過熔斷機制，當一個服務掛了，被影響的服務能夠及時熔斷，使用 Fallback 數據保證流程在非關鍵服務不可用的情況下，仍然可以進行。

通過線程池和消息隊列機制實現異步化，允許服務快速失敗，當一個服務因為過慢而阻塞，被影響服務可以在超時后快速失敗，不會影響整個調用鏈路。

在基礎設施層面，我們實施了以下的方案：

統一基礎設施，擁抱容器標準，解決服務器碎片化和服務之間的隔離問題；

統一編排和彈性伸縮平臺，2015 年擁抱 Kubernetes 標準，解決了部署困難，環境不一致的問題；

打造 CI/CD 服務，抽象出產品、環境等多級概念，實現從代碼到測試到上線的自動部署。

隨著我們支撐的內部業務越來越多，又遇到了以下問題：

微服務框架選型不一，技術無法積累，面向業務定制化嚴重，上手成本高；

傳統依賴于應用運維的排障復雜度高，傳統監控服務無法滿足需求；

故障演練手段不一，硬編碼隨處可見；

API 版本管理混亂，無統一的監控，治理，無開發標準；

分布式事務支持方式不一，和業務綁定嚴重。

為了解決這些問題，我們實施了以下方案：

微服務框架與開源技術棧統一，將服務治理邏輯抽離、以無侵入方式實現、支持 Spring Cloud、Dubbo 等開源技術棧；

全鏈路跟蹤服務與日志服務依據 ID 進行聯系，以發現故障點上下文；

在 Agent 引入故障注入服務，可統一進行故障演練；

服務通過 API 網關暴露，引入 API 管理、測試平臺，自動 Client SDK 生成；

實現 TCC 中間件、事務消息隊列等標準中間件。

3、InfoQ：你如何理解微服務？微服務在當前技術形勢下處于一個什么樣的位置？
劉超： 微服務是一個非常復雜的問題，業內對微服務也存在一些誤解：

微服務主要的工作是服務拆分，主要考慮將服務拆分成什么粒度以及如何進行拆分；

微服務是一個運動式的過程，把大家關起門來封閉開發一個月，就能把架構修改好了，以后就萬事大吉了；

微服務僅僅是一個技術問題，交給開發團隊或者運維團隊去搞就可以了。

微服務絕不僅僅是服務拆分，就像上圖所示，拆分只是實施微服務十二個要點之一，因為拆分了服務之后，會面臨上面我們遇到的所有問題，沒有相應的工具和平臺，拆分的越細，越是一場災難。

微服務絕不是一個運動式的過程，而是應該漸進的過程，一旦實施了微服務，就處于業務系統不斷更新和迭代的狀態中，也處于不斷的拆分和組合中。所以不建議一開始就拆的特別細，不建議一勞永逸，而是隨著慢慢的拆成幾個，十幾個，幾十個，上百個的過程，將十二個要點所需要的工具、團隊、員工能力慢慢匹配到微服務狀態。

微服務絕不僅僅是個技術問題，牽扯到 IT 架構、應用架構、組織架構多個方面。微服務必定帶來開發、上線、運維的復雜度的提高，如果說單體應用復雜度為 10，實施了微服務后的復雜度將是 100，配備了相應的工具和平臺后，可以將復雜度降低到 50，但仍然比單體復雜的多。

所以實施微服務是有成本的，只有在業務層面遇到不微不行的痛點，例如痛到影響收入，痛到被競爭對手甩在后面，所以微服務往往是業務驅動或者高管驅動的，而實施微服務的結果又必然會影響到組織架構的變化，例如運維和開發的界限模糊——DevOps，專門中間件和架構師團隊的成立，數據中臺和業務中臺組的建立，小團隊自主決策等。

目前，大多數企業都意識到了微服務的重要性，但是各處的階段不同，我把微服務分成三個階段：

微服務 1.0，僅使用注冊發現，基于 SpringCloud 或者 Dubbo 進行開發，目前意圖實施微服務的傳統企業大部分處于這個階段，或者正從單體應用，向這個階段過渡，處于 0.5 的階段；

微服務 2.0，使用了熔斷，限流，降級等服務治理策略，并配備完整微服務工具和平臺，目前大部分互聯網企業處于這個階段。傳統企業中的領頭羊，在做互聯網轉型的過程中，正在向這個階段過渡，處于 1.5 的階段；

微服務 3.0，Service Mesh 將服務治理作為通用組件，下沉到平臺層實現，使得應用層僅僅關注業務邏輯，平臺層可以根據業務監控自動調度和參數調整，實現 AIOps 和智能調度。目前一線互聯網公司在進行這方面的嘗試。

4、InfoQ：你怎么看微服務未來的發展趨勢？
劉超： 前面大概談了一下微服務 3.0，這里詳細說一下我眼中的微服務的發展趨勢。
第一個就是 Service Mesh，他的主要作用就是將服務治理下沉到平臺層，進行統一的治理。
為什么會這樣呢？因為無論是在我們內部，還是在外部企業，都能看的這樣的趨勢。
最初只有物理機，虛擬機是放在云平臺上，由運維組統一管理的。

后來因為能力復用和開發速度的需要，數據庫、中間件成為了 PaaS 平臺用于部署通用的組件，持續發布也成了 PaaS 平臺，用于部署客戶的業務，所以這兩部分也平臺化了。

隨著越來越多的業務需要進行服務治理，微服務框架，APM，也成為了平臺的一部分。

但是微服務框架的統一，涉及多語言的問題，也涉及和應用層綁定的問題，無論是 Spring Cloud 還是 Dubbo，都很難完全平臺化，所以需要 Service Mesh，通過 sidecar 的方式，將控制面和數據面隔離，通過非侵入的模式進行流量攔截，實現真正的治理平臺化。

第二個就是 AIOps 和智能調度，就是通過對于海量數據中心收集的監控數據和業務數據，實現業務的自動調度和參數調整。

這個看起來很遙遠，其實不然，如果大家感興趣的話，可以在網上搜索一下，Google 在 2011 年就公布了自己數據中心收集的監控數據（https://github.com/google/clu...），并在 2014 年發表論文《Machine Learning Applications for Data Center Optimization》，使用 AI 技術優化數據中心的效率。

而國內一線互聯網公司也在 2018 年公布 4000 臺服務器真實數據集，也在干和 Google 類似的事情。

我們觀察到，當數據中心的機器規模突破十萬臺的時候，效率的提高就變成了一件能夠節省大量成本的事情，所以開始引起重視。而能做到這件事情，往往依靠的就是數據驅動的智能調度。

為了支撐強大的調度功能，Google 開發了 Borg，Twitter 壯大了 Mesos，并通過將這些調度平臺和機器學習相結合，實現自動化的智能調度，國內一線互聯網公司也在進行著積極的嘗試。

隨著微服務化和容器化，服務的數量會十分的龐大，從而運維難度大幅度提高，原來僅僅會運維物理機和虛擬化的技術人員是不夠的，而運維 Kubernetes 和 Docker 的人會比較貴，使得人力成本大幅度提高。

很多組織從物理機時代，到虛擬化時代，到云時代，再到容器時代，運維團隊的規模是越來越大的，每個人的薪資也越來越高。

所以將來只運維少量節點的私有化容器平臺，從成本上來講是不劃算的，當出現有公信力的公有云平臺，則使用公有云成為節約成本的理智選擇。

例如亞馬遜、谷歌等公有云平臺就沒有問題，谷歌里面的運維工程師相當貴，他們掌握最先進的技術是沒有任何問題的，但是他們會通過各種自動化，甚至智能化的技術，管理全球的幾百萬臺機器，這樣成本攤下來就不是很高了。如果你只是運維一個幾十個節點，最多幾百個節點的容器平臺，同樣需要招一些這么貴的人，一般的企業肯定受不了。所以將來要么是大規模公有云平臺，要么是土豪如電信金融行業的自建云平臺，都會出現超大規模的場景，基于 AIOps 和智能調度節約成本，就是勢在必然的了。

5、InfoQ：QCon 廣州的「微服務實戰」專題下設置了 4 個演講，作為出品人，你如何策劃這 4 個演講，想給參會者呈現微服務的哪些方面？劉超： 基于我們自己的微服務實踐，和對于微服務發展階段的理解，作為「微服務實戰」專題的出品人，我計劃全方位展示微服務在主流公司的主流技術方向的實踐和未來方向。

第一個方面就是 基于 Dubbo 的大規模微服務實踐的場景，Dubbo 是應用范圍非常廣的微服務框架，很多企業都是基于 Dubbo 做的，Dubbo 的實踐是微服務實施過程中繞不過去的一環，這個主題能夠解決很多技術人員實施海量 Dubbo 服務的時候遇到的問題。

第二個方面就是 基于 Spring Cloud 的大規模微服務實戰的場景，Spring Cloud 是近年來新興的微服務框架，很多新實施微服務的，會選擇基于 Spring Cloud，但是 Spring Cloud 雖然組件豐富，可選項多，但是也很復雜，學習曲線高，如何再海量場景下進行改進和適配，是經常遇到的問題，這個主題能夠給予技術人員實施 Spring Cloud 微服務的時候以借鑒意義。

第三個方面就是 Service Mesh 在高并發場景下的實踐場景，前面說了 Service Mesh 是一個趨勢，一線互聯網公司都在嘗試，但是這個技術太新了，很多坑還在踩，這個主題能夠帶給技術人員最前沿微服務技術的落地實踐，給想試試 Service Mesh 的技術人員以借鑒意義。

第四個方面就是 微服務框架各個方向的發展與未來趨勢，微服務涉及范圍廣，技術選型難，很多沒有實施微服務的技術人員面臨如此多的技術名詞，無所適從，選穩定的，會不會過時被淘汰，選先進的，會不會冒進出線上事故，選錯了技術方向，萬一開源的不維護了就麻煩大了，這個主題會講解微服務發展的技術趨勢和各個方向的優劣對比，給選型困難的技術人員以參考。

點擊這里了解網易云輕舟微服務平臺，獲取解決方案。

文章來源： 網易云社區