個人專題目錄
1、apollo配置中心整體架構(gòu)圖
overall-architecture.png
2、上圖簡要描述了Apollo的總體設計：
- Config Service提供配置的讀取、推送等功能，服務對象是Apollo客戶端
- Admin Service提供配置的修改、發(fā)布等功能，服務對象是Apollo Portal（管理界面）
- Config Service和Admin Service都是多實例、無狀態(tài)部署，所以需要將自己注冊到Eureka中并保持心跳
- 在Eureka之上我們架了一層Meta Server用于封裝Eureka的服務發(fā)現(xiàn)接口
- Client通過域名訪問Meta Server獲取Config Service服務列表（IP+Port），而后直接通過IP+Port訪問服務，同時在Client側(cè)會做load balance、錯誤重試
- Portal通過域名訪問Meta Server獲取Admin Service服務列表（IP+Port），而后直接通過IP+Port訪問服務，同時在Portal側(cè)會做load balance、錯誤重試
- 為了簡化部署，我們實際上會把Config Service、Eureka和Meta Server三個邏輯角色部署在同一個JVM進程中
3、為什么我們采用Eureka作為服務注冊中心
它提供了完整的Service Registry和Service Discovery實現(xiàn)
- 首先是提供了完整的實現(xiàn)，并且也經(jīng)受住了Netflix自己的生產(chǎn)環(huán)境考驗，相對使用起來會比較省心。
- 易于我們的應用程序中嵌入
- 易于使用的Java客戶端集成
- 易用與docker集成
- 高可用性 (HA)
- 簡單
和Spring Cloud無縫集成
- 我們的項目本身就使用了Spring Cloud和Spring Boot，同時Spring Cloud還有一套非常完善的開源代碼來整合Eureka，所以使用起來非常方便。
- 另外，Eureka還支持在我們應用自身的容器中啟動，也就是說我們的應用啟動完之后，既充當了Eureka的角色，同時也是服務的提供者。這樣就極大的提高了服務的可用性。
- 這一點是我們選擇Eureka而不是zk、etcd等的主要原因，為了提高配置中心的可用性和降低部署復雜度，我們需要盡可能地減少外部依賴。
- Open Source
- 最后一點是開源，由于代碼是開源的，所以非常便于我們了解它的實現(xiàn)原理和排查問題。
| Eureka | Zookeeper | Consul | Etcd | |
|---|---|---|---|---|
| 嵌入在應用程序中的能力 | Yes | Difficult | No | No |
| 易于使用的Java客戶端集成 | Yes (Netflix offers an ecosystem with balancer and other features) | Yes | Yes | No |
| 易用與docker集成 | No (Added) | Yes | Yes | Yes |
| 高可用性 (HA) | Yes (AP) | Yes (CP) | Yes (CP) | Yes (CP) |
| 簡單的安裝/維護 | Yes | No | No | Yes |
3.1、為什么要使用服務發(fā)現(xiàn)?
| 名稱 | 特點 | 備注 |
| DNS | 最原始的配置文件和 DNS 來做服務發(fā)現(xiàn)，Host、端口都是寫在配置文件里的，發(fā)生變更的時候只能修改配置文件并重啟服務。所以當某臺機器掛掉的時候，依賴它上面服務的其他系統(tǒng)也都全部會出問題。而應急的步驟都是先在別的機器上運行新的實例，修改配置文件并重啟關聯(lián)的其他系統(tǒng)。這樣做費時、費力、且會有一個時間窗口內(nèi)系統(tǒng)無法提供服務。 | DNS 變更延遲問題 |
| 通過 Nginx 來做了負載均衡/主備的 | 這樣做還是有兩個問題：（1）Nginx 本身成為一個故障點（2）連接數(shù)量翻倍，其中第二個問題曾導致我們的環(huán)境出現(xiàn)了 nf_conntrack table full 的問題。我們的關鍵服務都是多實例負載均衡的，當系統(tǒng)并發(fā)上升到一定程度的時候，某些服務器，尤其是跑著 Nginx 的機器很容易出現(xiàn)這個錯誤。 | 中心化負載均衡，單點問題 |
| zk | 服務實例注冊的 Node 類型是 ephemeral node，這種類型的節(jié)點只有在客戶端保持著連接的時候才有效。所以當某個服務實例被停止或者出現(xiàn)網(wǎng)絡異常的時候，對應的節(jié)點也會被刪掉。因此，任何時候從 ZooKeeper 里查詢到的都是當前活躍的實例。借助 ZooKeeper 的推送功能，服務的消費者可以得知實例的變化，從而可以從容應對服務實例的宕機和新實例的添加，無需重啟。 | zk，多語言問題 |
| etcd | etcd是一個采用HTTP協(xié)議的健/值對存儲系統(tǒng)，它是一個分布式和功能層次配置系統(tǒng)，可用于構(gòu)建服務發(fā)現(xiàn)系統(tǒng)。其很容易部署、安裝和使用，提供了可靠的數(shù)據(jù)持久化特性。它是安全的并且文檔也十分齊全。etcd比Zookeeper是比更好的選擇，因為它很簡單，然而，它需要搭配一些第三方工具才可以提供服務發(fā)現(xiàn)功能。 | coreos開發(fā)，系統(tǒng)級別的 |
consul(go語言寫的) |
Consul是強一致性的數(shù)據(jù)存儲，使用gossip形成動態(tài)集群。它提供分級鍵/值存儲方式，不僅可以存儲數(shù)據(jù)，而且可以用于注冊器件事各種任務，從發(fā)送數(shù)據(jù)改變通知到運行健康檢查和自定義命令，具體如何取決于它們的輸出。與Zookeeper和etcd不一樣，Consul內(nèi)嵌實現(xiàn)了服務發(fā)現(xiàn)系統(tǒng)，所以這樣就不需要構(gòu)建自己的系統(tǒng)或使用第三方系統(tǒng)。這一發(fā)現(xiàn)系統(tǒng)除了上述提到的特性之外，還包括節(jié)點健康檢查和運行在其上的服務。Zookeeper和etcd只提供原始的鍵/值隊存儲，要求應用程序開發(fā)人員構(gòu)建他們自己的系統(tǒng)提供服務發(fā)現(xiàn)功能。而Consul提供了一個內(nèi)置的服務發(fā)現(xiàn)的框架?？蛻糁恍枰苑詹⑼ㄟ^DNS或HTTP接口執(zhí)行服務發(fā)現(xiàn)。其他兩個工具需要一個親手制作的解決方案或借助于第三方工具。Consul為多種數(shù)據(jù)中心提供了開箱即用的原生支持，其中的gossip系統(tǒng)不僅可以工作在同一集群內(nèi)部的各個節(jié)點，而且還可以跨數(shù)據(jù)中心工作。 | |
| Netflix的Eureka方案 | Eureka 由兩個組件組成： Eureka 服務器 和 Eureka 客戶端 。Eureka 服務器用作服務注冊服務器。Eureka 客戶端是一個 java 客戶端，用來簡化與服務器的交互、作為輪詢負載均衡器，并提供服務的故障切換支持。Netflix 在其生產(chǎn)環(huán)境中使用的是另外的客戶端，它提供基于流量、資源利用率以及出錯狀態(tài)的加權負載均衡當一個中間層服務首次啟動時，他會將自己注冊到 Eureka 中，以便讓客戶端找到它，同時每 30 秒發(fā)送一次心跳。如果一個服務在幾分鐘內(nèi)沒有發(fā)送心跳，它將從所有 Eureka 節(jié)點上注銷。一個 Amazon 域中可以有一個 Eureka 節(jié)點集群，每個可用區(qū)（Availability Zone）至少有一個 Eureka 節(jié)點。AWS 的域相互之間是隔離的。 |
| 為什么不用zookeeper做服務發(fā)現(xiàn) | 為什么不應該使用ZooKeeper做服務發(fā)現(xiàn) |
|---|---|
| zk是滿足CP犧牲A，這個不對，看ZooKeeper和CAP理論及一致性原則 ，其實zk只是滿足最終一致性C，可用性A這個是保證的，并且保證一半的節(jié)點是最新的數(shù)據(jù)，分區(qū)性P這個得看節(jié)點多少及讀寫情況，節(jié)點多，則寫耗時長，另外節(jié)點多了Leader選舉非常耗時, 就會放大網(wǎng)絡的問題，容易分區(qū)。 對于Service發(fā)現(xiàn)服務而言，寧可返回某服務5分鐘之前在哪幾個服務器上可用的信息，也不能因為暫時的網(wǎng)絡故障而找不到可用的服務器，而不返回任何結(jié)果。所以說，用ZooKeeper來做Service發(fā)現(xiàn)服務是肯定錯誤的?？偨Y(jié)一句就是，service不是強一致的，所以會有部分情況下沒發(fā)現(xiàn)新服務導致請求出錯。當部分或者所有節(jié)點跟ZooKeeper斷開的情況下，每個節(jié)點還可以從本地緩存中獲取到數(shù)據(jù)；但是，即便如此，ZooKeeper下所有節(jié)點不可能保證任何時候都能緩存所有的服務注冊信息。如果ZooKeeper下所有節(jié)點都斷開了，或者集群中出現(xiàn)了網(wǎng)絡分割的故障（注：由于交換機故障導致交換機底下的子網(wǎng)間不能互訪）；那么ZooKeeper會將它們都從自己管理范圍中剔除出去，外界就不能訪問到這些節(jié)點了，即便這些節(jié)點本身是“健康”的，可以正常提供服務的；所以導致到達這些節(jié)點的服務請求被丟失了。 | Eureka處理網(wǎng)絡問題導致分區(qū)。如果Eureka服務節(jié)點在短時間里丟失了大量的心跳連接（注：可能發(fā)生了網(wǎng)絡故障），那么這個Eureka節(jié)點會進入”自我保護模式“，同時保留那些“心跳死亡“的服務注冊信息不過期。此時，這個Eureka節(jié)點對于新的服務還能提供注冊服務，對于”死亡“的仍然保留，以防還有客戶端向其發(fā)起請求。當網(wǎng)絡故障恢復后，這個Eureka節(jié)點會退出”自我保護模式“。所以Eureka的哲學是，同時保留”好數(shù)據(jù)“與”壞數(shù)據(jù)“總比丟掉任何”好數(shù)據(jù)“要更好，所以這種模式在實踐中非常有效。 Eureka就是為發(fā)現(xiàn)服務所設計的，它有獨立的客戶端程序庫，同時提供心跳服務、服務健康監(jiān)測、自動發(fā)布服務與自動刷新緩存的功能。但是，如果使用ZooKeeper你必須自己來實現(xiàn)這些功能。 |
4、spring cloud架構(gòu)簡介：
4.1、spring cloud config 講解
01.png
4.2、spring cloud eureka講解
preview
- Service Provider會向Eureka Server做Register（服務注冊）、Renew（服務續(xù)約）、Cancel（服務下線）等操作。
- Eureka Server之間會做注冊服務的同步，從而保證狀態(tài)一致
- Service Consumer會向Eureka Server獲取注冊服務列表，并消費服務
5、CAP理論圖解
02.png
CAP理論的核心是：一個分布式系統(tǒng)不可能同時很好的滿足一致性，可用性和分區(qū)容錯性這三個需求，最多只能同時較好的滿足兩個。
因此，根據(jù)CAP原理將NoSQL數(shù)據(jù)庫分成了滿足CA原則 、滿足CP原則和滿足AP原則三大類：
CA- 單點集群，滿足一致性，可用性的系統(tǒng)，通常在可擴展性上不太強大。
CP-滿足一致性，分區(qū)容忍性的系統(tǒng)，通常性能不是特別高。
AP-滿足可用性，分區(qū)容忍性的系統(tǒng)，通常可能對一致性要求低一點。
