個人專題目錄
1父叙、apollo配置中心整體架構(gòu)圖
overall-architecture.png
2、上圖簡要描述了Apollo的總體設(shè)計：
- Config Service提供配置的讀取讥裤、推送等功能，服務(wù)對象是Apollo客戶端
- Admin Service提供配置的修改姻报、發(fā)布等功能己英，服務(wù)對象是Apollo Portal（管理界面）
- Config Service和Admin Service都是多實例、無狀態(tài)部署吴旋，所以需要將自己注冊到Eureka中并保持心跳
- 在Eureka之上我們架了一層Meta Server用于封裝Eureka的服務(wù)發(fā)現(xiàn)接口
- Client通過域名訪問Meta Server獲取Config Service服務(wù)列表（IP+Port）损肛，而后直接通過IP+Port訪問服務(wù)，同時在Client側(cè)會做load balance邮府、錯誤重試
- Portal通過域名訪問Meta Server獲取Admin Service服務(wù)列表（IP+Port）荧关，而后直接通過IP+Port訪問服務(wù)，同時在Portal側(cè)會做load balance褂傀、錯誤重試
- 為了簡化部署忍啤，我們實際上會把Config Service、Eureka和Meta Server三個邏輯角色部署在同一個JVM進程中
3仙辟、為什么我們采用Eureka作為服務(wù)注冊中心
它提供了完整的Service Registry和Service Discovery實現(xiàn)
- 首先是提供了完整的實現(xiàn)同波，并且也經(jīng)受住了Netflix自己的生產(chǎn)環(huán)境考驗，相對使用起來會比較省心叠国。
- 易于我們的應(yīng)用程序中嵌入
- 易于使用的Java客戶端集成
- 易用與docker集成
- 高可用性 (HA)
- 簡單
和Spring Cloud無縫集成
- 我們的項目本身就使用了Spring Cloud和Spring Boot未檩，同時Spring Cloud還有一套非常完善的開源代碼來整合Eureka，所以使用起來非常方便粟焊。
- 另外冤狡，Eureka還支持在我們應(yīng)用自身的容器中啟動，也就是說我們的應(yīng)用啟動完之后项棠，既充當(dāng)了Eureka的角色悲雳，同時也是服務(wù)的提供者。這樣就極大的提高了服務(wù)的可用性香追。
- 這一點是我們選擇Eureka而不是zk合瓢、etcd等的主要原因，為了提高配置中心的可用性和降低部署復(fù)雜度透典，我們需要盡可能地減少外部依賴晴楔。
- Open Source
- 最后一點是開源顿苇，由于代碼是開源的，所以非常便于我們了解它的實現(xiàn)原理和排查問題税弃。
| Eureka | Zookeeper | Consul | Etcd | |
|---|---|---|---|---|
| 嵌入在應(yīng)用程序中的能力 | 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纪岁、為什么要使用服務(wù)發(fā)現(xiàn)?
微服務(wù)系統(tǒng)中的服務(wù)發(fā)現(xiàn)機制
| 名稱 | 特點 | 備注 |
| DNS | 最原始的配置文件和 DNS 來做服務(wù)發(fā)現(xiàn)，Host钙皮、端口都是寫在配置文件里的蜂科，發(fā)生變更的時候只能修改配置文件并重啟服務(wù)顽决。所以當(dāng)某臺機器掛掉的時候短条，依賴它上面服務(wù)的其他系統(tǒng)也都全部會出問題。而應(yīng)急的步驟都是先在別的機器上運行新的實例才菠，修改配置文件并重啟關(guān)聯(lián)的其他系統(tǒng)茸时。這樣做費時、費力赋访、且會有一個時間窗口內(nèi)系統(tǒng)無法提供服務(wù)可都。 | DNS 變更延遲問題 |
| 通過 Nginx 來做了負載均衡/主備的 | 這樣做還是有兩個問題：（1）Nginx 本身成為一個故障點（2）連接數(shù)量翻倍，其中第二個問題曾導(dǎo)致我們的環(huán)境出現(xiàn)了 nf_conntrack table full 的問題蚓耽。我們的關(guān)鍵服務(wù)都是多實例負載均衡的渠牲，當(dāng)系統(tǒng)并發(fā)上升到一定程度的時候，某些服務(wù)器步悠，尤其是跑著 Nginx 的機器很容易出現(xiàn)這個錯誤签杈。 | 中心化負載均衡，單點問題 |
| zk | 服務(wù)實例注冊的 Node 類型是 ephemeral node鼎兽，這種類型的節(jié)點只有在客戶端保持著連接的時候才有效答姥。所以當(dāng)某個服務(wù)實例被停止或者出現(xiàn)網(wǎng)絡(luò)異常的時候，對應(yīng)的節(jié)點也會被刪掉谚咬。因此鹦付，任何時候從 ZooKeeper 里查詢到的都是當(dāng)前活躍的實例。借助 ZooKeeper 的推送功能择卦，服務(wù)的消費者可以得知實例的變化敲长，從而可以從容應(yīng)對服務(wù)實例的宕機和新實例的添加，無需重啟秉继。 | zk祈噪，多語言問題 |
| etcd | etcd是一個采用HTTP協(xié)議的健/值對存儲系統(tǒng)，它是一個分布式和功能層次配置系統(tǒng)秕噪，可用于構(gòu)建服務(wù)發(fā)現(xiàn)系統(tǒng)钳降。其很容易部署、安裝和使用腌巾，提供了可靠的數(shù)據(jù)持久化特性遂填。它是安全的并且文檔也十分齊全铲觉。etcd比Zookeeper是比更好的選擇，因為它很簡單吓坚，然而撵幽，它需要搭配一些第三方工具才可以提供服務(wù)發(fā)現(xiàn)功能。 | coreos開發(fā)礁击，系統(tǒng)級別的 |
consul(go語言寫的) |
Consul是強一致性的數(shù)據(jù)存儲盐杂，使用gossip形成動態(tài)集群。它提供分級鍵/值存儲方式哆窿，不僅可以存儲數(shù)據(jù)链烈，而且可以用于注冊器件事各種任務(wù)，從發(fā)送數(shù)據(jù)改變通知到運行健康檢查和自定義命令挚躯，具體如何取決于它們的輸出强衡。與Zookeeper和etcd不一樣，Consul內(nèi)嵌實現(xiàn)了服務(wù)發(fā)現(xiàn)系統(tǒng)码荔，所以這樣就不需要構(gòu)建自己的系統(tǒng)或使用第三方系統(tǒng)漩勤。這一發(fā)現(xiàn)系統(tǒng)除了上述提到的特性之外，還包括節(jié)點健康檢查和運行在其上的服務(wù)缩搅。Zookeeper和etcd只提供原始的鍵/值隊存儲越败，要求應(yīng)用程序開發(fā)人員構(gòu)建他們自己的系統(tǒng)提供服務(wù)發(fā)現(xiàn)功能。而Consul提供了一個內(nèi)置的服務(wù)發(fā)現(xiàn)的框架硼瓣【糠桑客戶只需要注冊服務(wù)并通過DNS或HTTP接口執(zhí)行服務(wù)發(fā)現(xiàn)。其他兩個工具需要一個親手制作的解決方案或借助于第三方工具巨双。Consul為多種數(shù)據(jù)中心提供了開箱即用的原生支持噪猾，其中的gossip系統(tǒng)不僅可以工作在同一集群內(nèi)部的各個節(jié)點，而且還可以跨數(shù)據(jù)中心工作筑累。 | |
| Netflix的Eureka方案 | Eureka 由兩個組件組成： Eureka 服務(wù)器 和 Eureka 客戶端 袱蜡。Eureka 服務(wù)器用作服務(wù)注冊服務(wù)器。Eureka 客戶端是一個 java 客戶端慢宗，用來簡化與服務(wù)器的交互坪蚁、作為輪詢負載均衡器，并提供服務(wù)的故障切換支持镜沽。Netflix 在其生產(chǎn)環(huán)境中使用的是另外的客戶端敏晤，它提供基于流量、資源利用率以及出錯狀態(tài)的加權(quán)負載均衡當(dāng)一個中間層服務(wù)首次啟動時缅茉，他會將自己注冊到 Eureka 中嘴脾，以便讓客戶端找到它，同時每 30 秒發(fā)送一次心跳。如果一個服務(wù)在幾分鐘內(nèi)沒有發(fā)送心跳译打，它將從所有 Eureka 節(jié)點上注銷耗拓。一個 Amazon 域中可以有一個 Eureka 節(jié)點集群，每個可用區(qū)（Availability Zone）至少有一個 Eureka 節(jié)點奏司。AWS 的域相互之間是隔離的乔询。 |
| 為什么不用zookeeper做服務(wù)發(fā)現(xiàn) | 為什么不應(yīng)該使用ZooKeeper做服務(wù)發(fā)現(xiàn) |
|---|---|
| zk是滿足CP犧牲A，這個不對韵洋，看ZooKeeper和CAP理論及一致性原則 竿刁，其實zk只是滿足最終一致性C，可用性A這個是保證的搪缨，并且保證一半的節(jié)點是最新的數(shù)據(jù)食拜，分區(qū)性P這個得看節(jié)點多少及讀寫情況，節(jié)點多勉吻，則寫耗時長监婶，另外節(jié)點多了Leader選舉非常耗時, 就會放大網(wǎng)絡(luò)的問題，容易分區(qū)齿桃。 對于Service發(fā)現(xiàn)服務(wù)而言，寧可返回某服務(wù)5分鐘之前在哪幾個服務(wù)器上可用的信息煮盼，也不能因為暫時的網(wǎng)絡(luò)故障而找不到可用的服務(wù)器短纵，而不返回任何結(jié)果。所以說僵控，用ZooKeeper來做Service發(fā)現(xiàn)服務(wù)是肯定錯誤的香到。總結(jié)一句就是报破，service不是強一致的悠就，所以會有部分情況下沒發(fā)現(xiàn)新服務(wù)導(dǎo)致請求出錯。當(dāng)部分或者所有節(jié)點跟ZooKeeper斷開的情況下充易，每個節(jié)點還可以從本地緩存中獲取到數(shù)據(jù)梗脾；但是，即便如此盹靴，ZooKeeper下所有節(jié)點不可能保證任何時候都能緩存所有的服務(wù)注冊信息炸茧。如果ZooKeeper下所有節(jié)點都斷開了，或者集群中出現(xiàn)了網(wǎng)絡(luò)分割的故障（注：由于交換機故障導(dǎo)致交換機底下的子網(wǎng)間不能互訪）稿静；那么ZooKeeper會將它們都從自己管理范圍中剔除出去梭冠，外界就不能訪問到這些節(jié)點了，即便這些節(jié)點本身是“健康”的改备，可以正常提供服務(wù)的控漠；所以導(dǎo)致到達這些節(jié)點的服務(wù)請求被丟失了。 | Eureka處理網(wǎng)絡(luò)問題導(dǎo)致分區(qū)悬钳。如果Eureka服務(wù)節(jié)點在短時間里丟失了大量的心跳連接（注：可能發(fā)生了網(wǎng)絡(luò)故障）盐捷，那么這個Eureka節(jié)點會進入”自我保護模式“柬脸，同時保留那些“心跳死亡“的服務(wù)注冊信息不過期。此時毙驯，這個Eureka節(jié)點對于新的服務(wù)還能提供注冊服務(wù)倒堕，對于”死亡“的仍然保留，以防還有客戶端向其發(fā)起請求爆价。當(dāng)網(wǎng)絡(luò)故障恢復(fù)后垦巴，這個Eureka節(jié)點會退出”自我保護模式“。所以Eureka的哲學(xué)是铭段，同時保留”好數(shù)據(jù)“與”壞數(shù)據(jù)“總比丟掉任何”好數(shù)據(jù)“要更好骤宣，所以這種模式在實踐中非常有效。 Eureka就是為發(fā)現(xiàn)服務(wù)所設(shè)計的序愚，它有獨立的客戶端程序庫憔披，同時提供心跳服務(wù)、服務(wù)健康監(jiān)測爸吮、自動發(fā)布服務(wù)與自動刷新緩存的功能芬膝。但是，如果使用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（服務(wù)注冊）癣缅、Renew（服務(wù)續(xù)約）、Cancel（服務(wù)下線）等操作哄酝。
- Eureka Server之間會做注冊服務(wù)的同步友存，從而保證狀態(tài)一致
- Service Consumer會向Eureka Server獲取注冊服務(wù)列表，并消費服務(wù)
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)拖叙，通常可能對一致性要求低一點赂乐。
