作者: joyo 來源: https://joyohub.com/micro-server/

Part1 序

• 隨着互聯網業務複雜性慢慢提高，單機服務的架構慢慢出現了生產效率問題

• 微服務架構帶來的有優點也有缺點，使用前需要調研清楚

• 微服務架構的網關設計、服務註冊 / 發現、配置管理都是關鍵點

Part2 單體結構

1 什麼是單體結構？

• Web 應用程序發展的早期，大部分 web 工程是將所有的功能模塊 (service side) 打包到一起並放在一個 web 容器中運行，很多企業的 Java 應用程序打包爲 war 包。

• 比如構建一個在線商店系統：客戶下訂單、覈對清單和信用卡額度，並將貨物運輸給客戶。可能會構造出如下圖所示的系統：

單體架構

• 這種將所有功能都部署在一個 web 容器中運行的系統就叫做單體架構（也叫：巨石型應用）。

• 單體架構有很多好處：IDE 都是爲開發單個應用設計的、容易測試——在本地就可以啓動完整的系統、容易部署——直接打包爲一個完整的包，拷貝到 web 容器的某個目錄下即可運行。

但是，上述的好處是有條件的：應用不那麼複雜 。

• 對於大規模的複雜應用，單體架構應用會顯得特別笨重：要修改一個地方就要將整個應用全部部署 (PS：在不同的場景下優勢也變成了劣勢);

• 編譯時間過長; 迴歸測試周期過長; 開發效率降低等。

• 另外，單體架構不利於更新技術框架，除非你願意將系統全部重寫，那將是一件工作量極大的任務。

2 單體架構的優缺點

優點：

• 易於開發 ：開發方式簡單，IDE 支持好，方便運行和調試。

• 易於測試 ：所有功能運行在一個進程中，一旦進程啓動，便可以進行系統測試。

• 易於部署 ：只需要將打好的一個軟件包發佈到服務器即可。

• 易於水平伸縮 ：只需要創建一個服務器節點，配置好運行時環境，再將軟件包發佈到新服務器節點即可運行程序（當然也需要採取分發策略保證請求能有效地分發到新節點）。

缺點：

• 維護成本大 ：當應用程序的功能越來越多、團隊越來越大時，溝通成本、管理成本顯著增加。當出現 bug 時，可能引起 bug 的原因組合越來越多，導致分析、定位和修復的成本增加；並且在對全局功能缺乏深度理解的情況下，容易在修復 bug 時引入新的 bug。

• 持續交付週期長 ：構建和部署時間會隨着功能的增多而增加，任何細微的修改都會觸發部署流水線。

• 新人培養週期長 ：新成員瞭解背景、熟悉業務和配置環境的時間越來越長。

• 技術選型成本高 ：單塊架構傾向於採用統一的技術平臺或方案來解決所有問題，如果後續想引入新的技術或框架，成本和風險都很大。

• 可擴展性差 ：隨着功能的增加，垂直擴展的成本將會越來越大；而對於水平擴展而言，因爲所有代碼都運行在同一個進程，沒辦法做到針對應用程序的部分功能做獨立的擴展。

Part3 微服務

3 什麼是微服務？

• 在微服務架構中，業務邏輯被拆分成一系列小而鬆散耦合的分佈式組件，共同構成了較大的應用。

• 每個組件都被稱爲微服務，而每個微服務都在整體架構中執行着單獨的任務，或負責單獨的功能。

• 每個微服務可能會被一個或多個其他微服務調用，以執行較大應用需要完成的具體任務；

總結起來就是：

1）一組小的服務（大小沒有特別的標準，只要同一團隊的工程師理解服務的標識一致即可）

2）獨立的進程（java 的 tomcat，nodejs 等）

3）輕量級的通信（不是 soap，是 http 協議或者是 Tcp 協議）

4）基於業務能力（類似電商的訂單服務、用戶服務、商品服務等等）

5）獨立部署（迭代速度快）

6）無集中式管理（無須統一技術棧，可以根據不同的服務或者團隊進行靈活選擇，只要提供調用就可以）

4 微服務的優缺點

優點

優點一：拆分系統

• 通過分解巨大單體應用爲多個服務方法解決了複雜性問題。

• 在功能不變的情況下，應用被分解爲多個可管理的分支或服務。

• 每個服務都有一個用 RPC 或者消息驅動 API 定義清楚的邊界。

優點二：分治管理

• 微服務架構使得每個服務都可以有專門開發團隊來開發。

• 開發者可以自由選擇開發技術，提供 API 服務。

優點三：簡化部署和增強擴展

• 微服務架構模式使得每個微服務獨立部署，開發者不再需要協調其它服務部署對本服務的影響。

• 微服務架構模式使得每個服務獨立擴展。

• 可以根據每個服務的規模來部署滿足需求的實利。

缺點

缺點一：拆分大小限制

• 跟他的名字類似，“微服務” 強調了服務大小，實際上，有一些開發者鼓吹建立稍微大一些的，10-100 LOC 服務組。

• 儘管小服務更樂於被採用，但是不要忘了微服務只是結果，而不是最終目的。

• 微服務的目的是有效的拆分應用，實現敏捷開發和部署。

缺點二：增加編碼的複雜性

• 微服務應用是分佈式系統，由此會帶來固有的複雜性。

• 開發者需要在 RPC 或者消息傳遞之間選擇並完成進程間通訊機制。

• 此外，他們必須寫代碼來處理消息傳遞中速度過慢或者不可用等局部失效問題。

缺點三：數據存儲難度增大

• 另外一個關於微服務的挑戰來自於分區的數據庫架構。

• 同時更新多個業務主體的事務很普遍。這種事務對於單體式應用來說很容易，因爲只有一個數據庫

• 在微服務架構應用中，需要更新不同服務所使用的不同的數據庫，需要處理好分佈式事務。

缺點四：測試完整服務複雜

• 測試一個基於微服務架構的應用也是很複雜的任務。

• 比如，採用流行的 Spring Boot 架構，對一個單體式 web 應用，測試它的 REST API，是很容易的事情。

• 反過來，同樣的服務測試需要啓動和它有關的所有服務（至少需要這些服務的 stubs）。再重申一次，不能低估了採用微服務架構帶來的複雜性。

缺點五：微服務架構模式應用的改變將會波及多個服務。

• 比如，假設你在完成一個案例，需要修改服務 A、B、C，而 A 依賴 B，B 依賴 C。

• 在單體式應用中，你只需要改變相關模塊，整合變化，部署就好了。

• 對比之下，微服務架構模式就需要考慮相關改變對不同服務的影響。

比如，你需要更新服務 C，然後是 B，最後纔是 A，幸運的是，許多改變一般隻影響一個服務，而需要協調多服務的改變很少。

缺點六：受網絡帶寬影響大

• 服務與服務之間都是通過 RPC 的方式來調用

• 分佈式系統是跨進程、跨網絡的調用，極受網絡延遲和帶寬的影響。

5 微服務架構

微服務體系按照請求接入，由外到內的順序，一般將整體架構分爲 接入層 、 網關層 、 業務服務層 、 支撐服務層 、 平臺服務層 、基礎設施層 六層。

1：接入層

負載均衡作用，運維團隊負責

2：網關層

反向路由，安全驗證，限流等

3：業務服務層

基礎服務和領域服務

4：支撐服務層

• 支撐服務層提供非業務功能，以支撐業務服務層和網關層軟件的正常運行。

• 核心模塊有服務註冊發現、集中配置、容錯限流、認證授權、日誌聚合、監控告警、後臺中間件（異步隊列、緩存、數據庫、任務調度）

5：平臺服務

• 平臺服務層站在系統平臺的角度上，處理系統發佈、資源調度整合等功能。

• 核心模塊有發佈系統、資源調度、容器鏡像治理、資源治理。

6：基礎設施層

• 包括計算、網絡、存儲、監控、安全、IDC 等。（雲計算服務）

Part4 微服務網關

6 什麼是服務網關？

服務網關可以這樣簡單理解：

服務網關 = 路由轉發 + 過濾器

1. 路由轉發：接收一切外界請求，轉發到後端的微服務上去；

2、過濾器：在服務網關中可以完成一系列的橫切功能，例如權限校驗、限流以及監控等，這些都可以通過過濾器完成（其實路由轉發也是通過過濾器實現的）。

7 爲什麼需要服務網關？

• 現在我們採用微服務架構了，在一個項目中微服務節點很多

• 如果讓每一個節點都去處理上面這些 “鑑權認證功能、Session 處理、安全檢查、日誌處理等” 會多出很多冗餘的代碼，也會給增加業務代碼的複雜度

• 因此我們就需要有一個「 API 網關 」把這些公共的功能獨立出來成爲一個服務來統一的處理這些事情。

舉個例子，以權限校驗的需求來講，我們有三個方案來解決：

方案一 : 每個服務都實現一遍權限校驗的代碼

方案二 : 將權限校驗的代碼抽取出來並作爲公共服務，然後其他所有服務都依賴這個服務

方案三 : 寫到服務網關的前置過濾器中，所有請求過來進行權限校驗

方案分析：

方案一

• 每個服務都有大量的權限校驗的代碼，代碼嚴重冗餘

• 如果還要擴展功能，代碼量將會更多，基本上方案不會被採用

方案二

• 由於每個服務引入了這個公共服務，那麼相當於在每個服務中都引入了相同的權限校驗的代碼，使得每個服務的 jar 包大小無故增加了一些，尤其是對於使用 docker 鏡像進行部署的場景，jar 越小越好；

• 由於每個服務都引入了這個公共服務，那麼我們後續升級這個服務可能就比較困難，而且公共服務的功能越多，升級就越難；

• 假設我們改變了公共服務中的權限校驗的方式，想讓所有的服務都去使用新的權限校驗方式，我們就需要將之前所有的服務都重新引包，編譯部署。

• 基本上方案二和方案一是換湯不換藥，仍然存在不合理的地方。

方案三

• 將權限校驗的邏輯寫在網關的過濾器中，後端服務不需要關注權限校驗的代碼，所以服務的 jar 包中也不會引入權限校驗的邏輯，不會增加 jar 包大小；

• 如果想修改權限校驗的邏輯，只需要修改網關中的權限校驗過濾器即可，而不需要升級所有已存在的微服務

• 所以網關的設計可以解決上面兩種方案的不足之處，所以再微服務架構中我們需要網關

網關

8 微服務網關的功能

路由轉發

• 「API 網關」是內部微服務的對外唯一入口，所以外面全部的請求都會先發到這個「API 網關」上，然後由「API 網關」來根據不同的請求去路由到不同的微服務節點上。

• 例如可以 根據接口映射路徑來轉發，也可以根據參數來轉發。

• 並且由於內部微服務實例也會隨着業務調整不停的變更，增加或者刪除節點，「API 網關」可以與「服務註冊」模塊進行協同工作，保證將外部請求轉發到最合適的微服務實例上面去。

負載均衡

• 既然「API 網關」是內部微服務的單一入口，所以「API 網關」在收到外部請求之後，還可以根據內部微服務每個實例的負荷情況進行動態的負載均衡調節。

• 一旦內部的某個微服務實例負載很高，甚至是不能及時響應，則「API 網關」就通過負載均衡策略減少或停止向這個實例轉發請求。

• 當所有的內部微服務實例都處理不過來的時候，「API 網關」還可以採用限流或熔斷的形式阻止外部請求，以保障整個系統的可用性。

安全認證

• 「API 網關」就像是微服務的大門守衛，每一個請求進來之後，都必須先在「API 網關」上進行身份驗證，身份驗證通過後才轉發給後面的服務，轉發的時候一般也會帶上身份信息。

• 同時「API 網關」也需要對每一個請求進行安全性檢查，例如參數的安全性、傳輸的安全性等等。

日誌記錄

• 既然所有的請求都需要走「API 網關」，那麼我們就可以在「API 網關」上統一集中的記錄下這些行爲日誌。

• 這些日誌既可以作爲我們後續事件查詢使用，也可以作爲系統的性能監控使用。

數據轉換

• 「API 網關」對外是面向多種不同的客戶端，不同的客戶端所傳輸的數據類型可能是不一樣的。

• 因此「API 網關」還需要具備數據轉換的功能，將不同客戶端傳輸進來的數據轉換成同一種類型再轉發給內部微服務上，這樣兼容了這些請求的多樣性，保證了微服務的靈活性。

9 微服務網關開源應用

Zuul

• Zuul 是由 Netflix 所開源的組件，基於 JAVA 技術棧開發的。

• Zuul 網關的使用熱度非常高，並且也集成到了 Spring Cloud 全家桶中了，使用起來非常方便。

zuul 架構

請求過程

• 首先將請求給 zuulservlet 處理，zuulservlet 中有一個 zuulRunner 對象，該對象中初始化了 RequestContext：作爲存儲整個請求的一些數據，並被所有的 zuulfilter 共享。

• zuulRunner 中還有 FilterProcessor，FilterProcessor 作爲執行所有的 zuulfilter 的管理器。

• FilterProcessor 從 filterloader 中獲取 zuulfilter，而 zuulfilter 是被 filterFileManager 所加載，並支持 groovy 熱加載，採用了輪詢的方式熱加載。

• 有了這些 filter 之後，zuulservelet 首先執行的 Pre 類型的過濾器，再執行 route 類型的過濾器，最後執行的是 post 類型的過濾器，如果在執行這些過濾器有錯誤的時候則會執行 error 類型的過濾器。

• 執行完這些過濾器，最終將請求的結果返回給客戶端。

• 主要特色是，這些過濾器可以動態插拔，就是如果需要增加減少過濾器，可以不用重啓，直接生效。

• 原理就是：通過一個 db 維護過濾器（上圖藍色部分），如果增加過濾器，就將新過濾器編譯完成後 push 到 db 中，有線程會定期掃描 db，發現新的過濾器後，會上傳到網關的相應文件目錄下，並通知過濾器 loader 進行加載相應的過濾器。

Tyk

• Tyk 是一個基於 GO 編寫的，輕量級、快速可伸縮的開源的 API 網關。

• 支持配額和速度限制，支持認證和數據分析，支持多用戶多組織，提供全 RESTful API

Kong

• Kong 是基於 OpenResty 技術棧的開源網關服務，因此其也是基於 Nginx 實現的。

• Kong 可以做到高性能、插件自定義、集羣以及易於使用的 Restful API 管理。

Traefik

• Traefik 是一個現代 HTTP 反向代理和負載均衡器，可以輕鬆部署微服務

• Traeffik 可以與現有的組件（Docker、Swarm，Kubernetes，Marathon，Consul，Etcd，…）集成，並自動動態配置

Ambassador

• Ambassador 是一個開源的微服務 API 網關，建立在 Envoy 代理之上，爲用戶的多個團隊快速發佈，監控和更新提供支持

• 支持處理 Kubernetes ingress controller 和負載均衡等功能，可以與 Istio 無縫集成

API 網關實現對比

• 從開源社區活躍度來看，無疑是 Kong 和 Traefik 較好；

• 從成熟度來看，較好的是 Kong、Tyk、Traefik；從性能角度來看，Kong 要比其他幾個領先一些；

• 從架構優勢的擴展性來看，Kong、Tyk 有豐富的插件，Ambassador 也有插件但不多，而 Zuul 是完全需要自研，但 Zuul 由於與 Spring Cloud 深度集成，使用度也很高，近年來 Istio 服務網格的流行，Ambassador 因爲能夠和 Istio 無縫集成也是相當大的優勢。具體使用選擇還是需要依據具體的業務場景

10 引入網關的微服務架構

引入服務網關後的微服務架構如上，總體包含三部分：服務網關、open-service 和 service。

微服務

訪問流程

• 服務網關、open-service 和 service 啓動時註冊到註冊中心上去；

• 用戶請求時直接請求網關，網關做智能路由轉發（包括服務發現，負載均衡）到 open-service，這其中包含權限校驗、監控、限流等操作

• open-service 聚合內部 service 響應，返回給網關，網關再返回給用戶

注意點

• 增加了網關，多了一層轉發（原本用戶請求直接訪問 open-service 即可），性能會下降一些

• 但是下降不大，通常，網關機器性能會很好，而且網關與 open-service 的訪問通常是內網訪問，速度很快；

• 網關的單點問題：在整個網絡調用過程中，一定會有一個單點，可能是網關、nginx、dns 服務器等。

• 防止網關單點，可以在網關層前邊再掛一臺 nginx，nginx 的性能極高，基本不會掛，這樣之後，網關服務就可以不斷的添加機器。但是這樣一個請求就轉發了兩次，所以最好的方式是網關單點服務部署在一臺牛逼的機器上（通過壓測來估算機器的配置）

• 網關要儘量輕量級。

Part5 微服務的服務註冊和發現

11 爲什麼需要服務註冊？

• 微服務架構中，一般集羣都會部署很多個微服務節點。這些節點一般也具備這 2 種角色，稱爲：“服務的提供者” 和 “服務的消費者”

• “服務消費者”需要調用 “服務提供者” 的 API 來獲得服務。當 “服務提供者” 的節點有增加或減少的時候，也得讓調用者（“服務消費者”）及時的知曉。

• 在大規模集羣中，一般節點數目都很多，節點變化頻繁，通過手動去維護這些節點的狀態是不現實的，因此需要一個叫做 “服務註冊中心” 的組件來實現。

• “服務提供者”將自己的服務地址等信息登記到 “服務註冊中心” 中，調用者（“服務消費者”）需要的時候，每次都先去 “服務註冊中心” 查詢即可。既解決了人工維護微服務節點狀態的問題，也能解決多節點間負載均衡的問題。

12 服務註冊原理

• 在分析其原理之前，我們先來看一下這裏包含的一些角色，有三類：“服務提供者”、“服務消費者”、“服務註冊中心”。

• 其中 “服務提供者” 需要將自己的服務信息註冊到 “服務註冊中心” 裏面。而 “服務消費者” 需要到 “服務註冊中心” 裏面去查詢有哪些服務可以調用。

因此，我們可以分爲兩個角度去分析原理：

角度一：“服務提供者”向 “服務註冊中心” 進行註冊

1. 服務自己註冊

• 自己註冊就是指微服務節點在啓動的時候，自己去服務註冊中心登記註冊了，把自己的信息和狀態傳過去。

• 這種方式整體結構比較簡單，對於註冊中心而言也比較省事，但是對於微服務節點而言，每個微服務都得包含這麼一段註冊的邏輯代碼，架構上看起來不是很優美。

自己註冊服務

2. 第三方註冊

• 第三方註冊就是指有一個 “服務管理器”（圖中的 Service Manager），這個“服務管理器” 會去管理所有的微服務和進程，以輪詢或其它方式去檢查有哪些微服務實例正在運行，會將這些微服務實例自動更新到服務註冊中心。

• 這是目前比較常用的方式，例如 Eureka 就是採用這個模式。

第三方註冊

角度二：“服務消費者”向 “服務註冊中心” 查詢和調用服務

1. 客戶端模式

client

• 在客戶端模式下，“服務消費者”（圖中的 Client）在向 “服務註冊中心” 查詢到自己需要調用的 “服務提供者” 的地址

• “服務消費者”（客戶端）就會自己根據查詢到的地址去訪問微服務（圖中的第 3 步 API Gateway 是可選項，有 API Gateway 的情況下，API Gateway 起到負載均衡作用，沒有第 3 步的話，那就是 Client 直接調用 Microservice，需要 Client 自己寫負載均衡邏輯）。

2. 代理模式

代理模式

• 在代理模式下，“服務消費者”（圖中的 Client）與 微服務、“服務註冊中心” 中間有一個 API Gateway 組件相隔着。

• “服務消費者”只管去找 API Gateway 訪問即可。至於去註冊中心查詢服務地址，以及訪問服務地址的動作都由 API Gateway 效勞了，最後 API Gateway 在把結果返回給 “服務消費者” 即可。

• 這種模式，看起來 “服務消費者” 省事了，但是 API Gateway 模塊卻複雜了，因爲 API Gateway 就是整個系統的一個非常核心關鍵節點了，不僅需要保障自己的穩定性和性能，而且還需要處理一些負載均衡的邏輯。

• 在大型架構中，這種模式用的還比較多，原理就是在網關加上了網關服務註冊和發現的邏輯。

13 開源的服務註冊發現框架

Eureka

Eureka 是由 Netflix 開源，其架構如下圖：

Eureka

• 從圖中可以看到，我們的服務（圖中 Application Clinet 與 Application Service）要使用 Eureka 就需要集成它的 SDK（圖中 Eureka Client）。

• 圖中的 Eureka 部署在了三個異地機房，也就是說 Eureka 是支持多中心部署的。

• 服務提供者（Application Service）通過 Eureka Client 實現服務的註冊、更新和註銷等。服務消費者（Application Clinet）通過 Eureka Client 實現服務的查詢和調用。

• Eureka 支持了與 Spring Cloud 的集成，所以使用起來也非常方便，目前屬於比較流行的方案。

Consul

• Consul 是在服務外進行完成一系列動作的，也就是說並不需要服務節點去依賴它的 SDK，沒有侵入性，所以跨語言的解決能力更強一些。

• 它一般是在服務節點外通過一些探針的方法去檢查應用是否存活，是否需要註冊或註銷。

• Consul 也支持 Spring Cloud 集成，所以使用起來也很方便，也屬於比較流行的方案。

Consul

Etcd

• etcd 是可通過 HTTP 訪問的鍵 / 值存儲。它是分佈式的，具有可用於構建服務發現的分層配置系統。

• 它易於部署，設置和使用，提供可靠的數據持久性，安全性和非常好的文檔。

• 由於其簡單性，etcd 是比 Zookeeper 更好的選擇。但是，它需要與少數第三方工具結合才能提供服務發現目標。

Part6 微服務配置中心

14 什麼是配置中心？

• 「配置中心」，顧名思義，就是用來統一管理項目中所有配置的系統。

• 如果一箇中型互聯網項目，不採用配置中心的模式，一大堆的各類配置項，各種不定時的修改需求，管理起來會十分混亂。

• 現在的服務都是集羣模式，如果每臺服務器都需要手動去更新，工作量可謂是遞增

15 爲什麼需要配置中心？

傳統項目中，我們是怎麼處理各類配置參數問題的：

1. 一般是靜態化配置

• 大多數在項目中單獨寫一個配置文件，例如 "config.yaml"，然後將各類參數配置、應用配置、環境配置、安全配置、業務配置 都寫到這個文件裏。

• 當項目代碼邏輯中需要使用配置的時候，就從這個配置文件中讀取。

• 這種做法雖然簡單，但如果參數需要修改，就非常的不靈活，甚至需要重啓運行中的項目才能生效。

2. 配置文件無法區分環境

• 由於配置文件是放在項目中的，但是我們項目可能會有多個環境，例如：測試環境、預發佈環境、生產環境。

• 每一個環境所使用的配置參數理論上都是不同的，所以我們在配置文件中根據不同環境配置不同的參數，這些都是手動維護，在項目發佈的時候，極其容易因開發人員的失誤導致出錯。

3. 配置文件過於分散

• 如果一個項目中存在多個邏輯模塊獨立部署，每個模塊所使用的配置內容又不相同.

• 傳統的做法是會在每一個模塊中都放一個配置文件，甚至不同模塊的配置文件格式還不一樣。

• 那麼長期的結果就是配置文件過於分散混亂，難以管理。

4. 配置修改無法追溯

• 因爲採用的靜態配置文件方式，所以當配置進行修改之後，不容易形成記錄，更無法追溯是誰修改的、修改時間是什麼、修改前是什麼內容。

• 既然無法追溯，那麼當配置出錯時，更沒辦法回滾配置了。

上面只是拿配置文件的形式來舉例，有的項目會採用數據庫配置，雖然靈活一點，但是依舊不能完全解決上述問題。

「配置中心」的方案是如何解決這些痛點的：

• 「配置中心」的思路就是把項目中各種配置、各種參數、各種開關，全部都放到一個集中的地方進行統一管理，並提供一套標準的接口。

• 當各個服務需要獲取配置的時候，就來「配置中心」的接口拉取。

• 當「配置中心」中的各種參數有更新的時候，也能通知到各個服務實時的過來同步最新的信息，使之動態更新。

16 配置中心的特點

• 配置集中管理、統一標準

• 配置與應用分離

• 實時更新

• 高可用

那麼，具有上述特性的「配置中心」是如何解決上面傳統配置所面臨的問題的呢？

• 解決傳統的 “配置文件過於分散” 的問題 ：採用 “配置集中管理”，所有的配置都集中在配置中心這一個地方管理，不需要每一個項目都自帶一個，這樣極大的減輕了開發成本。

• 解決傳統的 “配置文件無法區分環境” 的問題 ：採用 “配置與應用分離”，配置並不跟着環境走，當不同環境有不同需求的時候，就到配置中心獲取即可，極大的減輕了運維部署成本。

• 解決傳統的 “靜態化配置” 的問題 ：具備 “實時更新” 的功能，線上系統需要調整參數的時候，只需要在配置中心動態修改即可。

• 解決傳統的 “配置修改無法追溯” 的問題 ：配置統一管理，並且會記錄每一次修改的版本，通過修改版本可以追蹤歷史修改記錄。

• 既然配置都統一管理了，那配置中心在整個系統中的地位就非常重要了，一旦配置中心不能正常提供服務，就可能會導致項目整體故障，因此 “高可用” 就是配置中心又一個很關鍵的指標。

17 開源的配置中心方案

Apollo

• Apollo（阿波羅）是攜程框架部門研發的分佈式配置中心，能夠集中化管理應用不同環境、不同集羣的配置

• 配置修改後能夠實時推送到應用端，並且具備規範的權限、流程治理等特性，適用於微服務配置管理場景。

• 服務端基於 Spring Boot 和 Spring Cloud 開發，不依賴外部容器，便於部署。

• Java 客戶端不依賴任何框架，能夠運行於所有 Java 運行時環境，同時對 Spring/Spring Boot 環境也有額外支持。

• 原生支持 Java 和. Net 客戶端，同時也支持其他語言客戶端，目前已支持 Go、PHP、Python、NodeJS、C++。

apollo

Apollo 項目的 Github 地址

XDiamond

• 全局配置中心，存儲應用的配置項，解決配置混亂分散的問題。

• 名字來源於淘寶的開源項目 Diamond，前面加上一個字母 X 以示區別。

XDiamond 項目的 Github 地址

Qconf

• QConf 是一個分佈式配置管理工具。

• 用來替代傳統的配置文件，使得配置信息和程序代碼分離，同時配置變化能夠實時同步到客戶端，而且保證用戶高效讀取配置，這使的工程師從瑣碎的配置修改、代碼提交、配置上線流程中解放出來，極大地簡化了配置管理工作。

Qconf 項目的 Github 地址

Disconf

• 專注於各種「分佈式系統配置管理」的「通用組件」和「通用平臺」,

• 提供統一的「配置管理服務」包括 百度、滴滴出行、銀聯、網易、拉勾網、蘇寧易購、順豐科技 等知名互聯網公司正在使用!

Disconf 項目的 Github 地址

Part7 總結

• 以上主要總結了單點結構和微服務結構的區別和特點

• 然後介紹了微服務架構的網關設計、服務註冊和發現、分佈式配置中心的內容

• 微服務要探索的內容還有：服務框架、服務監控、服務治理、服務熔斷、服務降級等等

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/rjucAF4zvDylBfIri3RgeQ