張小剛，網易雲基礎服務架構師，負責網易雲多Region、多AZ、VPC整體架構設計和推進工作，在負載均衡、分散式系統方面有豐富的經驗。在本文中，張小剛為我們解答了微服務對於網易業務發展的意義，以及團隊在微服務方面的實踐經驗與心得。本文由原載於公眾號技術瑣話，有改動。

Q：作為一家打造多款互聯網爆款的公司，網易技術架構演進和業務的關係如何？

張小剛: 我認為這兩者應該是一個相互促進，螺旋上升的過程。一方面，作為基礎部門，我們會通過技術預研的形式引入新技術，並形成解決方案提供給產品團隊。推動產品進行一些技術改造。另一方面，業務部門用戶的爆發性增長，也會給基礎服務提出更高的要求，倒逼著我們進行技術升級。

一般來說，這兩者一般不會在一個平衡狀態，當業務相對穩定時，我們這邊會更多時間，幫助業務部門來提前進行技術規劃，和架構演進。而當某些業務爆炸性增長，碰到一些棘手問題時。技術這邊也會抽人力幫助業務部門制定解決方案，並將一些好的結果反向輸出到我們的解決方案中，在公司內整體推廣。

整體上看，我們技術部門和業務部門的合作是很順暢的。最近一次比較大的技術改造就是網易考拉，我們作為核心支撐部門幫助網易考拉平穩度過了雙十一大促。

Q：微服務架構經過幾年的發展，可以說是百花齊放，各領風騷。網易是從什麼時候開始著手於微服務設計的呢？此外，設計原則把控能為我們舉例說說嗎？

張小剛: 網易的服務化開始還是比較早的，從最早網易博客的服務化拆分開始，大概有近10年的歷史了。這實際上還是在我進入網易之前，從前輩的大佬那裡聽到了不少輝（xue）煌（lei）史，這塊也是我這次分享的一個重點。關於微服務的一些基本評估方式（低內聚高耦合之類的）就不再提了。我這裡直接提幾個我這邊常用的，看起來非常簡單，但卻十分有效的原則：

1）評估投入產出比（ROI）:這個其實是一個非常基礎，但卻很容易被忽視的原則。作為商業公司，任何投入都需要有回報（回報本身可以是短期的，或者是非常長期的技術積累）我們做微服務設計也是一樣，需要思考投入的成本是否可以得到足夠的回報。這一點說起來簡單，但卻是技術人員最容易犯的問題。特別是看到一些業界追捧的技術熱點，或者醉心於精確的設計時，就很容易忽略了成本的投入。另外，當進展不是特別順利時，可以停下來想想是否還需要繼續投入。一些時候，壯士斷腕比深陷泥潭會更好。2）沒想清楚就別亂動：對於一些設計方案，如果無法判斷是否要執行，較好的做法是先擱置起來，去做更明確的事情。對於非常重要的事情，在推進中就會將問題暴露得更加明晰，而對於一些非核心內容，在後續檢驗中可能就會被證明是沒有必要的。一般來說，不動的話不會更差，但亂動往往會更糟。如果你連設計方案都沒想清楚，那幾乎是不可能順利實施的。這個原則說起來很簡單，但遺憾的是，在面臨實際困難時往往會做出錯誤的選擇。這些實際困難可能是進度壓力，對新技術的憧憬，或者對業務的熟悉了解程度。3）風險把控：我們做任何技術升級和改造，實際上都會有潛在的風險。而很多同學往往只看到光明的那一面，而忽略了陽光下的陰影。我們對於微服務的推進有很謹慎的流程。一般是新業務和較為獨立的功能先採用，老業務根據實際情況，一般會先從邊緣業務推進，根據實際情況逐步推進。

Q：作為架構師，相信不能只看到微服務外部的世界,而輕忽或完全忽略了微服務內部的世界。所以，對於微服務中服務的粒度問題您是如何考量的？

張小剛: 我覺得微服務中的粒度本身和代碼量多少並沒有直接關係（至少不是強相關）。最關鍵的，還是粒度把控，是否符合業務特點，是否滿足實際業務和場景需求，即對業務本身是否有幫助。如果僅僅是為了拆分而拆分，反而會徒增業務的複雜性。

關於這個問題，執行時還是有一些簡單的標準可以參考的：1）設計時預留拆分的能力。項目開始時可以不拆，但是要保留能力。2）根據需要推進。在有明確需要（如業務分離，單獨熱點，獨立升級等）時再進行業務拆分。切忌為了拆分而拆分。3）明確服務邊界。當弄清楚服務邊界的時候，往往服務拆分就已經完成了。反過來說，如果你連服務邊界都劃分不清，那最好還是不要亂動。4）微服務劃分需要符合實際組織架構，規避跨團隊服務。這個如果有維護跨團隊服務經驗的人，就會知道其中的痛了。

Q：微服務是一個系統工程，主要包含哪些維度？

張小剛:基於微服務架構來實施項目，由於服務實例的大幅度增加，如果還採用原有的支撐體系，會造成開發，測試，運維成本的大幅上升，在一些場景下甚至是無法進行（比如全鏈路排障）。

因此，面向微服務技術，就需要新的工具和基礎設施來進行支持，而這些設施之間也是會相互關聯的。以網易雲的輕舟微服務平台為例，大概可以分為以下六個維度：

1）微服務框架：這個是實現微服務的基礎設施，比如服務註冊/發現，服務拓撲，配置管理等。在輕舟微服務平台中，我們自研了一套微服務框架NSF，完全兼容Spring Cloud和Dubbo，不但提供了服務註冊/發現，列表，路由等基礎功能，還提供了服務容錯，服務降級，限流等高級特性。

2）RPC通道/API 網關：做了細粒度的拆分後，作為服務邊界的API的統一治理就特別重要。API網關實現服務鑒權，流控/熔斷，發布管理等功能。在輕舟微服務平台中，我們是使用自研的API網關來實現的。除了API網關的基本特性（鑒權，流控）之外，還和整個服務體系打通，提供了審計，多維度故障隔離，流量控制等能力。3）底層設施：底層設施的支持也必不可少，這方面雲計算有天生的優勢，特別是容器服務。網易雲輕舟微服務基於Kubernetes實現，支持容器編排，彈性伸縮，鏡像管理等。4）面向微服務的運維工具：微服務架構帶來巨大的變化，原有工具很難滿足要求，需要面向微服務設計，更為智能的運維工具。輕舟微服務直接提供了統一的控制台，所有功能都可以直接在界面操作。並且集成了自研的全鏈路監控工具，可以快速定位問題。這邊現在重點在推進智能運維，包括異常智能檢測，關聯報警分析，故障根因分析等。5）DevOps：這塊主要包括從開發到構建的流程管理，提供代碼倉庫，構建發布管理，pipeline管理等。輕舟微服務平台整合Kubernetes，支持完整的DevOps流水線，可以直接構建完整的CI/CD服務。 6）自動化測試：包括故障演練，性能壓測，API測試，異常定位/回滾等。輕舟微服務集成了網易自研的自動化測試平台，對應平台在網易內部經過了長期的應用，並廣泛應用在網易內部重大產品的測試中。

Q：網易在在引入微服務的過程中，有沒有發生過一些有意思的故事？

張小剛: 網易引入微服務的過程，就是一個不斷踩坑->填坑螺旋上升的過程。我們也正是因為碰到並解決了那麼多的問題，才最終形成一個較為完整的微服務技術棧。這裡有一個比較有趣的例子：

當微服務概念剛剛興起的時候，我們的一個技術團隊決定開始實施微服務。他們當時維護的是一個單體架構，做了不錯的模塊劃分，但是並沒有實現服務化。他們微服務的第一步就是服務拆分，而且拆的很細。細到什麼程度呢？最終從一個由幾個模塊構成的單體服務，拆到了四五十個服務的樣子。

其實他們的設計能力和拆分並沒有太大問題，粒度模塊劃分，邊界定的也算清楚。但是，在拆之後還是面臨了很大的困難。最大的問題就是當時我們的運維部署工具沒有跟上，還是沿用老的一套，需要人為控制服務發布。而他們的需求很多，一次大的功能需求往往需要十幾個，甚至幾十個服務共同升級，而服務相互之間還有一些前後升級的依賴關係。結果，最先做了微服務的團隊，變成每次升級最為困難，升級成本最高的團隊。經常是其他服務已經升級部署好了，他們還在那邊一個個的進行服務發布。現在還能記得他們苦逼的眼神。但這個團隊還是很有辦法的，乾脆直接引入了一套底層Kubernetes，完全接管了運維。後續又逐步引入各種微服務工具，才逐步體會到了微服務的優勢。實際上，這個團隊後來成為了輕舟微服務團隊的主力，而當時他們踩過的坑都變成了我們的寶貴經驗。

Q：目前貴公司微服務的實施狀況是怎樣的，下一步要解決哪些問題？

張小剛: 網易內部現在大部分互聯網服務都在不同程度的進行了微服務化實踐，並且已經在線上運行了。

我們雲計算部門也形成了一套完整的微服務解決方案，並封裝成為一個獨立的產品----輕舟微服務平台，現在已經成功對外輸出微服務能力，應用於金融、物流、製造等領域。

下一步的目標，主要還是完善功能，比如：ServiceMesh的支持，讓服務發現對應用完全透明；提供對分散式事務的支持，簡化分散式事務的開發和使用。其他還有很多具體的功能點，這裡就不細說了。

推薦閱讀：

相关文章