前言

為了實現(xiàn)基于微服務開發(fā)的產(chǎn)品，或者說為了將單體應用重構(gòu)為微服務架構(gòu)時，將面臨著眾多技術(shù)框架的選擇。大公司往往會有專門的部門或團隊來負責自主研發(fā)自己的框架，以滿足產(chǎn)品的需要，但是對于一般的中小型企業(yè)，選擇合適的開源框架就顯得更接地氣了。

本章將簡單介紹微服務中，在技術(shù)選型時需要注意哪些原則，一些常用的開源技術(shù)框架，希望能夠為大家在進行技術(shù)選型、調(diào)研時提供一些思路方向。

筆者面試過很多程序員，一提及微服務，就會具體說道Spring Boot、Spring Cloud，然后就是“背誦”各種具體的用法和配置文件。并不是說這樣不對，但我們更希望知道的是這些技術(shù)框架的原理，為什么選擇它，它與其他類似框架又有何不同呢。

至于一個技術(shù)框架該怎么用，它適用于什么場景，筆者建議可以直接閱讀官方或?qū)膅ithub上的文檔，有需要時還可以閱讀下關(guān)注點的源碼，這樣對正確的理解它，是很有必要的，畢竟官方發(fā)布的東西是相對權(quán)威的，其他地方的資料或許存在片面性，對大家的使用、理解存在一定的誤導。(這只是筆者對大家在技術(shù)選型時，查閱資料的一些建議)

一、選型原則

在軟件開發(fā)領域，幾乎每天都有新的技術(shù)框架誕生、更新，一些新的概念更是層出不窮，技術(shù)選型時，難免讓人無從抉擇。對于技術(shù)選型，我個人有以下幾點建議：

1.有需求，再引入

在微服務架構(gòu)中，各類組件/技術(shù)很多很多，但并不意味著所有的都應該引入你的項目，倘若單純?yōu)榱烁采w全技術(shù)?；蚪M件而全部引入，這將是一種很不明智的選擇。后續(xù)將會成為你項目的累贅，讓你苦不堪言。

只要你記住這六個字：“有需求，再引入”，就OK了。伴隨著項目體系架構(gòu)的完善、功能的健全，當有某方面的需求時，在逐步考慮是否引入某些技術(shù)組件。

2.選擇最熟悉、使用最多的技術(shù)

“一個新項目里最好不要使用超過30%的新技術(shù)”，我覺得這句話是有一定道理的。對于你完全不知道、不了解的技術(shù)，你是無法預估、掌控在使用過程中會出現(xiàn)的任何風險，一旦出現(xiàn)問題，短時間內(nèi)解決不了，你將會變得很難堪。

在這里不是說拒絕使用、接觸新技術(shù)，新技術(shù)是值得大家去追捧、了解、學習，一些新技術(shù)在很大程度上能給我們帶來前所未有的利處，解決其他技術(shù)框架解決不了的問題。這里所說的“新技術(shù)”，是指沒有經(jīng)過充分的考察、技術(shù)驗證、存在種種疑惑的技術(shù)，而是一味的拿來主義，這樣的風險可想而知。

確保選擇的技術(shù)，是業(yè)界使用最多的、被大家認可的技術(shù)，即使出現(xiàn)了問題，也能應對自如。至少在團隊內(nèi)部小范圍是非常認可的。

3.強大社區(qū)支撐的技術(shù)

GitHub上star的數(shù)量是一個重要指標，同時參考近年來代碼、文檔、issues等更新頻率，各大技術(shù)博客是否有相關(guān)技術(shù)分享記載，這些都是能夠說明該技術(shù)是否活躍、受歡迎程度、使用人群多少等。

擁有強大社區(qū)支持的技術(shù)，在選型后，倘若使用出現(xiàn)疑問、問題、bug等，能夠有地方可提、可修復、可深究探討，畢竟現(xiàn)在的技術(shù)社區(qū)都是足夠開放的。

慎選個人開源的技術(shù)框架、組件等，里面到底有多少坑，沒幾個人能說清楚的，況且說不定哪天就不復存在了呢。

4.從業(yè)務、項目規(guī)模出發(fā)

任何技術(shù)的出發(fā)點都是為最終業(yè)務而服務的，不同業(yè)務、不同項目規(guī)模，對技術(shù)的要求指標都是不同的。

處于初創(chuàng)期的業(yè)務，選型的基準是相對靈活，畢竟業(yè)務相對簡單，支撐業(yè)務不是很大，只要夠用、開發(fā)效率足夠高就好。處于復雜業(yè)務而重構(gòu)的項目，選型就需謹慎，往往伴隨著一些復雜需求誕生、規(guī)模大小的不確定性，不得不考慮選型技術(shù)可能伴隨著一些小修小補或者螺旋式上升的重構(gòu)，則需選型便于適配、切換、替換，耦合度低的技術(shù)。

正因為技術(shù)選型和業(yè)務相關(guān)，我們能夠觀察到一些很明顯的現(xiàn)象：新技術(shù)往往被早期創(chuàng)業(yè)團隊或大公司的新興業(yè)務使用；中大型公司的核心業(yè)務則更傾向于用一些穩(wěn)定了幾年的技術(shù)；一個公司如果長期使用一種技術(shù)，就會傾向于一直使用下去，甚至連版本都不更新的使用下去。

學會從業(yè)務端思考。首先我們需要充分地理解業(yè)務，理解用戶需求，理解當下需要解決的首要問題，以及可能的風險有哪些，再將目標進行分解，進行具體的技術(shù)選型、模型設計、架構(gòu)設計。

5.先驗證后使用

對于未經(jīng)驗證的新技術(shù)、新理念的引入一定要慎重，一定要在全方位的驗證過后，再大規(guī)模的使用，最終確定選型。

新技術(shù)、新理念的出現(xiàn)，自然有它的誘惑，慎重并不代表保守，技術(shù)總是在不斷前進，擁抱變化本身沒有問題，但是引入不成熟的技術(shù)看似能帶來短期的收益，但是它的風險或者是后期的成本可能遠遠大于收益。

驗證后，才有說服力，用著更放心。

二、技術(shù)選型

每種技術(shù)架構(gòu)都有其優(yōu)缺點，存在即合理，不同的業(yè)務場景使用不同的應用架構(gòu)，技術(shù)框架，不一定說最新的架構(gòu)、技術(shù)就是最適合你的。

微服務架構(gòu)中常提及到的主要技術(shù)框架選型如下表所示，本文后面將基于此展開說明對比。

三、服務治理

1.Dubbo

Dubbo是一款高性能、輕量級的開源JAVA RPC框架，以及SOA服務治理方案。簡單的說，Dubbo就是個服務框架，說白了就是個遠程服務調(diào)用的分布式框架。它提供了三大核心能力：面向接口的遠程方法調(diào)用、智能容錯和負載均衡、以及服務自動注冊和發(fā)現(xiàn)，很容易和Spring框架無縫集成。

Dubbo邏輯架構(gòu)如下圖所示：

•  Provider：暴露服務的提供方，可以通過jar或者容器的方式啟動服務；
•  Consumer：調(diào)用遠程服務的服務消費方；
•  Registry：服務注冊中心和發(fā)現(xiàn)中心；
•  Monitor：統(tǒng)計服務和調(diào)用次數(shù)，調(diào)用時間監(jiān)控中心（dubbo的控制臺頁面中可以顯示，目前只有一個簡單版本）；
•  Container：服務運行的容器。

Dubbo特點：

•  遠程通訊: 提供對多種基于長連接的NIO框架抽象封裝（非阻塞I/O的通信方式，Mina/Netty/Grizzly），包括多種線程模型，序列化（Hessian2/ProtoBuf），以及“請求-響應”模式的信息交換方式。
•  集群容錯: 提供基于接口方法的透明遠程過程調(diào)用（RPC），包括多協(xié)議支持（自定義RPC協(xié)議），以及軟負載均衡（Random/RoundRobin），失敗容錯（Failover/Failback），地址路由，動態(tài)配置等集群支持。

    自動發(fā)現(xiàn): 基于注冊中心目錄服務，使服務消費方能動態(tài)的查找服務提供方，使地址透明，使服務提供方可以平滑增加或減少機器。

在現(xiàn)有的微服務架構(gòu)下，Dubbo只能說是一個服務治理框架，或者說是一個RPC框架，是以接口為粒度，一個接口類就就是一個服務。如果直接用Dubbo來實現(xiàn)微服務架構(gòu)，還缺少以下幾個功能：  

•  分布式配置：可以使用Spring Cloud Config、Apollo等來實現(xiàn)；
•  鏈路追蹤：可以使用Zipkin、CAT等來實現(xiàn)；
•  批量任務：可以使用當當網(wǎng)開源的Elastic-Job來實現(xiàn)。

2.Spring Cloud

Spring Cloud是目前最主流的微服務架構(gòu)落地首選方案之一，是基于Spring Boot實現(xiàn)的開源框架，是一個全家桶，是微服務的整體技術(shù)棧。

Spring Boot是Spring 的一套快速配置腳手架，使用默認大于配置的理念，用于快速開發(fā)單個微服務。

它為服務注冊發(fā)現(xiàn)、*動態(tài)路由*、負載均衡、*配置管理*、消息總線、**熔斷器**、分布式鏈路追蹤、*大數(shù)據(jù)操作*等提供了簡單的實現(xiàn)，讓我們可以更簡潔的使用它。

正如我們前面說過的，微服務是可以獨立部署、水平擴展、獨立訪問的服務單元，而Spring Cloud就是這些微服務的“大管家”，采用了微服務這種架構(gòu)之后，項目的數(shù)量會非常多，調(diào)用鏈路復雜，從而管理成了很大的問題，而Spring Cloud框架恰恰提供了各種組件用于管理和治理微服務。理所應當?shù)?，就成了大家首選框架了。

Spring Cloud的整體架構(gòu)如下圖所示，提供一站式的微服務架構(gòu)解決方案。

使用Spring Cloud來構(gòu)建微服務架構(gòu)可以省去你整合各家技術(shù)的成本，Spring Cloud為我們構(gòu)建微服務架構(gòu)提供了一站式的解決方案，就好比當初Spring誕生是為解決EJB企業(yè)應用開發(fā)的眾多問題而提供的一站式輕量級企業(yè)應用開發(fā)解決方案一樣，隨著使用Spring Cloud的產(chǎn)品數(shù)量增加，Spring Cloud在微服務架構(gòu)中已一統(tǒng)江湖。

下面是Spring Cloud的完整技術(shù)棧，看完你就知道它為啥會在微服務架構(gòu)中一統(tǒng)江湖了。

3.對比、總結(jié)

通過上表對比，很容易發(fā)現(xiàn)Spring Cloud擁有很多的項目模塊，包含了微服務系統(tǒng)的方方面面。Dubbo是一個非常優(yōu)秀的服務治理和服務調(diào)用框架，但缺少很多功能模塊，例如網(wǎng)關(guān)、鏈路追蹤等。在項目模塊上，Spring Cloud占據(jù)著更大的優(yōu)勢。對比并不是否定誰，推崇誰，只是說明在不同場景下，有利優(yōu)劣，需客觀來看。

如果僅關(guān)注于服務治理的這個層面，Dubbo其實還優(yōu)于Spring Cloud很多：

•  支持多種序列化協(xié)議，如Hessian、HTTP、WebService；
•  Dobbo Admin后臺管理功能強大，提供了路由規(guī)則、動態(tài)配置、訪問控制、權(quán)重調(diào)節(jié)、均衡負載等功能；
•  在國內(nèi)影響力比較大，中文社區(qū)文檔較為全面；
•  阿里最近重啟維護，成為Apache孵化項目；
•  Dubbo使用RPC協(xié)議效率更高，在極端壓力測試下，Dubbo的效率會高于Spring Cloud效率一倍多。

如果對效率有極高的要求建議使用Dubbo，相對比RPC的效率會比Restful高很多，如果選擇微服務架構(gòu)去重構(gòu)整個技術(shù)體系，那么 Spring Cloud是當仁不讓之選，它可以說是目前最好的微服務框架沒有之一，并且可以斷言，將來Dubbo可以很好的整合到Spring Cloud中。

四、API網(wǎng)關(guān)

API網(wǎng)關(guān)作為微服務中所有服務的唯一入口，免得業(yè)界各類成熟的技術(shù)框架組件，在進行技術(shù)選型時，需要特別考慮是否擁有以下特性：

•  高可用：網(wǎng)關(guān)是對外的唯一關(guān)口，必須保證 7 * 24小時可用，持續(xù)提供穩(wěn)定可靠的服務；
•  高性能：所有的請求都會經(jīng)過網(wǎng)關(guān)，它承受的壓力是巨大的，所以必須保證它具備良好的性能，以應對高并發(fā)請求；
•  安全性：網(wǎng)關(guān)必須能夠防止外部的惡意訪問，確保內(nèi)部各個微服務的安全；
•  擴展性：網(wǎng)關(guān)是一個處理非業(yè)務功能的絕佳場所，必須能夠提供流量管控、協(xié)議轉(zhuǎn)發(fā)、日志監(jiān)控等服務，同時能夠為以后對非業(yè)務功能的擴展提供良好的兼容性。

1.Zuul

Zuul作為Spring Cloud中的核心組件之一，充當API網(wǎng)關(guān)的重要角色，所有請求都可以通過Zuul達到后端的應用程序、服務。Zuul提供了動態(tài)路由、監(jiān)控、彈性負載和安全等特性，其核心是一系列的Filter，其作用類似于Servlet框架中的Filter，或者AOP。

Zuul底層利用各種Filter實現(xiàn)了如下功能：

•  動態(tài)路由：根據(jù)需要將請求動態(tài)路由到后端集群；
•  身份認證和安全性：識別每個需要認證的資源，拒絕不符合要求的請求，如：鑒權(quán)；
•  統(tǒng)計監(jiān)測：在服務邊界追蹤并統(tǒng)計數(shù)據(jù)，提供精確的統(tǒng)計監(jiān)測視圖；
•  壓力測試：逐漸增加對集群的流量以了解其性能；
•  負載卸載：預先為每種類型的請求分配容量，當請求超過容量時自動丟棄；
•  靜態(tài)資源處理：直接在邊界返回某些響應。

基于上述這些功能特性，使得Zuul作為API網(wǎng)關(guān)的不二之選。

Zuul的邏輯架構(gòu)如下圖所示:

Zuul的過濾器之間是不直接通信的，而是通過一個RequestContext的類來進行數(shù)據(jù)傳統(tǒng)，RequestContext繼承ConcurrentHashMap，使用ThreadLocal變量來記錄每個Request需要傳遞的數(shù)據(jù)。

Zuul的過濾器是由Groovy來實現(xiàn)的，這些過濾器文件被存放在Zuul Server的特定目錄下，Zuul會定期輪詢這些目錄，修改過的過濾器會動態(tài)加載到Zuul Server中，以便過濾請求使用。

Zuul的大部分功能都是通過過濾器來實現(xiàn)的，其中定義了4種標準的過濾器類型(pre、route、post、error)，以滿足應用于請求的不同階段。  

(如果想更清晰深入的了解Zuul，可以參考上圖的Zuul邏輯架構(gòu)圖，并結(jié)合Zuul源碼深入研究下。)

2.traefik

在了解traefik之前，不妨先看看它的整體架構(gòu)圖，如下所示：

從上圖不難看出，traefik充當了HTTP反向代理的角色，使得發(fā)布的服務變得輕松有趣。在微服務中，實質(zhì)上是一個為了讓部署微服務變得更加便捷而誕生的HTTP反向代理、負載均衡工具。，它支持多種后臺 (Docker, Swarm, Kubernetes, Marathon, Mesos, Consul, Etcd, Zookeeper, BoltDB, Rest API, file…) 來自動化、動態(tài)的應用它的配置文件設置。

除了眾多功能之外，traefik的與眾不同之處還在于它會自動發(fā)現(xiàn)適合您服務的配置。無需維護和同步單獨的配置文件,一切都會自動，實時地進行（無需重新啟動，不會中斷連接）。使用traefik后，你可以將更多的精力、時間花費在開發(fā)和部署上面，而不是在配置和維護其工作狀態(tài)上。

特性：

•  高性能；
•  無需安裝其他依賴，通過Go語言編寫的單一可執(zhí)行文件；
•  支持Restful API接口；
•  多種后臺支持：Docker, Swarm, Kubernetes, Marathon, Mesos, Consul, Etcd；
•  后臺監(jiān)控, 可以監(jiān)聽后臺變化進而自動化應用新的配置文件設置；
•  配置文件熱更新（無需重啟）；
•  正常結(jié)束http連接；
•  后端斷路器；
•  輪詢，rebalancer 負載均衡；
•  Rest Metrics；
•  支持最小化官方docker鏡像；
•  后臺支持SSL；
•  前臺支持SSL（包括SNI）；
•  清爽的AngularJS前端頁面；
•  支持Websocket；
•  支持HTTP/2；
•  網(wǎng)絡錯誤重試；
•  支持Let’s Encrypt (自動更新HTTPS證書)；
•  高可用集群模式。

3.OpenResty

OpenResty是一個基于Nginx與Lua的高性能Web平臺，其內(nèi)部集成了大量精良的Lua庫、第三方模塊以及大多數(shù)的依賴項。用于方便地搭建能夠處理超高并發(fā)、擴展性極高的動態(tài)Web應用、Web服務和動態(tài)網(wǎng)關(guān)。

OpenResty通過匯聚各種設計精良的Nginx模塊（主要由OpenResty團隊自主開發(fā)），從而將Nginx有效地變成一個強大的通用Web應用平臺。這樣，Web 開發(fā)人員和系統(tǒng)工程師可以使用Lua腳本語言調(diào)動 Nginx支持的各種C以及Lua模塊，快速構(gòu)造出足以勝任10K乃至 1000K以上單機并發(fā)連接的高性能Web應用系統(tǒng)。

OpenResty的目標是讓你的Web服務直接跑在Nginx服務內(nèi)部，充分利用Nginx的非阻塞I/O模型，不僅僅對HTTP客戶端請求,甚至于對遠程后端諸如MySQL、PostgreSQL、Memcached以及Redis等都進行一致的高性能響應。

4.Kong

Kong是一個在Nginx中運行的Lua應用程序，并且可以通過lua-nginx模塊實現(xiàn)，Kong不是用這個模塊編譯Nginx，而是與OpenResty一起發(fā)布，OpenResty已經(jīng)包含了lua-nginx-module，OpenResty不是 Nginx的分支，而是一組擴展功能的模塊。

是一個Api Gateway，通過插件的形式提供負載均衡，日志記錄，身份驗證，速率限制，轉(zhuǎn)換等功能?？梢院茌p松擴展功能，模塊化，可以運行在任何基礎設施上。

它的核心是實現(xiàn)數(shù)據(jù)庫抽象，路由和插件管理，插件可以存在于單獨的代碼庫中，并且可以在幾行代碼中注入到請求生命周期的任何位置。很方便地為路由和服務提供各種插件，網(wǎng)關(guān)所需要的基本特性，Kong都如數(shù)支持：

•  云原生：與平臺無關(guān)，Kong可以從裸機運行到Kubernetes；
•  動態(tài)路由：Kong的背后是OpenResty+Lua，所以從OpenResty繼承了動態(tài)路由的特性；
•  熔斷；
•  健康檢查；
•  日志：可以記錄通過Kong的HTTP，TCP，UDP請求和響應；
•  鑒權(quán)：權(quán)限控制，IP黑白名單，同樣是OpenResty的特性；
•  SSL: 可以為基礎服務或API設置特定的SSL證書；
•  監(jiān)控：Kong提供了實時監(jiān)控插件；
•  認證：如數(shù)支持HMAC, JWT, Basic, OAuth2.0等常用協(xié)議；
•  限流；
•  REST API：通過Rest API進行配置管理，從繁瑣的配置文件中解放；
•  可用性: 天然支持分布式；
•  高性能: 背靠非阻塞通信的nginx，性能自不用說；
•  插件機制: 提供眾多開箱即用的插件，且有易于擴展的自定義插件接口，用戶可以使用Lua自行開發(fā)插件。

上面這些特性中，反復提及了Kong背后的OpenResty，實際上，使用 Kong之后，Nginx可以完全摒棄，因為Kong的功能是Nginx的父集。

5.對比、總結(jié)

綜上對比，從開源社區(qū)活躍度和學習成本來看，無疑是Zuul和Traefik較好；從成熟度來看，較好的是Kong、Traefik；從性能角度來看，Kong要比其他幾個領先一些，從架構(gòu)優(yōu)勢的擴展性來看，Kong豐富的插件，而Zuul是完全需要自研各類Filter，但Zuul由于與Spring Cloud深度集成，使用度也很高。

五、服務注冊與發(fā)現(xiàn)

服務注冊與發(fā)現(xiàn)，是一個古老的話題，當應用開始脫離單機運行和訪問時，服務注冊與發(fā)現(xiàn)就誕生了。

目前的網(wǎng)絡架構(gòu)是每個主機都有一個獨立的IP地址，那么服務發(fā)現(xiàn)基本上都是通過某種方式獲取到服務所部署的IP地址。

DNS協(xié)議是最早將一個網(wǎng)絡名稱翻譯為網(wǎng)絡IP的協(xié)議，在最初的架構(gòu)選型中，DNS+LVS+Nginx基本可以滿足所有的RESTful服務的發(fā)現(xiàn)，此時服務的IP列表通常配置在Nginx或者LVS。后來出現(xiàn)了RPC服務，服務的上下線更加頻繁，人們開始尋求一種能夠支持動態(tài)上下線并且推送IP列表變化的注冊中心框架或組件。

現(xiàn)如今，各類服務注冊與發(fā)現(xiàn)的框架、組件很多(Zookeeper、Eureka、Consul、etcd等)，在選擇上更是眼花繚亂。在服務注冊與發(fā)現(xiàn)的技術(shù)選型上，我覺得我們應該還是有一定遵循原則和關(guān)注要點的。通?？蓮囊韵聨讉€方面出發(fā)，進行重點關(guān)注、抉擇：

•  數(shù)據(jù)一致性；
•  負載均衡；
•  健康檢查；
•  性能與容量；
•  易用性；
•  集群擴展性；
•  用戶擴展性。

六、配置中心

在微服務架構(gòu)中，服務的數(shù)量以及配置信息的日益增多，比如各種服務器參數(shù)配置、各種數(shù)據(jù)庫訪問參數(shù)配置、各種環(huán)境下配置信息的不同、配置信息修改之后實時生效等等，傳統(tǒng)的配置文件方式或者將配置信息存放于數(shù)據(jù)庫中的方式已無法滿足開發(fā)人員對配置管理的要求，如：

•  安全性：配置跟隨源代碼保存在代碼庫中，容易造成配置泄漏；
•  時效性：修改配置，需要重啟服務才能生效；
•  局限性：無法支持動態(tài)調(diào)整：例如日志開關(guān)、功能開關(guān)。

在微服務架構(gòu)中，使用配置中心之前，上述的問題或麻煩，你肯定也會遇到過，所以，是否引入配置中心，取決于你是否有下面的需求：

•  配置集中化統(tǒng)一管理；
•  配置實時生效。

一般完善的配置中心，都會從以下兩個方面設計出發(fā)，以發(fā)揮配置中心的作用。

•  配置實時生效：

傳統(tǒng)的靜態(tài)配置方式要想修改某個配置只能修改之后重新發(fā)布應用，要實現(xiàn)動態(tài)性，可以選擇使用數(shù)據(jù)庫，通過定時輪詢訪問數(shù)據(jù)庫來感知配置的變化。輪詢頻率低感知配置變化的延時就長，輪詢頻率高，感知配置變化的延時就短，但比較損耗性能，需要在實時性和性能之間做折中。配置中心專門針對這個業(yè)務場景，兼顧實時性和一致性來管理動態(tài)配置。

•  配置管理流程：

配置的權(quán)限管控、灰度發(fā)布、版本管理、格式檢驗和安全配置等一系列的配置管理相關(guān)的特性也是配置中心不可獲取的一部分。(這也算是配置中心的高級特性作用)

1.Spring Cloud Config

Spring Cloud Config作為Spring Cloud中的一個組件，其功能開放，可開發(fā)性強，常是各類配置中心自我研發(fā)的基石。

從Spring Cloud Config的源碼(spring-cloud-config-server)中，可以看出目前支持本地存儲、Git倉庫存儲、SVN倉庫存儲、數(shù)據(jù)庫存儲方式，其他存儲方式可參考源碼自行實現(xiàn)即可。

以Git存儲方式為例說明，Spring Cloud Config包含config-server、Git和Spring Cloud Bus三大組件：

•  config-server提供給客戶端獲取配置；
•  Git用于存儲和修改配置；
•  Spring Cloud Bus通知客戶端配置變更。

本地測試模式下，Spring Cloud Bus和config-server需要部署一個節(jié)點，Git使用GitHub就可以。在生產(chǎn)環(huán)境中，Spring Cloud Config，config-server需要部署至少兩個節(jié)點。Spring Cloud Bus如果使用RabbitMQ，普通集群模式至少需要兩個節(jié)點。

Git服務如果使用GitHub就不用考慮高可用問題，如果考慮到安全性要自建Git私有倉庫，整體的成本比較高。Web服務可以部署多節(jié)點支持高可用，由于Git有數(shù)據(jù)的一致性問題，可以通過以下的方式來支持高可用：

•  Git+Keepalived冷備模式，當主Git掛了可以馬上切到備Git；
•  Git多節(jié)點部署，存儲使用網(wǎng)絡文件系統(tǒng)或者通過DRBD實現(xiàn)多個Git節(jié)點的數(shù)據(jù)同步。

2.Apollo

Apollo（阿波羅）是攜程框架部門研發(fā)的分布式配置中心，能夠集中化管理應用不同環(huán)境、不同集群的配置，配置修改后能夠?qū)崟r推送到應用端，并且具備規(guī)范的權(quán)限、流程治理等特性，適用于微服務配置管理場景。

Apollo分為MySQL，Config Service，Admin Service，Portal四個模塊：

•  MySQL：存儲Apollo元數(shù)據(jù)和用戶配置數(shù)據(jù)；
•  Config Service：提供配置的讀取、推送等功能，客戶端請求都是落到Config Service上；
•  Admin Service：提供配置的修改、發(fā)布等功能，Portal操作的服務就是Admin Service；
•  Portal：提供給用戶配置管理界面。

本地測試Config Service，Admin Service，Portal三個模塊可以合并一起部署，MySQL單獨安裝并創(chuàng)建需要的表結(jié)構(gòu)。在生產(chǎn)環(huán)境使用Apollo，Portal可以兩個節(jié)點單獨部署，穩(wěn)定性要求沒那么高的話，Config Service和Admin Service可以部署在一起，數(shù)據(jù)庫支持主備容災。

3.Nacos

Nacos是一個更易于構(gòu)建云原生應用的動態(tài)服務發(fā)現(xiàn)、配置管理和服務管理平臺。這正是Nacos官方給出的定義：

an easy-to-use dynamic service discovery, configuration and service management platform for building cloud native applications.

核心功能：

•  動態(tài)配置服務： 

動態(tài)配置服務讓您能夠以中心化、外部化和動態(tài)化的方式管理所有環(huán)境的配置。動態(tài)配置消除了配置變更時重新部署應用和服務的需要。配置中心化管理讓實現(xiàn)無狀態(tài)服務更簡單，也讓按需彈性擴展服務更容易。

•  服務發(fā)現(xiàn)及管理：  

動態(tài)服務發(fā)現(xiàn)對以服務為中心的（例如微服務和云原生）應用架構(gòu)方式非常關(guān)鍵。Nacos支持DNS-Based和RPC-Based（Dubbo、gRPC）模式的服務發(fā)現(xiàn)。Nacos也提供實時健康檢查，以防止將請求發(fā)往不健康的主機或服務實例。借助Nacos，您可以更容易地為您的服務實現(xiàn)斷路器。

•  動態(tài)DNS服務：  

通過支持權(quán)重路由，動態(tài)DNS服務能讓您輕松實現(xiàn)中間層負載均衡、更靈活的路由策略、流量控制以及簡單數(shù)據(jù)中心內(nèi)網(wǎng)的簡單DNS解析服務。動態(tài)DNS服務還能讓您更容易地實現(xiàn)以DNS協(xié)議為基礎的服務發(fā)現(xiàn)，以消除耦合到廠商私有服務發(fā)現(xiàn)API上的風險。

Nacos部署需要Nacos Service和MySQL：

•  Nacos Service：對外提供服務，支持配置管理和服務發(fā)現(xiàn)；
•  MySQL：提供Nacos的數(shù)據(jù)持久化存儲。

單機模式下，Nacos可以使用嵌入式數(shù)據(jù)庫部署一個節(jié)點，就能啟動。如果對MySQL比較熟悉，想要了解整體數(shù)據(jù)流向，可以安裝MySQL提供給Nacos數(shù)據(jù)持久化服務。生產(chǎn)環(huán)境使用Nacos，Nacos服務需要至少部署三個節(jié)點，再加上MySQL主備。

4.對比、總結(jié)

整體來看，Nacos的部署結(jié)構(gòu)比較簡單，運維成本較低。Apollo部署組件較多，運維成本比Nacos高。Spring Cloud Config易于定制化二次開發(fā)，生產(chǎn)高可用的成本最高。

總的來說，Apollo和Nacos相對于Spring Cloud Config的生態(tài)支持更廣，在配置管理流程上做的更好。Apollo相對于Nacos在配置管理做的更加全面，不過使用起來也要麻煩一些。Nacos使用起來相對比較簡潔，在對性能要求比較高的大規(guī)模場景更適合。