作者：裴斐，網易杭州研究院雲計算技術部工程師

在我們發布《網易雲輕舟微服務框架：服務治理無侵入的設計》、《網易雲輕舟微服務框架：不僅僅是整合Spring Cloud》之後，有朋友就「企業如何選擇合適的微服務開發框架」的問題諮詢了我們，希望有更全面的答案，本文就結合網易雲輕舟微服務框架開發經驗分享我們的微服務框架設計理念與選型思考，供大家參考。

的確，微服務架構技術經過幾年的發展，已經是百花齊放，各領風騷。SpringCloud、Dubbo、自研RPC、Service Mesh…… 大家對微服務架構下的技術、架構、功能模塊似乎總有說不盡的話題。大部分團隊在自身業務服務規模大到一定程度時開始引入微服務架構，而在技術選型上則大有百家爭鳴的感覺：

• Spring體系下傾向以Spring Cloud作為框架主體；
• Dubbo是國內技術團隊選型RPC通用框架的主要選擇；
• 對於技術實力較強技術積澱較多的公司或團隊，自研RPC+治理能力帶來的可定製性也成為主流選擇；
• Service Mesh（服務網格）概念在2017年的崛起引發了「下一代微服務框架」的關注熱潮。

我們在開發輕舟微服務框架之前也有些疑惑：究竟怎樣的選型和架構最合適？如何避免重複造輪子？

設計理念

根據網易雲服務網易集團內部業務和外部客戶的經驗，我們首先梳理了微服務框架的設計理念。我們認為，「最好」的選型與架構需求是這樣的：

• 對業務無侵入：業務開發者應該無需關注和學習治理相關的技術，治理邏輯不應侵入業務代碼。
• 功能完備：提供完備的治理功能全家桶，包括服務註冊/發現，降級，限流，容錯，負載均衡，分流等。
• 快速接入：業務系統可以快速接入框架和平台，同時通過平台實時配置治理策略。
• 安全穩定：提供統一的認證、鑒權機制，同時保障業務系統穩定運行。
• 跨平台性：如果能跨不同語言和平台，那自然是極好的。
• 隔離性：多租戶、多項目隔離，具備大平台多業務隔離能力。
• 微服務生態親和性：符合微服務技術和架構趨勢，同時具備長遠的擴展性。

開發願景

輕舟微服務框架的最大願景，就是可以讓業務系統開發者無需關注和學習治理相關技術、無需修改業務系統代碼就可以快速引入服務治理能力。

以SpringCloud體系為例。傳統開發模式下，如果業務開發需要引入微服務架構，就需要學習SpringCloud全家桶內的相關內容：

需要服務註冊/發現？請學習Eureka；

需要熔斷器、線程隔離？請學習Hystrix；

需要負載均衡？請學習Ribbon；

需要API網關？請學習Zuul；

需要配置中心？請學習Config、Bus；

……

如果使用傳統的方式，可能一家企業的若干團隊的眾多相關開發人員都需要學習和熟悉Spring Cloud，至少是學習其中的部分組件，而且原生Spring Cloud組件在某些場景下缺乏靈活性，甚至存在一些BUG。除了掌握組件用法，甚至需要掌握核心源碼以避免一些被動引入的坑。

所以，前文提及過的避免重複造輪子何其重要！

技術選型

從上面分析可以看出，比起各家各自為戰重複造輪子，我們更希望的是一個更通用、侵入性更低、能力更全面的微服務框架。自研RPC雖然能更貼近一些公司或團隊的需求，但一般自研RPC往往帶有公司或團隊長期的技術背景，比較難作為通用技術選型，所以率先pass。

Spring Cloud作為開源屆大佬Spring旗下微服務框架的代表作，天生強大的同時還天生要強的引入了Netflix較完備的微服務治理工具集，諸如Eureka、Ribbon、Hystrix、Config、Archaius、Zuul。依託較早脫穎而出的SpringBoot，Spring在微服務圈依舊擁有眾多擁簇。

Dubbo作為一款標杆型的RPC框架，依託大廠場景成為國內公司RPC框架的重要選擇。從小到大到開放到停止維護再到恢復開放更新，Dubbo發展歷經風雨又讓開發者日久彌新。前期重RPC輕治理喪失了一些追求完整解決方案的粉絲，後來重新煥發生機引入了較多治理特性，也可以作為通用框架備選。

Service Mesh自問世起就備受關注，它提出的無侵入、去中心、高可運維型和擴展性架構十分迷人。Istio作為宇宙級大廠Google、IBM等的聯合作品，2017年的橫空出世讓人感覺到微服務全新時代到來的氣息。其依託於Kubernetes平台，雖然前期版本問題不少，其架構和技術的先進性還是微服務架構追隨者看到了來自遠方的曙光。

關於這幾個框架橫向對比和詳細介紹的文章較多，本文不做詳述。從通用微服務框架角度，滿足架構、功能、擴展性是技術選型的核心要素。網易雲輕舟微服務團隊在開始進行微服務基礎框架選型時，對各個框架發展狀況的最終思考如下：

• Spring Cloud在Java體系微服務成熟度較高，功能全家桶能力較全，加之Spring的天生優勢，成為我們微服務框架落地的首選；
• Dubbo初期治理能力的欠缺；
• Service Mesh理念超前，但由於框架處於較早期階段，尚存在一定問題（平台綁定Kubernetes、性能問題等），不太容易在傳統業務直接落地。

當然，Service Mesh在架構和技術上的超前性同樣讓我們持續關注，落地的架構和技術選型也參考其理念，並決定在後續版本逐步打通。

架構

網易雲輕舟微服務框架簡稱NSF，NSF 1.0版本的架構，以常見的微服務集群為主要場景，主體包括代理（nsf-agent）、服務控制中心（nsf-server）、註冊中心（nsf-registry），以及認證鑒權中心（Auth）、通用配置中心（Config）、監控中心（Monitor）、知識庫（knowledge）等通用組件。

NSF功能主體以nsf-agent為載體，其以代碼無侵入的java agent方式隨應用進程啟動，配合簡單的配置文件完成服務的註冊、發現，並對治理的目標進行方法級與服務級增強，使之具備熔斷、線程隔離、降級、限流、容錯等治理能力，以及負載均衡、路由、參數分流等流量控制能力。

nsf-server、nsf-registry為支撐nsf-agent能力提供了服務元信息管理、策略管理與分發、註冊信息同步與實時下發等平台級能力。

Auth、Config、Monitor、Knowledge則作為微服務平台通用組件提供諸如服務認證與鑒權、服務配置、服務監控、服務基礎信息能力。

這種架構最大的特點整體抽象agent，無需侵入業務服務代碼，同時提供平台能力統一管理微服務信息、治理策略、配置等，降低微服務集群運維成本。而平台本身也是微服務架構，也通過註冊中心、治理組件等保證自身微服務的穩定運行。

下篇我們將介紹NSF的這些核心組件，敬請期待……

相關文章：

• 網易雲輕舟微服務框架：服務治理無侵入的設計
• 網易雲輕舟微服務框架：不僅僅是整合Spring Cloud
• 網易雲輕舟微服務監控：基於Prometheus的實踐與踩過的坑
• 又讓馬兒跑又不讓吃草，微服務化如何完成低成本改造？
• 恕我直言，你可能誤解了微服務
• 支撐德邦快遞日進億元的微服務平台是如何設計的
• 網易云：2019年微服務5大趨勢，你pick哪個？

推薦閱讀：

相关文章