1 註冊中心
1.1 為什麼要用註冊中心
微服務之間會相互呼叫，假如有兩個服務orderService和userService，orderService會呼叫userService獲取當前訂單相關的使用者資訊，且userService部署了多個例項：
大家思考幾個問題：
- order-service在發起遠端呼叫的時候，該如何得知user-service例項的ip地址和埠？如果程式碼裡寫死ip地址，一旦發生變化怎麼辦？
- 有多個user-service例項地址，order-service呼叫時該如何選擇？
- order-service如何得知某個user-service例項是否依然健康，是不是已經當機？
這些都可以透過註冊中心來解決
1.2 註冊中心的作用
以eureka註冊中心為例。
回答之前的各個問題。
問題1：order-service如何得知user-service例項地址？
獲取地址資訊的流程如下：
- user-service服務例項啟動後，將自己的資訊註冊到註冊中心（Eureka服務端）。這個叫
服務註冊 - eureka-server儲存服務名稱到服務例項地址列表的對映關係，因此我們呼叫的時候，不用採用ip+埠的方式，直接透過服務名稱呼叫。
- order-service根據服務名稱，拉取例項地址列表。這個叫
服務發現或服務拉取。
問題2：order-service如何從多個user-service例項中選擇具體的例項？
- order-service從例項列表中利用
負載均衡演算法選中一個例項地址 - 向該例項地址發起遠端呼叫
問題3：order-service如何得知某個user-service例項是否依然健康，是不是已經當機？
- user-service會每隔一段時間（預設30秒）向註冊中心發起請求，報告自己狀態，稱為
心跳 - 當超過一定時間沒有傳送心跳時，註冊中心會認為微服務例項故障，將該例項從服務列表中剔除
- order-service拉取服務時，就能將故障例項排除了
總結：註冊中心的作用
- 服務註冊：服務提供方將自身路由資訊釋出到註冊中心，供消費方獲取，用於與提供方建立連線併發起呼叫。
- 服務發現：服務消費方透過註冊中心獲取服務提供方節點路由資訊。
- 確保已註冊節點健康度，能夠及時準確剔除失效節點，保證服務發現正確性
- 變更通知：提供方節點發生變更時，註冊中心應該能夠第一時間把變更事件或變更後的資料推送到服務訂閱方。
1.3 常用註冊中心
詳細對比介紹：https://zhuanlan.zhihu.com/p/63263168
1.4 負載均衡
SpringCloud底層其實是利用了一個名為Ribbon的元件，來實現負載均衡功能的。以此為例進行介紹：
注意，
Spring Cloud 2020.0.0後官方拋棄了 Netflix 技術棧（Spring Cloud Netflix 進入維護模式將不會再向模組新增新功能和版本更新。只修復block級別的bug以及安全問題），Spring Cloud Netflix中的Ribbon此後版本也不再支援，官方推薦使用Spring Cloud Loadbalancer，大家使用高階別版本的SpringCloud服務要注意。
從http://userservice/user/1到http://localhost:8081，具體的實現過程是：
SpringCloudRibbon的底層採用了一個攔截器，攔截了RestTemplate發出的請求，對地址做了修改。
基本流程如下：
-
攔截服務請求方order-service的請求http://userservice/user/1
-
RibbonLoadBalancerClient會從請求url中獲取服務名稱，也就是user-service
-
DynamicServerListLoadBalancer根據user-service到註冊中心拉取服務列表
-
註冊中心返回列表，localhost:8081、localhost:8082
-
IRule利用內建
負載均衡規則，從列表中選擇一個，例如localhost:8081 -
RibbonLoadBalancerClient修改請求地址，用localhost:8081替代userservice，得到http://localhost:8081/user/1，發起真實請求
常用的負載均衡規則：
| 內建負載均衡規則類 | 規則描述 |
|---|---|
| RoundRobinRule | 簡單輪詢服務列表來選擇伺服器。它是Ribbon預設的負載均衡規則。 |
| AvailabilityFilteringRule | 對以下兩種伺服器進行忽略： （1）在預設情況下，這臺伺服器如果3次連線失敗，這臺伺服器就會被設定為“短路”狀態。短路狀態將持續30秒，如果再次連線失敗，短路的持續時間就會幾何級地增加。 （2）併發數過高的伺服器。如果一個伺服器的併發連線數過高，配置了AvailabilityFilteringRule規則的客戶端也會將其忽略。併發連線數的上限，可以由客戶端的 |
| WeightedResponseTimeRule | 為每一個伺服器賦予一個權重值。伺服器響應時間越長，這個伺服器的權重就越小。這個規則會隨機選擇伺服器，這個權重值會影響伺服器的選擇。 |
| ZoneAvoidanceRule | 以區域可用的伺服器為基礎進行伺服器的選擇。使用Zone對伺服器進行分類，這個Zone可以理解為一個機房、一個機架等。而後再對Zone內的多個服務做輪詢。 |
| BestAvailableRule | 忽略那些短路的伺服器，並選擇併發數較低的伺服器。 |
| RandomRule | 隨機選擇一個可用的伺服器。 |
| RetryRule | 重試機制的選擇邏輯 |
1.5 Nacos介紹
Nacos是阿里巴巴的產品，現在是SpringCloud中的一個元件。相比Eureka功能更加豐富，在國內受歡迎程度較高。
Nacos也可以做配置中心。
2 配置中心
2.1 為什麼使用配置中心
微服務架構下關於配置檔案的一些問題：
-
配置檔案相對分散。在一個微服務架構下，配置檔案會隨著微服務的增多變的越來越多，而且分散在各個微服務中，不好統一配置的和管理。
-
配置檔案無法區分環境。微服務專案可能會有多個環境，例如：測試環境，預發環境，生產環境。每一個環境所使用的配置理論上都是不同的，一旦需要修改，就需要我們去各個微服務下手動維護，這比較困難。
-
配置如果在程式碼裡寫死，更新維護比較困難。
-
配置檔案無法實時更新。我們修改了配置檔案之後，必須重新啟動微服務才能使配置生效，這對一個正在執行的專案來說是非常不友好的
2.2 配置中心的作用
配置中心的思路是：
- 配置統一管理：首先把專案中各種配置全部都放到一個集中的地方進行統一管理，並提供一套標準的介面。
- 配置自動拉取：當各個服務需要獲取配置的時候，就來配置中心的介面拉取自己的配置。
- 配置動態更新:當配置中心中的各種引數有更新的時候，也能通知到各個服務實時的過來同步最新的資訊，使之動態更新。
此外，配置中心還有灰度釋出、許可權管理、版本管理&回滾等特點。
2.3 常用配置中心
Apollo
GitHub：https://github.com/apolloconfig/apollo
官方文件：https://www.apolloconfig.com/#/zh/development/apollo-development-guide
Apollo（阿波羅）是攜程框架部門研發的開源配置管理中心，具備規範的許可權、流程治理等特性。
Spring Cloud Config
GitHub：https://github.com/spring-cloud/spring-cloud-config
2014年9月開源，Spring Cloud 生態元件，可以和Spring Cloud體系無縫整合。
Nacos
Nacos官網：https://nacos.io/zh-cn/docs/what-is-nacos.html
2.4 Apollo配置中心
2.4.1 Apollo介紹
Apollo（阿波羅）是一款可靠的分散式配置管理中心，誕生於攜程框架研發部，能夠集中化管理應用不同環境、不同叢集的配置，配置修改後能夠實時推送到應用端，並且具備規範的許可權、流程治理等特性，適用於微服務配置管理場景。
服務端基於Spring Boot和Spring Cloud開發，打包後可以直接執行，不需要額外安裝Tomcat等應用容器。
2.4.2 Apollo特點
- 統一管理不同環境、不同叢集的配置
- Apollo提供了一個統一介面集中式管理不同環境（environment）、不同叢集（cluster）、不同名稱空間（namespace）的配置。
- 同一份程式碼部署在不同的叢集，可以有不同的配置，比如zk的地址等
- 透過名稱空間（namespace）可以很方便的支援多個不同應用共享同一份配置，同時還允許應用對共享的配置進行覆蓋
- 配置介面支援多語言（中文，English）
- 配置修改實時生效（熱釋出）
- 使用者在Apollo修改完配置併發布後，客戶端能實時（1秒）接收到最新的配置，並通知到應用程式。
- 版本釋出管理
- 所有的配置釋出都有版本概念，從而可以方便的支援配置的回滾。
- 灰度釋出
- 支援配置的灰度釋出，比如點了釋出後，只對部分應用例項生效，等觀察一段時間沒問題後再推給所有應用例項。
- 許可權管理、釋出稽核、操作審計
- 應用和配置的管理都有完善的許可權管理機制，對配置的管理還分為了編輯和釋出兩個環節，從而減少人為的錯誤。
- 所有的操作都有審計日誌，可以方便的追蹤問題。
- 客戶端配置資訊監控
- 可以方便的看到配置在被哪些例項使用
2.4.4 Apollo框架
-
使用者在配置中心對配置進行修改併發布
-
配置中心通知Apollo客戶端有配置更新
-
Apollo客戶端從配置中心拉取最新的配置、更新本地配置並通知到應用
- 在遇到服務不可用，或網路不通的時候，依然能從本地恢復配置
下圖是它的所有模組：
- ConfigService
-
- 提供配置獲取、配置推送介面
- 服務於Apollo客戶端
- AdminService
-
- 提供配置管理、配置修改釋出介面
- 服務於管理介面Portal
- Client
-
- 為應用獲取配置，支援實時更新
- 透過MetaServer獲取ConfigService的服務列表
- 使用客戶端軟負載SLB（例如Ribbon）方式呼叫ConfigService
- Portal
-
- 配置管理介面
- 透過MetaServer獲取AdminService的服務列表
- 使用客戶端軟負載SLB方式呼叫AdminService
- Eureka
- 用於服務發現和註冊
- Config/AdminService註冊例項並定期報心跳
- MetaServer
- Portal透過域名訪問MetaServer獲取AdminService的地址列表
- Client透過域名訪問MetaServer獲取ConfigService的地址列表
- 相當於一個Eureka Proxy（Eureka只能部署在java客戶端，為了能部署在多語言環境，攜程做了一個封裝）