隨著雲計算和容器技術的普及，網際網路it基礎設施已經發生了很大的變革，也推動了微服務技術的大量採用和落地。現在的技術人，不談微服務已經要跟不上形勢了。但是你真的對微服務有正確的理解嗎？要向微服務轉型，有哪些問題和挑戰擺在面前？如何撥開現代各種技術棧的迷霧看清微服務的發展趨勢，選擇最適合團隊的技術方向？本次infoq記者採訪了網易杭州研究院雲計算技術部的首席架構師劉超，為大家分享他對這些問題的看法。劉超也是今年5月份qcon全球軟體開發大會廣州站「微服務實戰」專題的出品人，將為大家策劃幾場微服務相關的內容豐富的分享。
infoq：劉超老師，請先介紹一下自己吧。
infoq：網易雲在微服務方面的探索有哪些？落地過程中有哪些難點？
劉超：網易雲的技術團隊在部落格時代就開始探索網際網路架構，是在支撐部落格使用者量、訪問量就爆發式增長的過程中，構建了聚焦微服務的網易雲輕舟平台，並支撐內部考拉、雲**、雲課堂等核心業務。
在實施微服務的過程中，難點層出不窮，可謂見山開路，遇水搭橋。
實施服務化架構之後，首先實現的功能是進行統一的註冊發現和rpc的透明封裝，但是服務拆分多了，在應用層面就遇到以下問題：
在基礎設施層面，還有另外的問題：
為了解決這些問題，我們在應用層面實施了以下方案：
在基礎設施層面，我們實施了以下的方案：
隨著我們支撐的內部業務越來越多，就進一步遇到了以下問題：
為了解決這些問題，我們實施了以下方案：
infoq：你如何理解微服務？微服務在當前技術形勢下處於乙個什麼樣的位置？
劉超：微服務是乙個非常複雜的問題，在業內會有一些誤解：
微服務主要的工作是服務拆分，主要考慮將服務拆分成什麼粒度以及如何進行拆分；
微服務是乙個運動式的過程，把大家關起門來封閉開發乙個月，就能把架構修改好了，以後就萬事大吉了；
微服務僅僅是乙個技術問題，交給開發團隊或者運維團隊去搞就可以了。
微服務絕不僅僅是服務拆分，就像上圖所示，拆分只是實施微服務十二個要點之一，因為拆分了服務之後，會面臨上面我們遇到的所有問題，沒有相應的工具和平台，拆分的越細，越是一場災難。
微服務絕不是乙個運動式的過程，而是應該漸進的過程，一旦實施了微服務，就處於業務系統不斷更新和迭代的狀態中，也處於不斷的拆分和組合中。所以不建議一開始就拆的特別細，不建議一勞永逸，而是隨著慢慢的拆成幾個，十幾個，幾十個，上百個的過程，將十二個要點所需要的工具、團隊、員工能力慢慢匹配到微服務狀態。
微服務絕不僅僅是個技術問題，牽扯到it架構、應用架構、組織架構多個方面。微服務必定帶來開發、上線、運維的複雜度的提高，如果說單體應用複雜度為10，實施了微服務後的複雜度將是100，配備了相應的工具和平台後，可以將複雜度降低到50，但仍然比單體複雜的多。
所以實施微服務是有成本的，只有在業務層面遇到不微不行的痛點，例如痛到影響收入，痛到被競爭對手甩在後面，所以微服務往往是業務驅動或者高管驅動的，而實施微服務的結果又必然會影響到組織架構的變化，例如運維和開發的界限模糊——devops，專門中介軟體和架構師團隊的成立，資料中颱和業務中颱組的建立，小團隊自主決策等。
目前，大多數企業都意識到了微服務的重要性，但是各處的階段不同，我把微服務分成三個階段：
infoq：你怎麼看微服務未來的發展趨勢？
劉超：前面大概談了一下微服務3.0，這裡詳細說一下我眼中的微服務的發展趨勢。
第乙個就是service mesh，他的主要作用就是將服務治理下沉到平台層，進行統一的治理。
為什麼會這樣呢？因為無論是在我們內部，還是在外部企業，都能看的這樣的趨勢。
最初只有物理機，虛擬機器是放在雲平台上，由運維組統一管理的。
後來因為能力復用和開發速度的需要，資料庫、中介軟體成為了paas平台用於部署通用的元件，持續發布也成了paas平台，用於部署客戶的業務，所以這兩部分也平台化了。
隨著越來越多的業務需要進行服務治理，微服務框架，apm，也成為了平台的一部分。
但是微服務框架的統一，涉及多語言的問題，也涉及和應用層繫結的問題，無論是spring cloud還是dubbo，都很難完全平台化，所以需要service mesh，通過sidecar的方式，將控制面和資料面隔離，通過非侵入的模式進行流量攔截，實現真正的治理平台化。
第二個就是aiops和智慧型排程，就是通過對於海量資料中心收集的監控資料和業務資料，實現業務的自動排程和引數調整。
而國內一線網際網路公司也在2023年公布4000臺伺服器真實資料集，也在幹和google類似的事情。
我們觀察到，當資料中心的機器規模突破十萬台的時候，效率的提高就變成了一件能夠節省大量成本的事情，所以開始引起重視。而能做到這件事情，往往依靠的就是資料驅動的智慧型排程。
為了支撐強大的排程功能，google開發了borg，twitter壯大了mesos，並通過將這些排程平台和機器學習相結合，實現自動化的智慧型排程，國內一線網際網路公司也在進行著積極的嘗試。
隨著微服務化和容器化，服務的數量會十分的龐大，從而運維難度大幅度提高，原來僅僅會運維物理機和虛擬化的技術人員是不夠的，而運維kubernetes和docker的人會比較貴，使得人力成本大幅度提高。
很多組織從物理機時代，到虛擬化時代，到雲時代，再到容器時代，運維團隊的規模是越來越大的，每個人的薪資也越來越高。
所以將來只運維少量節點的私有化容器平台，勢必從成本上來講是不划算的，當出現有公信力的公有雲平台，則勢必使用公有雲成為節約成本的理智選擇。
例如亞馬遜、谷歌等公有雲平台就沒有問題，谷歌裡面的運維工程師相當貴，他們掌握最先進的技術是沒有任何問題的，但是他們會通過各種自動化，甚至智慧型化的技術，管理全球的幾百萬臺機器，這樣成本攤下來就不是很高了。如果你只是運維乙個幾十個節點，最多幾百個節點的容器平台，同樣需要招一些這麼貴的人，一般的企業肯定受不了。所以將來要麼是大規模公有雲平台，要麼是土豪如電信金融行業的自建雲平台，都會出現超大規模的場景，基於aiops和智慧型排程節約成本，就是勢在必然的了。
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的技術人員以借鑑意義。
第四個方面就是微服務框架各個方向的發展與未來趨勢，微服務涉及範圍廣，技術選型難，很多沒有實施微服務的技術人員面臨如此多的技術名詞，無所適從，選穩定的，會不會過時被淘汰，選先進的，會不會冒進出線上事故，選錯了技術方向，萬一開源的不維護了就麻煩大了，這個主題會講解微服務發展的技術趨勢和各個方向的優劣對比，給選型困難的技術人員以參考。
恕我直言，你可能誤解了微服務
隨著雲計算和容器技術的普及，網際網路it基礎設施已經發生了很大的變革，也推動了微服務技術的大量採用和落地。現在的技術人，不談微服務已經要跟不上形勢了。但是你真的對微服務有正確的理解嗎？要向微服務轉型，有哪些問題和挑戰擺在面前？如何撥開現代各種技術棧的迷霧看清微服務的發展趨勢，選擇最適合團隊的技術方向...
恕我直言，你可能誤解了微服務
劉超 劉超 大量請求堆積 故障恢復慢 即乙個服務慢，卡住了，整個呼叫鏈路出現大量超時，要長時間等待慢的服務恢復到正常狀態 一台伺服器上多個程序互相影響 qos 難以保障 採用虛擬機器或者物理機的部署，往往會多個程序放在一台伺服器上，高峰期影響嚴重 測試環境數量大增，環境管理 部署更新困難 每個團隊都...
恕我直言！你不是真的懂js中的作用域！
如果對於作用域，詞法作用域你還不是很清楚，那麼你可就要好好讀讀這篇文章了，它可是理解閉包的關鍵！為了便於理解，筆者使用對話的方式進行解釋 引擎 負責js程式的編譯以及執行過程 編譯器 負責語法分析以及 生成等髒活 作用域 負責收集並維護由所有宣告識別符號組成的一些列查詢，並實施一套非常嚴格的規則，確...