摘要：劉超，網(wǎng)易云計(jì)算首席架構(gòu)師，有多年的云計(jì)算架構(gòu)與開發(fā)經(jīng)歷，積累了豐富的企業(yè)級(jí)應(yīng)用的微服務(wù)化，容器化實(shí)戰(zhàn)經(jīng)驗(yàn)。近日，記者對(duì)劉超進(jìn)行了采訪，跟大家分享了微服務(wù)實(shí)戰(zhàn)的挑戰(zhàn)和一些常見的微服務(wù)誤解，以及他對(duì)微服務(wù)發(fā)展趨勢(shì)的判斷。

劉超，網(wǎng)易云計(jì)算首席架構(gòu)師，有10多年的云計(jì)算架構(gòu)與開發(fā)經(jīng)歷，積累了豐富的企業(yè)級(jí)應(yīng)用的微服務(wù)化，容器化實(shí)戰(zhàn)經(jīng)驗(yàn)。劉超將擔(dān)任今年 5 月份 QCon 全球軟件開發(fā)大會(huì)廣州站「微服務(wù)實(shí)戰(zhàn)」專題的出品人，為大家策劃幾場(chǎng)微服務(wù)相關(guān)的內(nèi)容豐富的分享。

近日，InfoQ 記者對(duì)劉超進(jìn)行了采訪，跟大家分享了微服務(wù)實(shí)戰(zhàn)的挑戰(zhàn)和一些常見的微服務(wù)誤解，以及他對(duì)微服務(wù)發(fā)展趨勢(shì)的判斷。歡迎關(guān)注網(wǎng)易云微信公眾號(hào)：Netease_Cloud，獲取更多微服務(wù)相關(guān)內(nèi)容。

1、InfoQ：劉超老師，請(qǐng)先介紹一下自己吧。
劉超： 我是網(wǎng)易云的首席架構(gòu)師，主要負(fù)責(zé)兩部分工作，對(duì)內(nèi)支撐網(wǎng)易核心業(yè)務(wù)上云，例如考拉，云音樂(lè)，云課堂，對(duì)外輸出網(wǎng)易的微服務(wù)經(jīng)驗(yàn)，幫助客戶搞定容器化與微服務(wù)化架構(gòu)，已經(jīng)在銀行、證券、物流、視頻監(jiān)控、智能制造等多個(gè)行業(yè)落地。

2、InfoQ：網(wǎng)易云在微服務(wù)方面的探索有哪些？落地過(guò)程中有哪些難點(diǎn)？
劉超： 網(wǎng)易云的技術(shù)團(tuán)隊(duì)在博客時(shí)代就開始探索互聯(lián)網(wǎng)架構(gòu)，是在支撐博客用戶量、訪問(wèn)量就爆發(fā)式增長(zhǎng)的過(guò)程中，構(gòu)建了聚焦微服務(wù)的網(wǎng)易云輕舟微服務(wù)平臺(tái)，并支撐內(nèi)部考拉、云音樂(lè)、云課堂等核心業(yè)務(wù)。
在實(shí)施微服務(wù)的過(guò)程中，難點(diǎn)層出不窮，可謂見山開路，遇水搭橋。
實(shí)施服務(wù)化架構(gòu)之后，首先實(shí)現(xiàn)的功能是進(jìn)行統(tǒng)一的注冊(cè)發(fā)現(xiàn)和 RPC 的透明封裝，但是服務(wù)拆分多了，在 應(yīng)用層面 就遇到以下問(wèn)題：

服務(wù)雪崩：即一個(gè)服務(wù)掛了，整個(gè)調(diào)用鏈路上的所有的服務(wù)都會(huì)受到影響；

大量請(qǐng)求堆積、故障恢復(fù)慢：即一個(gè)服務(wù)慢，卡住了，整個(gè)調(diào)用鏈路出現(xiàn)大量超時(shí)，要長(zhǎng)時(shí)間等待慢的服務(wù)恢復(fù)到正常狀態(tài)；

在基礎(chǔ)設(shè)施層面，還有另外的問(wèn)題：

服務(wù)器資源分配困難，服務(wù)器機(jī)型碎片化：服務(wù)多了，各個(gè)團(tuán)隊(duì)都要申請(qǐng)服務(wù)器，規(guī)格不一，要求多樣，管理十分困難；

一臺(tái)服務(wù)器上多個(gè)進(jìn)程互相影響、QoS 難以保障：采用虛擬機(jī)或者物理機(jī)的部署，往往會(huì)多個(gè)進(jìn)程放在一臺(tái)服務(wù)器上，高峰期影響嚴(yán)重；

測(cè)試環(huán)境數(shù)量大增，環(huán)境管理、部署更新困難：每個(gè)團(tuán)隊(duì)都有反復(fù)部署測(cè)試環(huán)境，手動(dòng)部署或者腳本部署過(guò)于復(fù)雜。

為了解決這些問(wèn)題，我們?cè)趹?yīng)用層面實(shí)施了以下方案：

通過(guò)熔斷機(jī)制，當(dāng)一個(gè)服務(wù)掛了，被影響的服務(wù)能夠及時(shí)熔斷，使用 Fallback 數(shù)據(jù)保證流程在非關(guān)鍵服務(wù)不可用的情況下，仍然可以進(jìn)行。

通過(guò)線程池和消息隊(duì)列機(jī)制實(shí)現(xiàn)異步化，允許服務(wù)快速失敗，當(dāng)一個(gè)服務(wù)因?yàn)檫^(guò)慢而阻塞，被影響服務(wù)可以在超時(shí)后快速失敗，不會(huì)影響整個(gè)調(diào)用鏈路。

在基礎(chǔ)設(shè)施層面，我們實(shí)施了以下的方案：

統(tǒng)一基礎(chǔ)設(shè)施，擁抱容器標(biāo)準(zhǔn)，解決服務(wù)器碎片化和服務(wù)之間的隔離問(wèn)題；

統(tǒng)一編排和彈性伸縮平臺(tái)，2015 年擁抱 Kubernetes 標(biāo)準(zhǔn)，解決了部署困難，環(huán)境不一致的問(wèn)題；

打造 CI/CD 服務(wù)，抽象出產(chǎn)品、環(huán)境等多級(jí)概念，實(shí)現(xiàn)從代碼到測(cè)試到上線的自動(dòng)部署。

隨著我們支撐的內(nèi)部業(yè)務(wù)越來(lái)越多，又遇到了以下問(wèn)題：

微服務(wù)框架選型不一，技術(shù)無(wú)法積累，面向業(yè)務(wù)定制化嚴(yán)重，上手成本高；

傳統(tǒng)依賴于應(yīng)用運(yùn)維的排障復(fù)雜度高，傳統(tǒng)監(jiān)控服務(wù)無(wú)法滿足需求；

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

API 版本管理混亂，無(wú)統(tǒng)一的監(jiān)控，治理，無(wú)開發(fā)標(biāo)準(zhǔn)；

分布式事務(wù)支持方式不一，和業(yè)務(wù)綁定嚴(yán)重。

為了解決這些問(wèn)題，我們實(shí)施了以下方案：

微服務(wù)框架與開源技術(shù)棧統(tǒng)一，將服務(wù)治理邏輯抽離、以無(wú)侵入方式實(shí)現(xiàn)、支持 Spring Cloud、Dubbo 等開源技術(shù)棧；

全鏈路跟蹤服務(wù)與日志服務(wù)依據(jù) ID 進(jìn)行聯(lián)系，以發(fā)現(xiàn)故障點(diǎn)上下文；

在 Agent 引入故障注入服務(wù)，可統(tǒng)一進(jìn)行故障演練；

服務(wù)通過(guò) API 網(wǎng)關(guān)暴露，引入 API 管理、測(cè)試平臺(tái)，自動(dòng) Client SDK 生成；

實(shí)現(xiàn) TCC 中間件、事務(wù)消息隊(duì)列等標(biāo)準(zhǔn)中間件。

3、InfoQ：你如何理解微服務(wù)？微服務(wù)在當(dāng)前技術(shù)形勢(shì)下處于一個(gè)什么樣的位置？
劉超： 微服務(wù)是一個(gè)非常復(fù)雜的問(wèn)題，業(yè)內(nèi)對(duì)微服務(wù)也存在一些誤解：

微服務(wù)主要的工作是服務(wù)拆分，主要考慮將服務(wù)拆分成什么粒度以及如何進(jìn)行拆分；

微服務(wù)是一個(gè)運(yùn)動(dòng)式的過(guò)程，把大家關(guān)起門來(lái)封閉開發(fā)一個(gè)月，就能把架構(gòu)修改好了，以后就萬(wàn)事大吉了；

微服務(wù)僅僅是一個(gè)技術(shù)問(wèn)題，交給開發(fā)團(tuán)隊(duì)或者運(yùn)維團(tuán)隊(duì)去搞就可以了。

微服務(wù)絕不僅僅是服務(wù)拆分，就像上圖所示，拆分只是實(shí)施微服務(wù)十二個(gè)要點(diǎn)之一，因?yàn)椴鸱至朔?wù)之后，會(huì)面臨上面我們遇到的所有問(wèn)題，沒(méi)有相應(yīng)的工具和平臺(tái)，拆分的越細(xì)，越是一場(chǎng)災(zāi)難。

微服務(wù)絕不是一個(gè)運(yùn)動(dòng)式的過(guò)程，而是應(yīng)該漸進(jìn)的過(guò)程，一旦實(shí)施了微服務(wù)，就處于業(yè)務(wù)系統(tǒng)不斷更新和迭代的狀態(tài)中，也處于不斷的拆分和組合中。所以不建議一開始就拆的特別細(xì)，不建議一勞永逸，而是隨著慢慢的拆成幾個(gè)，十幾個(gè)，幾十個(gè)，上百個(gè)的過(guò)程，將十二個(gè)要點(diǎn)所需要的工具、團(tuán)隊(duì)、員工能力慢慢匹配到微服務(wù)狀態(tài)。

微服務(wù)絕不僅僅是個(gè)技術(shù)問(wèn)題，牽扯到 IT 架構(gòu)、應(yīng)用架構(gòu)、組織架構(gòu)多個(gè)方面。微服務(wù)必定帶來(lái)開發(fā)、上線、運(yùn)維的復(fù)雜度的提高，如果說(shuō)單體應(yīng)用復(fù)雜度為 10，實(shí)施了微服務(wù)后的復(fù)雜度將是 100，配備了相應(yīng)的工具和平臺(tái)后，可以將復(fù)雜度降低到 50，但仍然比單體復(fù)雜的多。

所以實(shí)施微服務(wù)是有成本的，只有在業(yè)務(wù)層面遇到不微不行的痛點(diǎn)，例如痛到影響收入，痛到被競(jìng)爭(zhēng)對(duì)手甩在后面，所以微服務(wù)往往是業(yè)務(wù)驅(qū)動(dòng)或者高管驅(qū)動(dòng)的，而實(shí)施微服務(wù)的結(jié)果又必然會(huì)影響到組織架構(gòu)的變化，例如運(yùn)維和開發(fā)的界限模糊——DevOps，專門中間件和架構(gòu)師團(tuán)隊(duì)的成立，數(shù)據(jù)中臺(tái)和業(yè)務(wù)中臺(tái)組的建立，小團(tuán)隊(duì)自主決策等。

目前，大多數(shù)企業(yè)都意識(shí)到了微服務(wù)的重要性，但是各處的階段不同，我把微服務(wù)分成三個(gè)階段：

微服務(wù) 1.0，僅使用注冊(cè)發(fā)現(xiàn)，基于 SpringCloud 或者 Dubbo 進(jìn)行開發(fā)，目前意圖實(shí)施微服務(wù)的傳統(tǒng)企業(yè)大部分處于這個(gè)階段，或者正從單體應(yīng)用，向這個(gè)階段過(guò)渡，處于 0.5 的階段；

微服務(wù) 2.0，使用了熔斷，限流，降級(jí)等服務(wù)治理策略，并配備完整微服務(wù)工具和平臺(tái)，目前大部分互聯(lián)網(wǎng)企業(yè)處于這個(gè)階段。傳統(tǒng)企業(yè)中的領(lǐng)頭羊，在做互聯(lián)網(wǎng)轉(zhuǎn)型的過(guò)程中，正在向這個(gè)階段過(guò)渡，處于 1.5 的階段；

微服務(wù) 3.0，Service Mesh 將服務(wù)治理作為通用組件，下沉到平臺(tái)層實(shí)現(xiàn)，使得應(yīng)用層僅僅關(guān)注業(yè)務(wù)邏輯，平臺(tái)層可以根據(jù)業(yè)務(wù)監(jiān)控自動(dòng)調(diào)度和參數(shù)調(diào)整，實(shí)現(xiàn) AIOps 和智能調(diào)度。目前一線互聯(lián)網(wǎng)公司在進(jìn)行這方面的嘗試。

4、InfoQ：你怎么看微服務(wù)未來(lái)的發(fā)展趨勢(shì)？
劉超： 前面大概談了一下微服務(wù) 3.0，這里詳細(xì)說(shuō)一下我眼中的微服務(wù)的發(fā)展趨勢(shì)。
第一個(gè)就是 Service Mesh，他的主要作用就是將服務(wù)治理下沉到平臺(tái)層，進(jìn)行統(tǒng)一的治理。
為什么會(huì)這樣呢？因?yàn)闊o(wú)論是在我們內(nèi)部，還是在外部企業(yè)，都能看的這樣的趨勢(shì)。
最初只有物理機(jī)，虛擬機(jī)是放在云平臺(tái)上，由運(yùn)維組統(tǒng)一管理的。

后來(lái)因?yàn)槟芰?fù)用和開發(fā)速度的需要，數(shù)據(jù)庫(kù)、中間件成為了 PaaS 平臺(tái)用于部署通用的組件，持續(xù)發(fā)布也成了 PaaS 平臺(tái)，用于部署客戶的業(yè)務(wù)，所以這兩部分也平臺(tái)化了。

隨著越來(lái)越多的業(yè)務(wù)需要進(jìn)行服務(wù)治理，微服務(wù)框架，APM，也成為了平臺(tái)的一部分。

但是微服務(wù)框架的統(tǒng)一，涉及多語(yǔ)言的問(wèn)題，也涉及和應(yīng)用層綁定的問(wèn)題，無(wú)論是 Spring Cloud 還是 Dubbo，都很難完全平臺(tái)化，所以需要 Service Mesh，通過(guò) sidecar 的方式，將控制面和數(shù)據(jù)面隔離，通過(guò)非侵入的模式進(jìn)行流量攔截，實(shí)現(xiàn)真正的治理平臺(tái)化。

第二個(gè)就是 AIOps 和智能調(diào)度，就是通過(guò)對(duì)于海量數(shù)據(jù)中心收集的監(jiān)控?cái)?shù)據(jù)和業(yè)務(wù)數(shù)據(jù)，實(shí)現(xiàn)業(yè)務(wù)的自動(dòng)調(diào)度和參數(shù)調(diào)整。

這個(gè)看起來(lái)很遙遠(yuǎn)，其實(shí)不然，如果大家感興趣的話，可以在網(wǎng)上搜索一下，Google 在 2011 年就公布了自己數(shù)據(jù)中心收集的監(jiān)控?cái)?shù)據(jù)（https://github.com/google/clu...），并在 2014 年發(fā)表論文《Machine Learning Applications for Data Center Optimization》，使用 AI 技術(shù)優(yōu)化數(shù)據(jù)中心的效率。

而國(guó)內(nèi)一線互聯(lián)網(wǎng)公司也在 2018 年公布 4000 臺(tái)服務(wù)器真實(shí)數(shù)據(jù)集，也在干和 Google 類似的事情。

我們觀察到，當(dāng)數(shù)據(jù)中心的機(jī)器規(guī)模突破十萬(wàn)臺(tái)的時(shí)候，效率的提高就變成了一件能夠節(jié)省大量成本的事情，所以開始引起重視。而能做到這件事情，往往依靠的就是數(shù)據(jù)驅(qū)動(dòng)的智能調(diào)度。

為了支撐強(qiáng)大的調(diào)度功能，Google 開發(fā)了 Borg，Twitter 壯大了 Mesos，并通過(guò)將這些調(diào)度平臺(tái)和機(jī)器學(xué)習(xí)相結(jié)合，實(shí)現(xiàn)自動(dòng)化的智能調(diào)度，國(guó)內(nèi)一線互聯(lián)網(wǎng)公司也在進(jìn)行著積極的嘗試。

隨著微服務(wù)化和容器化，服務(wù)的數(shù)量會(huì)十分的龐大，從而運(yùn)維難度大幅度提高，原來(lái)僅僅會(huì)運(yùn)維物理機(jī)和虛擬化的技術(shù)人員是不夠的，而運(yùn)維 Kubernetes 和 Docker 的人會(huì)比較貴，使得人力成本大幅度提高。

很多組織從物理機(jī)時(shí)代，到虛擬化時(shí)代，到云時(shí)代，再到容器時(shí)代，運(yùn)維團(tuán)隊(duì)的規(guī)模是越來(lái)越大的，每個(gè)人的薪資也越來(lái)越高。

所以將來(lái)只運(yùn)維少量節(jié)點(diǎn)的私有化容器平臺(tái)，從成本上來(lái)講是不劃算的，當(dāng)出現(xiàn)有公信力的公有云平臺(tái)，則使用公有云成為節(jié)約成本的理智選擇。

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

5、InfoQ：QCon 廣州的「微服務(wù)實(shí)戰(zhàn)」專題下設(shè)置了 4 個(gè)演講，作為出品人，你如何策劃這 4 個(gè)演講，想給參會(huì)者呈現(xiàn)微服務(wù)的哪些方面？劉超： 基于我們自己的微服務(wù)實(shí)踐，和對(duì)于微服務(wù)發(fā)展階段的理解，作為「微服務(wù)實(shí)戰(zhàn)」專題的出品人，我計(jì)劃全方位展示微服務(wù)在主流公司的主流技術(shù)方向的實(shí)踐和未來(lái)方向。

第一個(gè)方面就是 基于 Dubbo 的大規(guī)模微服務(wù)實(shí)踐的場(chǎng)景，Dubbo 是應(yīng)用范圍非常廣的微服務(wù)框架，很多企業(yè)都是基于 Dubbo 做的，Dubbo 的實(shí)踐是微服務(wù)實(shí)施過(guò)程中繞不過(guò)去的一環(huán)，這個(gè)主題能夠解決很多技術(shù)人員實(shí)施海量 Dubbo 服務(wù)的時(shí)候遇到的問(wèn)題。

第二個(gè)方面就是 基于 Spring Cloud 的大規(guī)模微服務(wù)實(shí)戰(zhàn)的場(chǎng)景，Spring Cloud 是近年來(lái)新興的微服務(wù)框架，很多新實(shí)施微服務(wù)的，會(huì)選擇基于 Spring Cloud，但是 Spring Cloud 雖然組件豐富，可選項(xiàng)多，但是也很復(fù)雜，學(xué)習(xí)曲線高，如何再海量場(chǎng)景下進(jìn)行改進(jìn)和適配，是經(jīng)常遇到的問(wèn)題，這個(gè)主題能夠給予技術(shù)人員實(shí)施 Spring Cloud 微服務(wù)的時(shí)候以借鑒意義。

第三個(gè)方面就是 Service Mesh 在高并發(fā)場(chǎng)景下的實(shí)踐場(chǎng)景，前面說(shuō)了 Service Mesh 是一個(gè)趨勢(shì)，一線互聯(lián)網(wǎng)公司都在嘗試，但是這個(gè)技術(shù)太新了，很多坑還在踩，這個(gè)主題能夠帶給技術(shù)人員最前沿微服務(wù)技術(shù)的落地實(shí)踐，給想試試 Service Mesh 的技術(shù)人員以借鑒意義。

第四個(gè)方面就是 微服務(wù)框架各個(gè)方向的發(fā)展與未來(lái)趨勢(shì)，微服務(wù)涉及范圍廣，技術(shù)選型難，很多沒(méi)有實(shí)施微服務(wù)的技術(shù)人員面臨如此多的技術(shù)名詞，無(wú)所適從，選穩(wěn)定的，會(huì)不會(huì)過(guò)時(shí)被淘汰，選先進(jìn)的，會(huì)不會(huì)冒進(jìn)出線上事故，選錯(cuò)了技術(shù)方向，萬(wàn)一開源的不維護(hù)了就麻煩大了，這個(gè)主題會(huì)講解微服務(wù)發(fā)展的技術(shù)趨勢(shì)和各個(gè)方向的優(yōu)劣對(duì)比，給選型困難的技術(shù)人員以參考。

點(diǎn)擊這里了解網(wǎng)易云輕舟微服務(wù)平臺(tái)，獲取解決方案。

文章來(lái)源： 網(wǎng)易云社區(qū)