一、微服務框架：
1.Dubbo
基於Java的高效能 RPC 分散式服務框架
2.Spring Cloud
“全家桶”，因其具備微服務架構體系中所需的各個服務元件，
比如服務註冊發現(如Spring Cloud Eureka、Zookeeper、Consul)、API閘道器路由服務(Spring Cloud Zuul)，客戶端負載均衡(Spring Cloud Ribbon，Zuul預設整合了Ribbon)、服務容錯保護(Spring Cloud Hystrix)，訊息匯流排 (Spring Cloud Bus)、分散式配置中心(Spring Cloud Config)、訊息驅動的微服務(Spring Cloud Stream)、分散式鏈路跟蹤服務(Spring Cloud Sleuth)。
3.比較
使用Dubbo構建的微服務架構就像組裝電腦，各個環節的可選自由度很高，但是最終結果很有可能因為一條記憶體質量不行就點不亮了，但是如果是一個高手，這一切都不存在問題；
使用Spring Cloud就像品牌機，在Spring Source的整合下，做了大量相容性的測試，保證了機器擁有更高的穩定性，但是如果要在使用非原裝元件外配件時，需要對配件足夠的瞭解。
二、配置中心
1.原理
a.配置實時生效：
傳統的靜態配置方式要想修改某個配置只能修改之後重新發布應用，要實現動態性，可以選擇使用資料庫或配置檔案；
配置中心專門針對這個業務場景，兼顧實時性和一致性來管理動態配置。
b.配置管理流程：
配置的許可權管控、灰度釋出、版本管理&回滾、配置格式檢驗、安全配置、多環境、多叢集等一系列的配置管理。
2.主流分散式配置中心框架：
Spring Cloud Config 依賴git，儲存在git
Apollo 攜程開源的配置管理中心，儲存在mysql
Nacos 阿里開源，儲存在mysql
三、註冊中心
1.原理：
a.註冊中心可以說是微服務架構中的”通訊錄“，它記錄了服務和服務地址的對映關係。
在分散式架構中，服務會註冊到這裡，當服務需要呼叫其它服務時，就這裡找到服務的地址，進行呼叫。
服務提供者、服務消費者、註冊中心
各個微服務在啟動時，將自己的網路地址等資訊註冊到註冊中心，註冊中心儲存這些資料。
服務消費者從註冊中心查詢服務提供者的地址，並透過該地址呼叫服務提供者的介面。
微服務網路地址傳送變化（例如例項增加或IP變動等）時，會重新註冊到註冊中心。這樣，服務消費者就無需人工修改提供者的網路地址了。
服務的註冊與發現：服務註冊是指微服務在啟動時，將自己的資訊註冊到註冊中心的過程；服務發現是指查詢可用的微服務列表及網路地址的機制。
b.註冊中心解決了服務之間的自動發現。
在沒有註冊中心時候，服務間呼叫需要知道被調方的地址或者代理地址。當服務更換部署地址，就不得不修改呼叫當中指定的地址或者修改代理配置。
而有了註冊中心之後，每個服務在呼叫別人的時候只需要知道服務名稱就好，修改地址都會透過註冊中心同步過來。
2.主流分散式註冊中心框架：
Eureka AP
Zookeeper CP
Nacos AP
補充：
CAP原則：指的是在一個分散式系統中，
一致性（Consistency） 寫操作之後的讀操作，必須返回該值
可用性（Availability） 只要收到使用者的請求，伺服器就必須給出回應。
分割槽容錯性（Partition tolerance） 大多數分散式系統都分佈在多個子網路。每個子網路就叫做一個區，區間通訊可能失敗
這三個要素最多隻能同時實現兩點，不可能三者兼顧。
四、API閘道器路由服務
1.作用
主要是限流、認證鑑權（過濾器）、路由轉發
路由轉發：路由id（註冊服務的id）、uri路徑、判定器、過濾器，可以寫在配置檔案中，或者存在表中
2.技術
nginx 是一個高效能的HTTP和反向代理web伺服器，同時也提供了IMAP/POP3/SMTP服務；
Spring Cloud Zuul 是Netflix出品的一個基於JVM路由和服務端的負載均衡器；
Spring Cloud gateway 是spring出品的基於spring的閘道器專案，整合斷路器，路徑重寫，效能比Zuul好；
五、客戶端負載均衡
ribbo