一文吃透何為微服務、網關、服務發現/注冊？

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

歡迎關注公眾號"Java學習之道"，查看更多干貨！

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 全家桶中了，使用起來非常方便。

請求過程

• 首先將請求給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）在向“服務注冊中心”查詢到自己需要調用的“服務提供者”的地址
• “服務消費者”（客戶端）就會自己根據查詢到的地址去訪問微服務（圖中的第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開源，其架構如下圖：

• 從圖中可以看到，我們的服務（圖中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集成，所以使用起來也很方便，也屬于比較流行的方案。

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項目的Github地址

XDiamond

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

XDiamond項目的Github地址

Qconf

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

Qconf項目的Github地址

Disconf

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

Disconf項目的Github地址

Part7總結

• 以上主要總結了單點結構和微服務結構的區別和特點
• 然后介紹了微服務架構的網關設計、服務注冊和發現、分布式配置中心的內容
• 微服務要探索的內容還有：服務框架、服務監控、服務治理、服務熔斷、服務降級等等