分布式系統(tǒng)架構(gòu)特別是進入微服務(wù)架構(gòu)后，服務(wù)治理的重要性愈發(fā)變得不可缺少而且處于重要地位。缺乏服務(wù)治理的的分布式系統(tǒng)架構(gòu)，很難正式投入生產(chǎn)。那么服務(wù)治理包括哪些方面呢？主要包括服務(wù)發(fā)現(xiàn)，負載均衡，限流，熔斷，超時，重試，服務(wù)跟蹤等。下面展開講。
侵入式服務(wù)治理
1.服務(wù)發(fā)現(xiàn)
服務(wù)發(fā)現(xiàn)是指使用一個注冊中心來記錄分布式系統(tǒng)中全部服務(wù)的信息，以便讓其他服務(wù)能夠快速找到這些已注冊的服務(wù)。服務(wù)發(fā)現(xiàn)需要服務(wù)注冊，服務(wù)查找，服務(wù)健康檢查及服務(wù)變更通知等關(guān)鍵功能。
最早的服務(wù)發(fā)現(xiàn)應(yīng)用就是DNS，通過使用域名，讓訪問者不必關(guān)心服務(wù)在哪里。其實DNS的服務(wù)發(fā)現(xiàn)應(yīng)用，在原來公司做大型嵌入式軟件時，雖然是單體系統(tǒng)，但是是一個分時的多進程系統(tǒng)，由于系統(tǒng)非常龐大，不同的進程間通信采用的是IPC進程間通信。為了便于不同的進程間通信，我們當時設(shè)計在IPC模塊內(nèi)部提供了一個小型的服務(wù)發(fā)現(xiàn)功能，所有需要通過IPC通信的系統(tǒng)，在模塊啟動時都需要調(diào)用IPC提供的服務(wù)注冊功能，這樣當模塊間通信時，就不用關(guān)注這個IPC通信是設(shè)備的板間通信還是板內(nèi)通信。這里簡單解下，因為設(shè)備形態(tài)存在控制板（主要負責協(xié)議計算和路由）和接口板（主要負責數(shù)據(jù)報文轉(zhuǎn)發(fā)，可能多個接口板），因此當我們在考慮IPC時提供了類似的設(shè)計。
可以看到關(guān)于服務(wù)發(fā)現(xiàn)，關(guān)鍵是要有一個服務(wù)注冊中心。具體的服務(wù)發(fā)現(xiàn)機制
1.服務(wù)提供者啟動時需要注冊。
2.注冊中心與服務(wù)提供者無法保持心跳時需要剔除服務(wù)
3.服務(wù)消費者可以從注冊中心獲取服務(wù)提供者的最新信息，可以采取定期拉和事件通知的兩種方式
可以看到服務(wù)注冊中心在分布式服務(wù)架構(gòu)中的關(guān)鍵位置，因此需要具備高可用?；贑AP定理的，服務(wù)注冊中心的最佳選擇是一個AP的系統(tǒng)。但實際中我們常用的注冊中心有zooKeeper,Eureka,etcd,consul，還有阿里的Nacos。
- zooKeeper我們知道它本質(zhì)其實是一個CP模型，基于其自己的Zab協(xié)議（基于Paxos裁剪）來保證注冊中心多個節(jié)點之間的數(shù)據(jù)一致性。
Zab協(xié)議規(guī)定，消息傳遞要遵循可靠傳遞，完全有序，因果有序的特性.
在zooKeeper中，主節(jié)點故障下，Zab協(xié)議通過主節(jié)點快速選舉，初始化，同步從節(jié)點、廣播幾個階段來保證數(shù)據(jù)一致性和主節(jié)點選舉的高效。
zooKeeper 的核心概念
集群角色： 主節(jié)點,從節(jié)點，觀察者節(jié)點。主節(jié)點負責數(shù)據(jù)寫入服務(wù)，從節(jié)點提供讀數(shù)據(jù)。觀察者同樣提供讀但是不參與選舉投票。在集群中，服務(wù)器數(shù)量是奇數(shù)被認為是一個最佳實踐。集群對外工作的必要條件是超過半數(shù)的服務(wù)器可以對外正常工作。
另外有個集群宕機容忍度的衡量，2臺服務(wù)器的容忍度為0，3臺，4臺容忍度都是1
會話：在zooKeeper,客戶端和服務(wù)端之間是有TCP長連接的。基于長連接發(fā)送心跳。會話超時時間徐阿喲根據(jù)生產(chǎn)環(huán)境的網(wǎng)絡(luò)狀況合理設(shè)定。
數(shù)據(jù)節(jié)點：數(shù)據(jù)節(jié)點稱zNode,通過/分割父節(jié)點和子節(jié)點。zNode分為持久節(jié)點和臨時節(jié)點 服務(wù)注冊就是注冊在臨時節(jié)點上。
PERSISTENT
PERSISTENT_SEQUENTIAL（持久序列/test0000000019 ）
EPHEMERAL
EPHEMERAL_SEQUENTIAL
監(jiān)聽： 即watcher,客戶端可以在感興趣的zNode上進行監(jiān)聽，當zNode狀態(tài)變化時，服務(wù)端會通知客戶端。
zooKpeer 原生提供了命令行客戶端及Java，c的客戶端。原生客戶端開發(fā)效率低，且存在一些不足（不支持遞歸，需要重復(fù)注冊監(jiān)聽器，需要自行解決會話超時，對常用的分布式鎖，選舉，分布式計數(shù)等都需要二次開發(fā)）。
zkClient和Curator是兩個常見的三方庫。
zkClient提供遞歸刪除創(chuàng)建節(jié)點，會話超時處理，監(jiān)聽器反復(fù)等，簡化了原生API的使用。
Curator是Netflix開源的，已經(jīng)被Apache基金會收錄。除了支持zkClient的功能，還支持選舉，分布式鎖等場景
zooKeeper是最廣為廣泛的分布式協(xié)調(diào)組件，由于存在當主節(jié)點因為網(wǎng)絡(luò)與其他節(jié)點失去聯(lián)系導(dǎo)致整個系統(tǒng)重新選舉時，集群是不可用的（這也是它作為CP模型，不能應(yīng)用于大規(guī)模分布式系統(tǒng)注冊中心的考慮。），因此已經(jīng)不是服務(wù)發(fā)現(xiàn)的最好選擇了，其主要優(yōu)勢在選舉和分布式鎖。Curator提供的緩存能力，能夠讓zooKeeper可用性增強，同時由于緩存使得其從CP發(fā)生向AP的轉(zhuǎn)化
- Eureka
Eureka采用了去中心化的設(shè)計，整個集群由對等節(jié)點組成，不存在zk（zooKpeer以下簡稱zk）的選舉問題。服務(wù)端之間相互注冊彼此同步信息來實現(xiàn)高可用性?？蛻舳丝梢赃B接任一服務(wù)端進行注冊。但這樣會存在數(shù)據(jù)的一致性問題，也就是客戶端查詢的信息不一定是最新的。
Eureka也是Netflix的開源項目，可以和SpringCloud很好的整合。Eureka是一個 war包，需要部署到一個web服務(wù)器中。另外Eureka提提供一個保護機制，就是當超過85%的節(jié)點在15分鐘內(nèi)沒有心跳時，就會啟動，此時
1.不再從注冊列表刪除長時間沒有心跳的服務(wù)
2.不會接受新的戶注冊及同步數(shù)據(jù)
3.網(wǎng)絡(luò)恢復(fù)穩(wěn)定后再接受新注冊及同步信息
Eureka提供了java,Python, Node.js, .net的客戶端，對于沒有客戶端的語言可以通過Restful API交互。
Etcd
Etcd和zk具有類似的架構(gòu)，采用 Raft算法代替了 zab，從CAP來分析，也是一個CP系統(tǒng)，通過TTL來實現(xiàn)類似zk臨時節(jié)點的功能Consul
Consul是一個商業(yè)產(chǎn)品(Raft)，有一個開源版本。除了服務(wù)發(fā)現(xiàn)，還通過內(nèi)存，磁盤使用的細粒度狀態(tài)檢測及服務(wù)配置的鍵值存儲功能。-
Nacos
Nacos 致力于幫助您發(fā)現(xiàn)、配置和管理微服務(wù)。Nacos 提供了一組簡單易用的特性集，幫助您快速實現(xiàn)動態(tài)服務(wù)發(fā)現(xiàn)、服務(wù)配置、服務(wù)元數(shù)據(jù)及流量管理。
Nacos 幫助您更敏捷和容易地構(gòu)建、交付和管理微服務(wù)平臺。 Nacos 是構(gòu)建以“服務(wù)”為中心的現(xiàn)代應(yīng)用架構(gòu) (例如微服務(wù)范式、云原生范式) 的服務(wù)基礎(chǔ)設(shè)施。
nacos_map
Nacos 支持基于 DNS 和基于 RPC 的服務(wù)發(fā)現(xiàn)。服務(wù)提供者使用 原生SDK、OpenAPI、或一個獨立的Agent TODO注冊 Service 后，服務(wù)消費者可以使用DNS TODO 或HTTP&API查找和發(fā)現(xiàn)服務(wù).它同時支持AP和CP模式，可以通過配置切換。
