內(nèi)容來(lái)源：2018年1月25日涤久，ServiceComb 開(kāi)發(fā)工程師崔毅華在“ServiceComb在線直播”進(jìn)行《Service Center源碼揭秘》演講分享。IT 大咖說(shuō)（WeChat_ID：itdakashuo）作為獨(dú)家視頻合作方赐劣，經(jīng)主辦方和講者審閱授權(quán)發(fā)布。

閱讀字?jǐn)?shù)：2332?| 4分鐘閱讀

觀看嘉賓完整演講視頻及PPT闪幽，請(qǐng)點(diǎn)擊：http://t.cn/Eyfdkex

摘要

揭秘Service Center的架構(gòu)和設(shè)計(jì)細(xì)節(jié)击敌，在線閱讀分享Service Center代碼。

什么是服務(wù)注冊(cè)中心焕妙？

服務(wù)注冊(cè)中心具有服務(wù)注冊(cè)和服務(wù)發(fā)現(xiàn)能力的可靠的分布式服務(wù)蒋伦。

為什么需要服務(wù)注冊(cè)中心？

是單體架構(gòu)向微服務(wù)服務(wù)化演進(jìn)的需要焚鹊。

以前的老式單體結(jié)構(gòu)非常臃腫痕届，部署在一個(gè)集群上，不夠靈活末患。在演進(jìn)的過(guò)程中研叫，架構(gòu)師分散地進(jìn)行了拆分，慢慢演進(jìn)成微服務(wù)的架構(gòu)阻塑。

單體架構(gòu)到微服務(wù)架構(gòu)的演進(jìn)中的確帶來(lái)了很多好處蓝撇，比如架構(gòu)業(yè)務(wù)實(shí)現(xiàn)了解耦，單一職責(zé)陈莽，而且每一個(gè)服務(wù)可以獨(dú)立運(yùn)行渤昌。在開(kāi)發(fā)運(yùn)維上成本也更低虽抄，迭代上線周期更短，解放了程序員的生產(chǎn)力独柑。

但同時(shí)也引入了新的問(wèn)題迈窟。比如業(yè)務(wù)間的通信發(fā)生了變化，需要遠(yuǎn)程通信調(diào)用忌栅。要解決通信上的問(wèn)題车酣，除了定制一個(gè)業(yè)務(wù)間通信的標(biāo)準(zhǔn)協(xié)議之外，還需要一個(gè)具有服務(wù)注冊(cè)和服務(wù)發(fā)現(xiàn)能力的組件索绪，能夠保存業(yè)務(wù)進(jìn)程的一些實(shí)例信息湖员，還能提供查詢實(shí)例IP地址的標(biāo)準(zhǔn)接口給各個(gè)業(yè)務(wù)去使用。

服務(wù)注冊(cè)中心

服務(wù)端發(fā)現(xiàn)

DNS可以作為服務(wù)端發(fā)現(xiàn)的組件瑞驱，各個(gè)服務(wù)會(huì)把自己的服務(wù)名當(dāng)作域名娘摔，把自己的實(shí)例IP注冊(cè)到DNS當(dāng)中。DNS會(huì)根據(jù)每一次請(qǐng)求返回一個(gè)IP給服務(wù)消費(fèi)端唤反。

隨著業(yè)務(wù)規(guī)模變大凳寺，容器化的出現(xiàn)又使得微服務(wù)架構(gòu)重新出現(xiàn)。在這種情況下彤侍，DNS的問(wèn)題也慢慢突顯出來(lái)肠缨。首先，DNS的緩存刷新不及時(shí)盏阶。其次晒奕，為了減輕DNS的壓力，一般服務(wù)端在開(kāi)發(fā)過(guò)程中就會(huì)把域名解析的IP緩存到本地般哼，基本上沒(méi)有什么問(wèn)題的話不會(huì)訪問(wèn)DNS吴汪。DNS本身又缺少一個(gè)主動(dòng)通知的機(jī)制，無(wú)法通知消費(fèi)方刷新本地緩存蒸眠，時(shí)間一長(zhǎng)就會(huì)出現(xiàn)越來(lái)越多的實(shí)例不可用漾橙、IP找不到或者IP無(wú)法訪問(wèn)等情況，整個(gè)架構(gòu)都會(huì)非常不穩(wěn)定楞卡。另外還會(huì)有一個(gè)中心化的問(wèn)題霜运。DNS一旦出現(xiàn)故障，集中式的服務(wù)發(fā)現(xiàn)就會(huì)影響整個(gè)系統(tǒng)蒋腮。

DNS這個(gè)方案雖然可以臨時(shí)解決一些問(wèn)題淘捡，但是它最終還是不適合做服務(wù)注冊(cè)中心的。

客戶端發(fā)現(xiàn)

服務(wù)消費(fèi)端只需要關(guān)心和查詢訂閱自己依賴的一些業(yè)務(wù)服務(wù)實(shí)例表或IP列表池摧，自己在本地根據(jù)喜歡的路由策略進(jìn)行過(guò)濾和請(qǐng)求焦除。操作簡(jiǎn)單數(shù)量也很少，所以大部分開(kāi)源類似可以做服務(wù)注冊(cè)中心組件的都偏向于做客戶端發(fā)現(xiàn)作彤。

適合做服務(wù)注冊(cè)中心的開(kāi)源組件有Service Center膘魄，eureka乌逐，etcd，zookeeper和consul创葡。

為什么實(shí)現(xiàn)自己的服務(wù)注冊(cè)中心浙踢？

應(yīng)該提供標(biāo)準(zhǔn)化的接口，具有負(fù)載均衡和服務(wù)訂閱的能力灿渴。運(yùn)行時(shí)的依賴一定要夠輕洛波，可靠性也是非常重要的。

從服務(wù)注冊(cè)中心到服務(wù)管理中心

我們定義了微服務(wù)的靜態(tài)元數(shù)據(jù)結(jié)構(gòu)骚露，Service Center也提供了非常方便的接口去檢索這些信息蹬挤。

為了很好地呈現(xiàn)微服務(wù)之間的調(diào)用關(guān)系，也需要把依賴關(guān)系拉進(jìn)來(lái)作為管理荸百。

根據(jù)依賴關(guān)系的管理來(lái)可以進(jìn)行實(shí)例變化的推送闻伶。

支持多租隔離。

Service Center從設(shè)計(jì)上已經(jīng)考慮了各種故障點(diǎn)并提供了對(duì)應(yīng)的保護(hù)機(jī)制够话，也就是高可用保障的能力。

根據(jù)上面的架構(gòu)圖可見(jiàn)光绕，微服務(wù)的重要發(fā)現(xiàn)會(huì)統(tǒng)一通過(guò)Service Center進(jìn)行處理女嘲。

元數(shù)據(jù)

1、應(yīng)用App诞帐，便于微服務(wù)可在多個(gè)應(yīng)用間重用

2欣尼、微服務(wù)名稱，App內(nèi)唯一

3停蕉、微服務(wù)描述信息愕鼓，讓使用者可以快速了解到業(yè)務(wù)范疇等

4、微服務(wù)訪問(wèn)契約內(nèi)容慧起，API能力的描述文件

5菇晃、微服務(wù)擴(kuò)展屬性，添加具體業(yè)務(wù)擴(kuò)展屬性

6蚓挤、微服務(wù)黑白名單磺送，支持Provider側(cè)設(shè)置路由策略

7、微服務(wù)標(biāo)簽灿意，支持按標(biāo)簽檢索

高可用性保障

我們引用了互聯(lián)網(wǎng)分布式系統(tǒng)設(shè)計(jì)的準(zhǔn)則BASE來(lái)判斷組件是否為高可靠的估灿。BASE就是Basically Available（基本可用）、Soft state（軟狀態(tài)）和Eventually consistent（最終一致性）缤剧。

CAP理論

Consistency(一致性)馅袁，在分布式系統(tǒng)的各點(diǎn)同時(shí)保持?jǐn)?shù)據(jù)的一致。

Availability(可用性)荒辕，每個(gè)請(qǐng)求都能接受到一個(gè)響應(yīng)汗销，無(wú)論響應(yīng)成功或失敗芒粹。

Partition tolerance(分區(qū)容錯(cuò)性)，當(dāng)出現(xiàn)網(wǎng)絡(luò)分區(qū)故障時(shí)系統(tǒng)的容錯(cuò)能力

從微服務(wù)到服務(wù)管理中心

實(shí)例緩存機(jī)制

服務(wù)管理中心提供了實(shí)例緩存機(jī)制大溜』幔基于ServiceComb的SDK開(kāi)發(fā)的微服務(wù)在第一次消費(fèi)provider的時(shí)候會(huì)進(jìn)行一次實(shí)例發(fā)現(xiàn)的操作，在內(nèi)部向Service Center拉取provider存活的實(shí)例集合钦奋，并保存到內(nèi)存緩存中座云。消費(fèi)請(qǐng)求都會(huì)跟著這個(gè)緩存集合不停地用自定義的路由策略去選擇一個(gè)合適的進(jìn)行請(qǐng)求。

這樣做的好處就是已經(jīng)運(yùn)行的SDK進(jìn)程始終在內(nèi)部保存了一份實(shí)例緩存付材，在出現(xiàn)服務(wù)與Service Center網(wǎng)絡(luò)分區(qū)的情況下朦拖，雖然無(wú)法實(shí)時(shí)感知實(shí)例的刷新，但是可以在重新連上Service Center之后觸發(fā)一次實(shí)例刷新厌衔，保證這個(gè)實(shí)例最終還是有效的璧帝。

在這個(gè)過(guò)程中，SDK上承載的一些業(yè)務(wù)是始終可用的富寿，沒(méi)有中斷睬隶。

心跳保活機(jī)制

SDK通過(guò)進(jìn)程上報(bào)實(shí)例心跳的方式對(duì)它的實(shí)例進(jìn)行币承欤活苏潜。每個(gè)provider和Service Center之間的心跳在無(wú)法保持的時(shí)候，實(shí)例就會(huì)按照設(shè)置好的時(shí)間自動(dòng)老化变勇。

當(dāng)Service Center感知到這個(gè)實(shí)例下線了恤左，就會(huì)推送給各個(gè)監(jiān)聽(tīng)在ServiceComb上的consumer去刷新本地緩存，實(shí)現(xiàn)了微服務(wù)動(dòng)態(tài)發(fā)現(xiàn)的能力

從微服務(wù)管理中心到etcd

異步緩存機(jī)制

基于Service Center內(nèi)部本身是不存數(shù)據(jù)的搀绣，一旦etcd出現(xiàn)網(wǎng)絡(luò)故障的時(shí)候飞袋，就會(huì)導(dǎo)致Service Center不可用。

所以Service Center引入了異步緩存機(jī)制链患，在啟動(dòng)之初Service Center會(huì)與etcd建立一個(gè)長(zhǎng)連接巧鸭，也就是watch。每次watch的時(shí)候?yàn)榱朔乐菇atch時(shí)間窗發(fā)生變化锣险，做了一層保護(hù)蹄皱，在watch之前做了全量的查詢。

在運(yùn)行過(guò)程中查詢所得到的資源變化會(huì)緩存到Service Center本地芯肤，然后進(jìn)行異步的循環(huán)巷折。

異步心跳機(jī)制

ServiceCenter會(huì)根據(jù)上報(bào)實(shí)例的心跳頻率和失敗次數(shù)來(lái)推算最終實(shí)例下線的時(shí)間。異步心跳機(jī)制的好處就是它不會(huì)因?yàn)橐恍┬奶难訒r(shí)而阻塞崖咨，也使得Service Center處理心跳的能力大幅提高锻拘。

自我保護(hù)機(jī)制

前面提到的緩存機(jī)制，保證了Service Center在etcd出現(xiàn)網(wǎng)絡(luò)分區(qū)故障時(shí)依然保持可讀狀態(tài)，Service Center的自我保護(hù)(Self-preservation)機(jī)制保證了Provider端與Service Center在出現(xiàn)網(wǎng)絡(luò)分區(qū)故障時(shí)依然保持業(yè)務(wù)可用署拟。

ServiceCenter在一個(gè)時(shí)間窗內(nèi)監(jiān)聽(tīng)到etcd有80%的實(shí)例下線事件婉宰，會(huì)立即啟動(dòng)自我保護(hù)機(jī)制。即使etcd存儲(chǔ)的數(shù)據(jù)全部丟失推穷，這種極端場(chǎng)景下心包，SDK與Service Center之間可在不影響業(yè)務(wù)的前提下，做到數(shù)據(jù)自動(dòng)恢復(fù)馒铃。雖然這個(gè)恢復(fù)是有損的蟹腾，但在這種災(zāi)難場(chǎng)景下還能保持業(yè)務(wù)基本可用。

如何參與到ServiceComb社區(qū)

官網(wǎng)：http://servicecomb.incubator.apache.org/cn/

通過(guò)訂閱郵件列表參與討論：

1区宇、發(fā)送任意內(nèi)容至郵箱：dev-subscribe@servicecomb.incubator.apache.org

2娃殖、收到來(lái)自dev-help的郵件后，再回復(fù)任意內(nèi)容來(lái)確認(rèn)訂閱郵件列表

在Apache JIRA(https://issues.apache.org/jira/browse/SCB)上提issue或查看最新的開(kāi)發(fā)任務(wù)及進(jìn)展议谷；

加入微信群進(jìn)行交流炉爆；

通過(guò)Github(https://github.com/apache?q=servicecomb)發(fā)起PR

今天的分享就到這里，謝謝大家卧晓！

編者：IT大咖說(shuō)芬首，轉(zhuǎn)載請(qǐng)標(biāo)明版權(quán)和出處