InfoQ 記者採訪了網易杭州研究院雲計算技術部的首席架構師劉超，跟大家分享了微服務實戰的挑戰和一些常見的微服務誤解，以及他對微服務發展趨勢的判斷。
隨著雲計算和容器技術的普及，互聯網 IT 基礎設施已經發生了很大的變革，也推動了微服務技術的大量採用和落地。現在的技術人，不談微服務已經要跟不上形勢了。但是你真的對微服務有正確的理解嗎？要向微服務轉型，有哪些問題和挑戰擺在面前？如何撥開現代各種技術棧的迷霧看清微服務的發展趨勢，選擇最適合團隊的技術方向？本次 InfoQ 記者採訪了網易杭州研究院雲計算技術部的首席架構師劉超，為大家分享他對這些問題的看法。劉超也是今年 5 月份 QCon 全球軟件開發大會廣州站「微服務實戰」專題的出品人，將為大家策劃幾場微服務相關的內容豐富的分享。
InfoQ：劉超老師，請先介紹一下自己吧。
劉超：我是網易雲的首席架構師，主要負責兩部分工作，對內支撐網易核心業務上雲，例如考拉，雲音樂，雲課堂，對外輸出網易的微服務經驗，幫助客戶搞定容器化與微服務化架構，已經在銀行、證券、物流、視頻監控、智能製造等多個行業落地。
InfoQ：網易雲在微服務方面的探索有哪些？落地過程中有哪些難點？
劉超：網易雲的技術團隊在博客時代就開始探索互聯網架構，是在支撐博客用戶量、訪問量就爆發式增長的過程中，構建了聚焦微服務的網易雲輕舟平臺，並支撐內部考拉、雲音樂、雲課堂等核心業務。
在實施微服務的過程中，難點層出不窮，可謂見山開路，遇水搭橋。
實施服務化架構之後，首先實現的功能是進行統一的註冊發現和 RPC 的透明封裝，但是服務拆分多了，在 應用層面就遇到以下問題：
- 服務雪崩：即一個服務掛了，整個調用鏈路上的所有的服務都會受到影響；
- 大量請求堆積、故障恢復慢：即一個服務慢，卡住了，整個調用鏈路出現大量超時，要長時間等待慢的服務恢復到正常狀態。
在 基礎設施層面 ，還有另外的問題：
- 服務器資源分配困難，服務器機型碎片化：服務多了，各個團隊都要申請服務器，規格不一，要求多樣，管理十分困難；
- 一臺服務器上多個進程互相影響、QoS 難以保障：採用虛擬機或者物理機的部署，往往會多個進程放在一臺服務器上，高峰期影響嚴重；
- 測試環境數量大增，環境管理、部署更新困難：每個團隊都有反覆部署測試環境，手動部署或者腳本部署過於複雜。
為了解決這些問題，我們在應用層面實施了以下方案：
- 通過熔斷機制，當一個服務掛了，被影響的服務能夠及時熔斷，使用 Fallback 數據保證流程在非關鍵服務不可用的情況下，仍然可以進行。
- 通過線程池和消息隊列機制實現異步化，允許服務快速失敗，當一個服務因為過慢而阻塞，被影響服務可以在超時後快速失敗，不會影響整個調用鏈路。
在基礎設施層面，我們實施了以下的方案：
- 統一基礎設施，擁抱容器標準，解決服務器碎片化和服務之間的隔離問題；
- 統一編排和彈性伸縮平臺，2015 年擁抱 Kubernetes 標準，解決了部署困難，環境不一致的問題；
- 打造 CI/CD 服務，抽象出產品、環境等多級概念，實現從代碼到測試到上線的自動部署。
隨著我們支撐的內部業務越來越多，就 進一步遇到了以下問題：
- 微服務框架選型不一，技術無法積累，面向業務定製化嚴重，上手成本高；
- 傳統依賴於應用運維的排障複雜度高，傳統監控服務無法滿足需求；
- 故障演練手段不一，硬編碼隨處可見；
- API 版本管理混亂，無統一的監控，治理，無開發標準；
- 分佈式事務支持方式不一，和業務綁定嚴重。
為了解決這些問題，我們實施了以下方案：
- 微服務框架與開源技術棧統一，將服務治理邏輯抽離、以無侵入方式實現、支持 Spring Cloud、Dubbo 等開源技術棧；
- 全鏈路跟蹤服務與日誌服務依據 ID 進行聯繫，以發現故障點上下文；
- 在 Agent 引入故障注入服務，可統一進行故障演練；
- 服務通過 API 網關暴露，引入 API 管理、測試平臺，自動 Client SDK 生成；
- 實現 TCC 中間件、事務消息隊列等標準中間件。
InfoQ：你如何理解微服務？微服務在當前技術形勢下處於一個什麼樣的位置？
劉超：微服務是一個非常複雜的問題，在業內會有一些 誤解：
- 微服務主要的工作是服務拆分，主要考慮將服務拆分成什麼粒度以及如何進行拆分；
- 微服務是一個運動式的過程，把大家關起門來封閉開發一個月，就能把架構修改好了，以後就萬事大吉了；
- 微服務僅僅是一個技術問題，交給開發團隊或者運維團隊去搞就可以了。
原文地址：https://www.sohu.com/a/294779362_683048
閱讀更多 架構師筆記 的文章
