分散式
CAP
C：consistency 一致性 分散式系統能夠同時訪問同一份資料副本
A：availability 可用性 非故障節點能夠在合理時間內獲得合理的結果
P：Partition Tolerance 分割槽容錯性 分散式系統當發生網路分割槽時，服務仍然可用
網路分割槽：分散式網路中，由於某些節點故障，導致系統分成了幾個區域。比如呼叫鏈A->B->C，其中B節點故障，那麼A，B分成了兩個分割槽。
而是在P為條件下，只能實現A或者C。也就是說，在發生網路分割槽後，我們只能保證一致性或者可用性。
當沒有發生網路分割槽時，也就是沒有P為條件，那麼自然可以同時滿足A和C。
zookeeper：保證CP，zookeeper有leader節點，寫操作只能由leader來做，Follower只能處理讀操作，這樣就保證資料的一致性。
Eureka：保證AP，Eureka各個伺服器節點都是平等的，只要有至少一個節點，就能夠保證可用。
Nacos：保證AP和CP，預設支援AP，通過命令進行切換為CP。
BASE理論
-
基本可用（Basically Available）
當系統發生不可預知的故障時，允許損失部分可用性。
- 響應時間的損失：原先0.5s就能返回的結果，允許2s內返回
- 系統功能的損失：可以損失非核心功能，而保證核心功能的可用
-
軟狀態（Soft State）
允許存在中間狀態，允許在多個節點的資料副本存在時延
-
最終一致性（Eventually Consistent）
在一個時間期限後，要保證資料的最終一致性
分散式ID
對於單個資料庫我們使用id自增就能保證，id不重複。
對於兩個資料庫，我們分別設定起始值和步長就能避免id重複，但是這時在新增一個資料庫，則要重新修改初始值和步長。
號段模式：我們可以先從資料庫中取出一段資料，比如id為100到200，當需要使用時，在本地直接提取使用，使用完這100個id後，再從資料庫中取200到300的id。
redis：通過redis，在redis中使用incr自增，也能夠保證id的不重複。
雪花演算法：對分散式id的bit進行分配，比如64bit的一個id，從左到右，第一位符號位，接下來41bit為時間戳，接下來10bit為工作機器id，接下來12bit為序列號。這樣就能夠保證id的不重複。
限流演算法
固定視窗計數機演算法
規定一分鐘之內只能有100個請求，如果多了則丟棄該請求。該方法無法防止突增的請求，比如前30秒只有1個請求，後30秒突然進來99個請求，無法保證限流的速率。
滑動視窗計數機演算法
將一分鐘劃分成60個格子，大小為30的視窗不斷移動，每秒的請求放到格子中，如果視窗中的請求超過閾值，就不再處理其他請求。
漏桶演算法
輸出的水流是一定的，這樣就能保證輸出速率穩定。把請求比作水，當請求來時，則將水輸入到水桶上方，即使上方的水是突然激增的，那輸出也仍然是穩定的。如果木桶大小固定，上方水滿了，則水將溢位，也就是說請求丟棄。
缺點是，我們總是以固定的速率流出，我們希望當請求少時，固定速率流出自然沒問題，但是當請求到峰值，我們希望流出速率大一些。
令牌桶演算法
仍然是一個固定大小的桶，我們以固定速率生產令牌，當請求來時，對於大的請求，消耗多點的令牌，小請求就少點令牌。如果桶內令牌沒有了，則丟棄請求。這個演算法就能解決動態去做“流出速率”，峰值時流出速度快，平時呢流出速率平穩。
RPC
做為遠端呼叫框架，目的是希望呼叫遠端方法就像本地方法一樣簡單。
客戶端：通過簡單註解或者使用類呼叫遠端方法
客戶端代理類：通過動態代理，讓客戶端執行的方法最終讓代理類來執行。代理類拿到服務名/方法名，引數等資訊封裝到request中，然後通過網路呼叫傳送給服務端
網路呼叫：最簡單的可以用socket，當然netty更流行，編寫Netty的客戶端與服務端
服務端：Netty中拿到request，知道了方法名，可以通過反射建立實現了該方法的類，然後呼叫之，得到結果後，再通過Netty服務端傳送給客戶端
註冊中心：我們可以用zk，建立節點，節點為服務名，節點下資料為機器ip地址。服務端啟動時，首先將自己能夠提供的服務註冊到zk上。客戶端根據服務名從zk中找到具體的ip地址，然後根據ip地址傳送訪問。
閘道器
微服務下多個服務，對於許可權管理，流量控制，日誌，監控等和業務無關的東西提取出來，統一管理，因此就有閘道器。
閘道器可以做：鑑權，限流，請求路由，日誌，監控。
微服務
服務註冊與發現：Eureka，nacos
微服務有很多消費者，提供者，我們不希望將他們之間的呼叫寫死，因為針對某個服務，可能有多個機器去執行他，那麼我們希望有一個人能夠統一管理，那麼註冊中心可以解決我們的問題。服務提供者將自己的服務註冊到註冊中心，消費者只需根據服務名從註冊中心拿到提供者地址。並且對於閘道器，負載均衡，熔斷降級，訊息佇列等等元件，他們都希望自己能夠獲得註冊在註冊中心的某些資訊，從而進行操作。
比如監控功能，就需要拿到註冊中心的所有提供者消費者資訊，來判斷他們的健康情況。
總之，註冊中心統一對服務的管理，當我們需要使用或者檢視這些服務狀態時，只需訪問註冊中心即可。
負載均衡：Ribbon
nacos自己整合了Ribbon，要使用負載均衡，首先我們要講restTemplate通過@Bean註解註冊到spring中，然後或者使用註解，或者通過程式碼指定負載均衡策略即可，然後呼叫restTemplate.getForObject或者restTemplate.postForObject即可呼叫另一個服務的方法。
Openfeign：有人覺得直接寫restTemplate.postForObject，這樣不美觀，我就是想呼叫另一個服務就跟呼叫本地方法一樣，那麼這個Openfeign就可以幫助我們。我們寫一個介面，介面中方法指明另一個服務的介面，然後我們在controller呼叫的時候，加個註解，直接呼叫介面的方法，看起來多像在本地呼叫方法啊！
熔斷和降級：Hystrix，sentinel
當服務呼叫鏈路A->B->C，其中服務C發生故障，導致B有大量請求堆積，最終耗盡B的所有資源，B掛掉，然後A也堆積大量請求，A也掛掉，這就是服務雪崩。
為了防止服務雪崩，我們需要熔斷器，當某個服務故障時，切斷呼叫鏈路，告知上一個服務，當前服務已經故障了。
服務降級，比如某服務訪問量過大，我們一次處理不了那麼多請求，我們可以做服務降級。比如突然有1000訂單，我們一下子處理不了，那麼我們可以讓一部分請求走降級，返回稍後重試的提示資訊。
sentinel不僅僅有熔斷降級等功能，他還提供了多種其他功能，如限流，負載保護，實時監控，呼叫鏈路等。
閘道器：gateway，zuul
閘道器可以做路由對映，過濾器。
鏈路跟蹤：zipkin
每個服務是一個圓點，服務呼叫之間有連線，做出來的效果，真好看。。。?