Part1序

• 隨著互聯(lián)網(wǎng)業(yè)務復雜性慢慢提高，單機服務的架構慢慢出現(xiàn)了生產(chǎn)效率問題
• 微服務架構帶來的有優(yōu)點也有缺點，使用前需要調(diào)研清楚
• 微服務架構的網(wǎng)關設計、服務注冊/發(fā)現(xiàn)、配置管理都是關鍵點

Part2單體結構

1什么是單體結構？

• Web應用程序發(fā)展的早期，大部分web工程是將所有的功能模塊(service side)打包到一起并放在一個web容器中運行，很多企業(yè)的JAVA應用程序打包為war包。
• 比如構建一個在線商店系統(tǒng)：客戶下訂單、核對清單和信用卡額度，并將貨物運輸給客戶。可能會構造出如下圖所示的系統(tǒng)：

 

單體架構

• 這種將所有功能都部署在一個web容器中運行的系統(tǒng)就叫做單體架構（也叫：巨石型應用）。
• 單體架構有很多好處：IDE都是為開發(fā)單個應用設計的、容易測試——在本地就可以啟動完整的系統(tǒng)、容易部署——直接打包為一個完整的包，拷貝到web容器的某個目錄下即可運行。

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

• 對于大規(guī)模的復雜應用，單體架構應用會顯得特別笨重：要修改一個地方就要將整個應用全部部署(PS：在不同的場景下優(yōu)勢也變成了劣勢);
• 編譯時間過長;回歸測試周期過長;開發(fā)效率降低等。
• 另外，單體架構不利于更新技術框架，除非你愿意將系統(tǒng)全部重寫，那將是一件工作量極大的任務。

2單體架構的優(yōu)缺點

優(yōu)點：

• 易于開發(fā) ：開發(fā)方式簡單，IDE 支持好，方便運行和調(diào)試。
• 易于測試 ：所有功能運行在一個進程中，一旦進程啟動，便可以進行系統(tǒng)測試。
• 易于部署 ：只需要將打好的一個軟件包發(fā)布到服務器即可。
• 易于水平伸縮 ：只需要創(chuàng)建一個服務器節(jié)點，配置好運行時環(huán)境，再將軟件包發(fā)布到新服務器節(jié)點即可運行程序（當然也需要采取分發(fā)策略保證請求能有效地分發(fā)到新節(jié)點）。

缺點：

• 維護成本大 ：當應用程序的功能越來越多、團隊越來越大時，溝通成本、管理成本顯著增加。當出現(xiàn) bug 時，可能引起 bug 的原因組合越來越多，導致分析、定位和修復的成本增加；并且在對全局功能缺乏深度理解的情況下，容易在修復 bug 時引入新的 bug。
• 持續(xù)交付周期長 ：構建和部署時間會隨著功能的增多而增加，任何細微的修改都會觸發(fā)部署流水線。
• 新人培養(yǎng)周期長 ：新成員了解背景、熟悉業(yè)務和配置環(huán)境的時間越來越長。
• 技術選型成本高 ：單塊架構傾向于采用統(tǒng)一的技術平臺或方案來解決所有問題，如果后續(xù)想引入新的技術或框架，成本和風險都很大。
• 可擴展性差 ：隨著功能的增加，垂直擴展的成本將會越來越大；而對于水平擴展而言，因為所有代碼都運行在同一個進程，沒辦法做到針對應用程序的部分功能做獨立的擴展。

Part3微服務

3什么是微服務？

• 在微服務架構中，業(yè)務邏輯被拆分成一系列小而松散耦合的分布式組件，共同構成了較大的應用。
• 每個組件都被稱為微服務，而每個微服務都在整體架構中執(zhí)行著單獨的任務，或負責單獨的功能。
• 每個微服務可能會被一個或多個其他微服務調(diào)用，以執(zhí)行較大應用需要完成的具體任務；

總結起來就是：

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

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

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

4）基于業(yè)務能力（類似電商的訂單服務、用戶服務、商品服務等等）

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

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

4微服務的優(yōu)缺點

優(yōu)點

優(yōu)點一：拆分系統(tǒng)

• 通過分解巨大單體應用為多個服務方法解決了復雜性問題。
• 在功能不變的情況下，應用被分解為多個可管理的分支或服務。
• 每個服務都有一個用 RPC或者消息驅動 API 定義清楚的邊界。

優(yōu)點二：分治管理

• 微服務架構使得每個服務都可以有專門開發(fā)團隊來開發(fā)。
• 開發(fā)者可以自由選擇開發(fā)技術，提供 API 服務。

優(yōu)點三：簡化部署和增強擴展

• 微服務架構模式使得每個微服務獨立部署，開發(fā)者不再需要協(xié)調(diào)其它服務部署對本服務的影響。
• 微服務架構模式使得每個服務獨立擴展。
• 可以根據(jù)每個服務的規(guī)模來部署滿足需求的實利。

缺點

缺點一：拆分大小限制

• 跟他的名字類似，“微服務”強調(diào)了服務大小，實際上，有一些開發(fā)者鼓吹建立稍微大一些的，10-100 LOC服務組。
• 盡管小服務更樂于被采用，但是不要忘了微服務只是結果，而不是最終目的。
• 微服務的目的是有效的拆分應用，實現(xiàn)敏捷開發(fā)和部署。

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

• 微服務應用是分布式系統(tǒng)，由此會帶來固有的復雜性。
• 開發(fā)者需要在 RPC 或者消息傳遞之間選擇并完成進程間通訊機制。
• 此外，他們必須寫代碼來處理消息傳遞中速度過慢或者不可用等局部失效問題。

缺點三：數(shù)據(jù)存儲難度增大

• 另外一個關于微服務的挑戰(zhàn)來自于分區(qū)的數(shù)據(jù)庫架構。
• 同時更新多個業(yè)務主體的事務很普遍。這種事務對于單體式應用來說很容易，因為只有一個數(shù)據(jù)庫
• 在微服務架構應用中，需要更新不同服務所使用的不同的數(shù)據(jù)庫，需要處理好分布式事務。

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

• 測試一個基于微服務架構的應用也是很復雜的任務。
• 比如，采用流行的Spring Boot架構，對一個單體式web應用，測試它的REST API，是很容易的事情。
• 反過來，同樣的服務測試需要啟動和它有關的所有服務（至少需要這些服務的stubs）。再重申一次，不能低估了采用微服務架構帶來的復雜性。

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

• 比如，假設你在完成一個案例，需要修改服務A、B、C，而A依賴B，B依賴C。
• 在單體式應用中，你只需要改變相關模塊，整合變化，部署就好了。
• 對比之下，微服務架構模式就需要考慮相關改變對不同服務的影響。

比如，你需要更新服務C，然后是B，最后才是A，幸運的是，許多改變一般只影響一個服務，而需要協(xié)調(diào)多服務的改變很少。

缺點六：受網(wǎng)絡帶寬影響大

• 服務與服務之間都是通過RPC的方式來調(diào)用
• 分布式系統(tǒng)是跨進程、跨網(wǎng)絡的調(diào)用，極受網(wǎng)絡延遲和帶寬的影響。

5微服務架構

微服務體系按照請求接入，由外到內(nèi)的順序，一般將整體架構分為 接入層 、 網(wǎng)關層 、 業(yè)務服務層 、 支撐服務層 、 平臺服務層 、基礎設施層 六層。

 

1：接入層

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

2：網(wǎng)關層

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

3：業(yè)務服務層

基礎服務和領域服務

4：支撐服務層

• 支撐服務層提供非業(yè)務功能，以支撐業(yè)務服務層和網(wǎng)關層軟件的正常運行。
• 核心模塊有服務注冊發(fā)現(xiàn)、集中配置、容錯限流、認證授權、日志聚合、監(jiān)控告警、后臺中間件（異步隊列、緩存、數(shù)據(jù)庫、任務調(diào)度）

5：平臺服務

• 平臺服務層站在系統(tǒng)平臺的角度上，處理系統(tǒng)發(fā)布、資源調(diào)度整合等功能。
• 核心模塊有發(fā)布系統(tǒng)、資源調(diào)度、容器鏡像治理、資源治理。

6：基礎設施層

• 包括計算、網(wǎng)絡、存儲、監(jiān)控、安全、IDC等。（云計算服務）

Part4微服務網(wǎng)關

6什么是服務網(wǎng)關？

服務網(wǎng)關可以這樣簡單理解：

服務網(wǎng)關 = 路由轉發(fā) + 過濾器

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

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

7為什么需要服務網(wǎng)關？

• 現(xiàn)在我們采用微服務架構了，在一個項目中微服務節(jié)點很多
• 如果讓每一個節(jié)點都去處理上面這些 “鑒權認證功能、Session處理、安全檢查、日志處理等” 會多出很多冗余的代碼，也會給增加業(yè)務代碼的復雜度
• 因此我們就需要有一個「 API網(wǎng)關 」把這些公共的功能獨立出來成為一個服務來統(tǒng)一的處理這些事情。

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

方案一 :每個服務都實現(xiàn)一遍權限校驗的代碼

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

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

方案分析：

方案一

• 每個服務都有大量的權限校驗的代碼，代碼嚴重冗余
• 如果還要擴展功能，代碼量將會更多，基本上方案不會被采用

方案二

• 由于每個服務引入了這個公共服務，那么相當于在每個服務中都引入了相同的權限校驗的代碼，使得每個服務的jar包大小無故增加了一些，尤其是對于使用Docker鏡像進行部署的場景，jar越小越好；
• 由于每個服務都引入了這個公共服務，那么我們后續(xù)升級這個服務可能就比較困難，而且公共服務的功能越多，升級就越難；
• 假設我們改變了公共服務中的權限校驗的方式，想讓所有的服務都去使用新的權限校驗方式，我們就需要將之前所有的服務都重新引包，編譯部署。
• 基本上方案二和方案一是換湯不換藥，仍然存在不合理的地方。

方案三

• 將權限校驗的邏輯寫在網(wǎng)關的過濾器中，后端服務不需要關注權限校驗的代碼，所以服務的jar包中也不會引入權限校驗的邏輯，不會增加jar包大小；
• 如果想修改權限校驗的邏輯，只需要修改網(wǎng)關中的權限校驗過濾器即可，而不需要升級所有已存在的微服務
• 所以網(wǎng)關的設計可以解決上面兩種方案的不足之處，所以再微服務架構中我們需要網(wǎng)關

 

網(wǎng)關

8微服務網(wǎng)關的功能

路由轉發(fā)

• 「API網(wǎng)關」是內(nèi)部微服務的對外唯一入口，所以外面全部的請求都會先發(fā)到這個「API網(wǎng)關」上，然后由「API網(wǎng)關」來根據(jù)不同的請求去路由到不同的微服務節(jié)點上。
• 例如可以 根據(jù)接口映射路徑來轉發(fā)，也可以根據(jù)參數(shù)來轉發(fā)。
• 并且由于內(nèi)部微服務實例也會隨著業(yè)務調(diào)整不停的變更，增加或者刪除節(jié)點，「API網(wǎng)關」可以與「服務注冊」模塊進行協(xié)同工作，保證將外部請求轉發(fā)到最合適的微服務實例上面去。

負載均衡

• 既然「API網(wǎng)關」是內(nèi)部微服務的單一入口，所以「API網(wǎng)關」在收到外部請求之后，還可以根據(jù)內(nèi)部微服務每個實例的負荷情況進行動態(tài)的負載均衡調(diào)節(jié)。
• 一旦內(nèi)部的某個微服務實例負載很高，甚至是不能及時響應，則「API網(wǎng)關」就通過負載均衡策略減少或停止向這個實例轉發(fā)請求。
• 當所有的內(nèi)部微服務實例都處理不過來的時候，「API網(wǎng)關」還可以采用限流或熔斷的形式阻止外部請求，以保障整個系統(tǒng)的可用性。

安全認證

• 「API網(wǎng)關」就像是微服務的大門守衛(wèi)，每一個請求進來之后，都必須先在「API網(wǎng)關」上進行身份驗證，身份驗證通過后才轉發(fā)給后面的服務，轉發(fā)的時候一般也會帶上身份信息。
• 同時「API網(wǎng)關」也需要對每一個請求進行安全性檢查，例如參數(shù)的安全性、傳輸?shù)陌踩缘鹊取?/li>

日志記錄

• 既然所有的請求都需要走「API網(wǎng)關」，那么我們就可以在「API網(wǎng)關」上統(tǒng)一集中的記錄下這些行為日志。
• 這些日志既可以作為我們后續(xù)事件查詢使用，也可以作為系統(tǒng)的性能監(jiān)控使用。

數(shù)據(jù)轉換

• 「API網(wǎng)關」對外是面向多種不同的客戶端，不同的客戶端所傳輸?shù)臄?shù)據(jù)類型可能是不一樣的。
• 因此「API網(wǎng)關」還需要具備數(shù)據(jù)轉換的功能，將不同客戶端傳輸進來的數(shù)據(jù)轉換成同一種類型再轉發(fā)給內(nèi)部微服務上，這樣兼容了這些請求的多樣性，保證了微服務的靈活性。

9微服務網(wǎng)關開源應用

Zuul

• Zuul 是由.NETflix 所開源的組件，基于JAVA技術棧開發(fā)的。
• Zuul網(wǎng)關的使用熱度非常高，并且也集成到了 Spring Cloud 全家桶中了，使用起來非常方便。

 

zuul架構

請求過程

• 首先將請求給zuulservlet處理，zuulservlet中有一個zuulRunner對象，該對象中初始化了RequestContext：作為存儲整個請求的一些數(shù)據(jù)，并被所有的zuulfilter共享。
• zuulRunner中還有 FilterProcessor，F(xiàn)ilterProcessor作為執(zhí)行所有的zuulfilter的管理器。
• FilterProcessor從filterloader 中獲取zuulfilter，而zuulfilter是被filterFileManager所加載，并支持groovy熱加載，采用了輪詢的方式熱加載。
• 有了這些filter之后，zuulservelet首先執(zhí)行的Pre類型的過濾器，再執(zhí)行route類型的過濾器，最后執(zhí)行的是post 類型的過濾器，如果在執(zhí)行這些過濾器有錯誤的時候則會執(zhí)行error類型的過濾器。
• 執(zhí)行完這些過濾器，最終將請求的結果返回給客戶端。
• 主要特色是，這些過濾器可以動態(tài)插拔，就是如果需要增加減少過濾器，可以不用重啟，直接生效。
• 原理就是：通過一個db維護過濾器（上圖藍色部分），如果增加過濾器，就將新過濾器編譯完成后push到db中，有線程會定期掃描db，發(fā)現(xiàn)新的過濾器后，會上傳到網(wǎng)關的相應文件目錄下，并通知過濾器loader進行加載相應的過濾器。

Tyk

• Tyk是一個基于GO編寫的，輕量級、快速可伸縮的開源的API網(wǎng)關。
• 支持配額和速度限制，支持認證和數(shù)據(jù)分析，支持多用戶多組織，提供全 RESTful API

Kong

• Kong是基于OpenResty技術棧的開源網(wǎng)關服務，因此其也是基于Nginx實現(xiàn)的。
• Kong可以做到高性能、插件自定義、集群以及易于使用的Restful API管理。

Traefik

• Traefik 是一個現(xiàn)代 HTTP 反向代理和負載均衡器，可以輕松部署微服務
• Traeffik 可以與現(xiàn)有的組件（Docker、Swarm，Kubernetes，Marathon，Consul，Etcd，…）集成，并自動動態(tài)配置

Ambassador

• Ambassador 是一個開源的微服務 API 網(wǎng)關，建立在 Envoy 代理之上，為用戶的多個團隊快速發(fā)布，監(jiān)控和更新提供支持
• 支持處理 Kubernetes ingress controller 和負載均衡等功能，可以與 Istio 無縫集成

API 網(wǎng)關實現(xiàn)對比

• 從開源社區(qū)活躍度來看，無疑是Kong和Traefik較好；
• 從成熟度來看，較好的是Kong、Tyk、Traefik；從性能角度來看，Kong要比其他幾個領先一些；
• 從架構優(yōu)勢的擴展性來看，Kong、Tyk有豐富的插件，Ambassador也有插件但不多，而Zuul是完全需要自研，但Zuul由于與Spring Cloud深度集成，使用度也很高，近年來Istio服務網(wǎng)格的流行，Ambassador因為能夠和Istio無縫集成也是相當大的優(yōu)勢。具體使用選擇還是需要依據(jù)具體的業(yè)務場景

10引入網(wǎng)關的微服務架構

引入服務網(wǎng)關后的微服務架構如上，總體包含三部分：服務網(wǎng)關、open-service和service。

 

微服務

訪問流程

• 服務網(wǎng)關、open-service和service啟動時注冊到注冊中心上去；
• 用戶請求時直接請求網(wǎng)關，網(wǎng)關做智能路由轉發(fā)（包括服務發(fā)現(xiàn)，負載均衡）到open-service，這其中包含權限校驗、監(jiān)控、限流等操作
• open-service聚合內(nèi)部service響應，返回給網(wǎng)關，網(wǎng)關再返回給用戶

注意點

• 增加了網(wǎng)關，多了一層轉發(fā)（原本用戶請求直接訪問open-service即可），性能會下降一些
• 但是下降不大，通常，網(wǎng)關機器性能會很好，而且網(wǎng)關與open-service的訪問通常是內(nèi)網(wǎng)訪問，速度很快；
• 網(wǎng)關的單點問題：在整個網(wǎng)絡調(diào)用過程中，一定會有一個單點，可能是網(wǎng)關、nginx、DNS服務器等。
• 防止網(wǎng)關單點，可以在網(wǎng)關層前邊再掛一臺nginx，nginx的性能極高，基本不會掛，這樣之后，網(wǎng)關服務就可以不斷的添加機器。但是這樣一個請求就轉發(fā)了兩次，所以最好的方式是網(wǎng)關單點服務部署在一臺牛逼的機器上（通過壓測來估算機器的配置）
• 網(wǎng)關要盡量輕量級。

Part5微服務的服務注冊和發(fā)現(xiàn)

11為什么需要服務注冊？

• 微服務架構中，一般集群都會部署很多個微服務節(jié)點。這些節(jié)點一般也具備這2種角色，稱為：“服務的提供者” 和 “服務的消費者”
• “服務消費者”需要調(diào)用“服務提供者”的API來獲得服務。當“服務提供者”的節(jié)點有增加或減少的時候，也得讓調(diào)用者（“服務消費者”）及時的知曉。
• 在大規(guī)模集群中，一般節(jié)點數(shù)目都很多，節(jié)點變化頻繁，通過手動去維護這些節(jié)點的狀態(tài)是不現(xiàn)實的，因此需要一個叫做“服務注冊中心”的組件來實現(xiàn)。
• “服務提供者”將自己的服務地址等信息登記到“服務注冊中心”中，調(diào)用者（“服務消費者”）需要的時候，每次都先去“服務注冊中心”查詢即可。既解決了人工維護微服務節(jié)點狀態(tài)的問題，也能解決多節(jié)點間負載均衡的問題。

12服務注冊原理

• 在分析其原理之前，我們先來看一下這里包含的一些角色，有三類：“服務提供者”、“服務消費者”、“服務注冊中心”。
• 其中“服務提供者”需要將自己的服務信息注冊到“服務注冊中心”里面。而“服務消費者”需要到“服務注冊中心”里面去查詢有哪些服務可以調(diào)用。

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

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

1.服務自己注冊

• 自己注冊就是指微服務節(jié)點在啟動的時候，自己去服務注冊中心登記注冊了，把自己的信息和狀態(tài)傳過去。
• 這種方式整體結構比較簡單，對于注冊中心而言也比較省事，但是對于微服務節(jié)點而言，每個微服務都得包含這么一段注冊的邏輯代碼，架構上看起來不是很優(yōu)美。

 

自己注冊服務

2.第三方注冊

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

 

第三方注冊

角度二：“服務消費者”向“服務注冊中心”查詢和調(diào)用服務

1.客戶端模式

 

client

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

2.代理模式

 

代理模式

• 在代理模式下，“服務消費者”（圖中的Client）與 微服務、“服務注冊中心”中間有一個 API Gateway組件相隔著。
• “服務消費者”只管去找API Gateway訪問即可。至于去注冊中心查詢服務地址，以及訪問服務地址的動作都由API Gateway效勞了，最后API Gateway在把結果返回給“服務消費者”即可。
• 這種模式，看起來“服務消費者”省事了，但是API Gateway模塊卻復雜了，因為API Gateway就是整個系統(tǒng)的一個非常核心關鍵節(jié)點了，不僅需要保障自己的穩(wěn)定性和性能，而且還需要處理一些負載均衡的邏輯。
• 在大型架構中，這種模式用的還比較多，原理就是在網(wǎng)關加上了網(wǎng)關服務注冊和發(fā)現(xiàn)的邏輯。

13開源的服務注冊發(fā)現(xiàn)框架

Eureka

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

 

Eureka

• 從圖中可以看到，我們的服務（圖中Application Clinet與Application Service）要使用Eureka就需要集成它的SDK（圖中Eureka Client）。
• 圖中的Eureka部署在了三個異地機房，也就是說Eureka是支持多中心部署的。
• 服務提供者（Application Service）通過Eureka Client實現(xiàn)服務的注冊、更新和注銷等。服務消費者（Application Clinet）通過Eureka Client實現(xiàn)服務的查詢和調(diào)用。
• Eureka支持了與Spring Cloud的集成，所以使用起來也非常方便，目前屬于比較流行的方案。

Consul

• Consul是在服務外進行完成一系列動作的，也就是說并不需要服務節(jié)點去依賴它的SDK，沒有侵入性，所以跨語言的解決能力更強一些。
• 它一般是在服務節(jié)點外通過一些探針的方法去檢查應用是否存活，是否需要注冊或注銷。
• Consul也支持Spring Cloud集成，所以使用起來也很方便，也屬于比較流行的方案。

 

Consul

Etcd

• etcd是可通過HTTP訪問的鍵/值存儲。它是分布式的，具有可用于構建服務發(fā)現(xiàn)的分層配置系統(tǒng)。
• 它易于部署，設置和使用，提供可靠的數(shù)據(jù)持久性，安全性和非常好的文檔。
• 由于其簡單性，etcd是比Zookeeper更好的選擇。但是，它需要與少數(shù)第三方工具結合才能提供服務發(fā)現(xiàn)目標。

Part6微服務配置中心

14什么是配置中心？

• 「配置中心」，顧名思義，就是用來統(tǒng)一管理項目中所有配置的系統(tǒng)。
• 如果一個中型互聯(lián)網(wǎng)項目，不采用配置中心的模式，一大堆的各類配置項，各種不定時的修改需求，管理起來會十分混亂。
• 現(xiàn)在的服務都是集群模式，如果每臺服務器都需要手動去更新，工作量可謂是遞增

15為什么需要配置中心？

傳統(tǒng)項目中，我們是怎么處理各類配置參數(shù)問題的：

1.一般是靜態(tài)化配置

• 大多數(shù)在項目中單獨寫一個配置文件，例如 "config.yaml"，然后將各類參數(shù)配置、應用配置、環(huán)境配置、安全配置、業(yè)務配置 都寫到這個文件里。
• 當項目代碼邏輯中需要使用配置的時候，就從這個配置文件中讀取。
• 這種做法雖然簡單，但如果參數(shù)需要修改，就非常的不靈活，甚至需要重啟運行中的項目才能生效。

2.配置文件無法區(qū)分環(huán)境

• 由于配置文件是放在項目中的，但是我們項目可能會有多個環(huán)境，例如：測試環(huán)境、預發(fā)布環(huán)境、生產(chǎn)環(huán)境。
• 每一個環(huán)境所使用的配置參數(shù)理論上都是不同的，所以我們在配置文件中根據(jù)不同環(huán)境配置不同的參數(shù)，這些都是手動維護，在項目發(fā)布的時候，極其容易因開發(fā)人員的失誤導致出錯。

3.配置文件過于分散

• 如果一個項目中存在多個邏輯模塊獨立部署，每個模塊所使用的配置內(nèi)容又不相同.
• 傳統(tǒng)的做法是會在每一個模塊中都放一個配置文件，甚至不同模塊的配置文件格式還不一樣。
• 那么長期的結果就是配置文件過于分散混亂，難以管理。

4.配置修改無法追溯

• 因為采用的靜態(tài)配置文件方式，所以當配置進行修改之后，不容易形成記錄，更無法追溯是誰修改的、修改時間是什么、修改前是什么內(nèi)容。
• 既然無法追溯，那么當配置出錯時，更沒辦法回滾配置了。

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

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

• 「配置中心」的思路就是把項目中各種配置、各種參數(shù)、各種開關，全部都放到一個集中的地方進行統(tǒng)一管理，并提供一套標準的接口。
• 當各個服務需要獲取配置的時候，就來「配置中心」的接口拉取。
• 當「配置中心」中的各種參數(shù)有更新的時候，也能通知到各個服務實時的過來同步最新的信息，使之動態(tài)更新。

16配置中心的特點

• 配置集中管理、統(tǒng)一標準
• 配置與應用分離
• 實時更新
• 高可用

那么，具有上述特性的「配置中心」是如何解決上面?zhèn)鹘y(tǒng)配置所面臨的問題的呢？

• 解決傳統(tǒng)的“配置文件過于分散”的問題 ：采用“配置集中管理”，所有的配置都集中在配置中心這一個地方管理，不需要每一個項目都自帶一個，這樣極大的減輕了開發(fā)成本。
• 解決傳統(tǒng)的“配置文件無法區(qū)分環(huán)境”的問題 ：采用“配置與應用分離”，配置并不跟著環(huán)境走，當不同環(huán)境有不同需求的時候，就到配置中心獲取即可，極大的減輕了運維部署成本。
• 解決傳統(tǒng)的“靜態(tài)化配置”的問題 ：具備“實時更新”的功能，線上系統(tǒng)需要調(diào)整參數(shù)的時候，只需要在配置中心動態(tài)修改即可。
• 解決傳統(tǒng)的“配置修改無法追溯”的問題 ：配置統(tǒng)一管理，并且會記錄每一次修改的版本，通過修改版本可以追蹤歷史修改記錄。
• 既然配置都統(tǒng)一管理了，那配置中心在整個系統(tǒng)中的地位就非常重要了，一旦配置中心不能正常提供服務，就可能會導致項目整體故障，因此“高可用”就是配置中心又一個很關鍵的指標。

17開源的配置中心方案

Apollo

• Apollo（阿波羅）是攜程框架部門研發(fā)的分布式配置中心，能夠集中化管理應用不同環(huán)境、不同集群的配置
• 配置修改后能夠實時推送到應用端，并且具備規(guī)范的權限、流程治理等特性，適用于微服務配置管理場景。
• 服務端基于Spring Boot和Spring Cloud開發(fā)，不依賴外部容器，便于部署。
• Java客戶端不依賴任何框架，能夠運行于所有Java運行時環(huán)境，同時對Spring/Spring Boot環(huán)境也有額外支持。
• 原生支持Java和.Net客戶端，同時也支持其他語言客戶端，目前已支持Go、php、Python/ target=_blank class=infotextkey>Python、NodeJS、C++。

 

apollo

Apollo項目的Github地址

XDiamond

• 全局配置中心，存儲應用的配置項，解決配置混亂分散的問題。
• 名字來源于淘寶的開源項目Diamond，前面加上一個字母X以示區(qū)別。

XDiamond項目的Github地址

Qconf

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

Qconf項目的Github地址

Disconf

• 專注于各種「分布式系統(tǒng)配置管理」的「通用組件」和「通用平臺」,
• 提供統(tǒng)一的「配置管理服務」包括 百度、滴滴出行、銀聯(lián)、網(wǎng)易、拉勾網(wǎng)、蘇寧易購、順豐科技 等知名互聯(lián)網(wǎng)公司正在使用!

Disconf項目的Github地址

Part7總結

• 以上主要總結了單點結構和微服務結構的區(qū)別和特點
• 然后介紹了微服務架構的網(wǎng)關設計、服務注冊和發(fā)現(xiàn)、分布式配置中心的內(nèi)容
• 微服務要探索的內(nèi)容還有：服務框架、服務監(jiān)控、服務治理、服務熔斷、服務降級等等