簡介
- 微服務(wù)的三大特性：small翅娶、lightweight、automated狭园。
-
微服務(wù)的基礎(chǔ)設(shè)置
image.png
1. 自動(dòng)化測試
微服務(wù)將原本大一統(tǒng)的系統(tǒng)拆分了很多獨(dú)立運(yùn)行的微服務(wù)，微服務(wù)之間接口數(shù)量居多，并且微服務(wù)提倡快速交付踏堡，版本周期短，版本更新頻繁咒劲。如果每次更新靠人工回歸整個(gè)系統(tǒng)顷蟆，則工作量大，效率低腐魂，達(dá)不到快速交付的目的帐偎，因此必須通過自動(dòng)化完成絕大部分測試回歸的工作
自動(dòng)化測試包括：代碼級(jí)的單元測試、單個(gè)系統(tǒng)級(jí)的集成測試蛔屹、系統(tǒng)間的接口測試削樊，理想情況下每個(gè)類都要自動(dòng)化。如果因?yàn)閳F(tuán)隊(duì)規(guī)模和人力的原因無法全面覆蓋判导，至少要做到接口測試自動(dòng)化
- 開源：pithy 資料
2. 自動(dòng)化部署
與單體試架構(gòu)嫉父，微服務(wù)需要部署的節(jié)點(diǎn)增加了幾倍甚至十幾倍，微服務(wù)部署頻率也大幅度提升眼刃，綜合算下來绕辖，微服務(wù)部署次數(shù)是大一統(tǒng)部署次數(shù)的幾十倍。如果繼續(xù)采用人工部署擂红，需要投入大量的人力仪际，且容易出錯(cuò)围小，因此需要自動(dòng)化部署系統(tǒng)。
- 自動(dòng)化部署系統(tǒng)包括：版本管理树碱、資源管理（如：機(jī)器管理肯适、虛擬機(jī)管理）、部署操作成榜、回退操作等框舔。
- 開源：gitlab cicd, k8s
3. 配置中心
微服務(wù)的節(jié)點(diǎn)數(shù)量非常多，通過人工登錄每臺(tái)機(jī)器手工修改赎婚，效率低刘绣，容易出錯(cuò)。特別是在部署或拍障時(shí)挣输，需要快速增刪改查配置纬凤，人工操作的方式顯然是不行的。此外撩嚼，有的運(yùn)行期配置需要?jiǎng)討B(tài)修改并且所有節(jié)點(diǎn)即時(shí)生效停士，人工操作是無法做到的。綜合上述的分析完丽，微服務(wù)需要一個(gè)統(tǒng)一的配置中心來管理所有的微服務(wù)節(jié)點(diǎn)配置
配置中心包括：版本管理恋技、增刪改查配置、節(jié)點(diǎn)管理舰涌、配置同步猖任、配置推送等功能。
- 開源：攜程的apollo
4. 接口框架
微服務(wù)提倡輕量級(jí)的通信方式瓷耙，一般采用HTTP/REST或RPC方式統(tǒng)一接口協(xié)議。但在實(shí)踐過程中刁赖，統(tǒng)一接口協(xié)議還不夠搁痛，還需要統(tǒng)一接口傳遞的數(shù)據(jù)格式。例如宇弛，我們需要指定接口協(xié)議為HTTP/REST,還需要指定數(shù)據(jù)格式為JSON且JSON的數(shù)據(jù)都遵循如下規(guī)范：
"requestId":100,
"time":"2020-04-23 00:01:01",
"caller":"tencent",
"api":"get_money",
"param":{
"userId":110
},
"sign":"1299394ujjdlfjasldjfoweuio"
}
接口框架不是一個(gè)可運(yùn)行的系統(tǒng)鸡典，一般以庫或包的形式提供給所有微服務(wù)調(diào)用
開源：gRPC，Thrift枪芒，dubbo彻况，rpcx，monthan
image.png
5. api網(wǎng)關(guān)
系統(tǒng)拆分為微服務(wù)后舅踪，內(nèi)部的微服務(wù)之間是互聯(lián)互通的纽甘，相互之間的訪問都是點(diǎn)對點(diǎn)的，如果外部系統(tǒng)想調(diào)用系統(tǒng)某個(gè)功能抽碌，也采用點(diǎn)對點(diǎn)的方式悍赢，則外部系統(tǒng)會(huì)非常“頭大”。因?yàn)閷ν獠肯到y(tǒng)來說左权，它不需要也沒辦法理解這么多微服務(wù)的職責(zé)分工和邊界皮胡，它只會(huì)關(guān)注它需要的能力，而不會(huì)關(guān)注這個(gè)能力時(shí)有那個(gè)微服務(wù)提供
- 此外赏迟，外部系統(tǒng)訪問系統(tǒng)還涉及到安全和權(quán)限的問題屡贺，如果外部系統(tǒng)直接訪問某個(gè)服務(wù)，則意味的每個(gè)服務(wù)都需要自己實(shí)現(xiàn)安全和權(quán)限的功能锌杀，這樣做不但工作量大烹笔，而且都是重復(fù)的工作。
- 綜合上訴分析抛丽，微服務(wù)需要一個(gè)統(tǒng)一的api網(wǎng)關(guān)谤职，負(fù)責(zé)外部系統(tǒng)的訪問操作。api網(wǎng)關(guān)是外部系統(tǒng)訪問的接口亿鲜，所有的外部系統(tǒng)接入系統(tǒng)都需要通過api網(wǎng)關(guān)允蜈，主要包括接入鑒權(quán)（是否允許接入）、權(quán)限控制（可以訪問那些功能）蒿柳、傳輸加密饶套、請求路由、流量控制等功能垒探。
- 開源：Kong妓蛮、Traefik、Ambassador圾叼、Tyk蛤克、Zuul 資料
6. 服務(wù)發(fā)現(xiàn)
微服務(wù)種類和數(shù)量很多，如果這些信息全部通過手工配置的方式寫入到各個(gè)微服務(wù)節(jié)點(diǎn)夷蚊，首先配置工作量很大构挤，配置文件可能要配幾百上千行，幾十個(gè)節(jié)點(diǎn)加起來后配置項(xiàng)就是幾萬幾十萬了惕鼓，人工維護(hù)這么大數(shù)量的配置項(xiàng)是一項(xiàng)災(zāi)難筋现。其次是微服務(wù)節(jié)點(diǎn)經(jīng)常變化，可能是由于擴(kuò)容導(dǎo)致節(jié)點(diǎn)增加箱歧，也可能是故障處理時(shí)隔離掉一部分節(jié)點(diǎn)矾飞，還可能是采用灰度升級(jí)，先將一部分節(jié)點(diǎn)升級(jí)到新版本呀邢，然后讓新老版本同時(shí)運(yùn)行洒沦；不管哪種情況，我們都希望節(jié)點(diǎn)的變化能夠及時(shí)同步到所有其他依賴的微服務(wù)驼鹅。如果采用手工配置微谓，是不可能做到實(shí)時(shí)更新生效的森篷。所有我們需要一套服務(wù)發(fā)現(xiàn)的系統(tǒng)來支撐微服務(wù)的自動(dòng)注冊和發(fā)現(xiàn)。
- 服務(wù)發(fā)現(xiàn)主要實(shí)現(xiàn)方式：自理式和代理式
- 服務(wù)發(fā)現(xiàn)的核心功能就是服務(wù)注冊表豺型，注冊表記錄了所有的服務(wù)節(jié)點(diǎn)的配置和狀態(tài)仲智，每個(gè)微服務(wù)啟動(dòng)后都需要將自己的信息注冊到服務(wù)注冊表，然后由微服務(wù)系統(tǒng)到服務(wù)注冊表查詢可用的服務(wù)
開源：Nacos姻氨、Eureka钓辆、consul、CoreDNS肴焊、Zookeeper
對比
7. 服務(wù)路由
- 有了服務(wù)發(fā)現(xiàn)后前联，微服務(wù)之間能夠方便地獲取相關(guān)配置信息，但具體進(jìn)行某次調(diào)用請求時(shí)娶眷，我們還需要從所有符合條件的可用微服務(wù)節(jié)點(diǎn)中挑選出一個(gè)具體的節(jié)點(diǎn)發(fā)起請求似嗤，這就是服務(wù)路由需要完成的功能。
- 服務(wù)路由和服務(wù)發(fā)現(xiàn)是密切相關(guān)的届宠，服務(wù)路由一般不會(huì)設(shè)計(jì)成為一個(gè)獨(dú)立運(yùn)行的系統(tǒng)烁落，通常情況下是和服務(wù)發(fā)現(xiàn)放在一起實(shí)現(xiàn)的。對于自理式服務(wù)發(fā)現(xiàn)豌注，服務(wù)路由是微服務(wù)內(nèi)部實(shí)現(xiàn)的伤塌；對于代理式服務(wù)發(fā)現(xiàn)，服務(wù)路由是load balancer系統(tǒng)實(shí)現(xiàn)的轧铁。無論放在那里每聪，核心功能是路由的算法：
- 常見路由算法：隨機(jī)路由、輪詢路由齿风、最小壓力路由药薯、最小連接數(shù)路由等。
8. 服務(wù)容錯(cuò)
- 系統(tǒng)拆分為微服務(wù)后聂宾，單個(gè)節(jié)點(diǎn)故障的概率變小果善，故障影響范圍也變少，但是微服務(wù)的節(jié)點(diǎn)數(shù)量大大增加了系谐。從整體看，系統(tǒng)中某個(gè)微服務(wù)出現(xiàn)故障的概率會(huì)大大增加讨跟，微服務(wù)還有故障擴(kuò)散的特點(diǎn)纪他，如果不及時(shí)處理，導(dǎo)致看起來系統(tǒng)很多節(jié)點(diǎn)都故障了晾匠。
- 常見服務(wù)容錯(cuò)包括：請求重試茶袒、流控和服務(wù)隔離
9.服務(wù)監(jiān)控
- 系統(tǒng)拆分微服務(wù)后，節(jié)點(diǎn)數(shù)量大大增加凉馆，導(dǎo)致需要監(jiān)控的機(jī)器薪寓、網(wǎng)絡(luò)亡资、進(jìn)程、接口調(diào)用數(shù)等監(jiān)控對象的數(shù)量大大增加向叉；同時(shí)锥腻，一旦發(fā)生故障，我們需要快速根據(jù)各類信息來定位故障母谎。
- 服務(wù)監(jiān)控主要作用：
-- 實(shí)時(shí)搜集信息并進(jìn)行分析瘦黑，避免故障后再來分析，減少了處理時(shí)間
-- 可以實(shí)時(shí)分析的基礎(chǔ)上進(jìn)行報(bào)警奇唤，在問題萌芽的階段發(fā)覺并預(yù)警幸斥，降低了問題的影響范圍和時(shí)間- 通常情況下，服務(wù)監(jiān)控需要搜集并分析大量的數(shù)據(jù)咬扇，因此建議做成獨(dú)立的系統(tǒng)甲葬，而不是集成到服務(wù)發(fā)現(xiàn)、api網(wǎng)關(guān)等系統(tǒng)中懈贺。
10. 服務(wù)跟蹤
- 服務(wù)監(jiān)控可以做到微服務(wù)節(jié)點(diǎn)級(jí)的監(jiān)控和信息收集经窖，但如果我們需要某個(gè)請求在微服務(wù)的完整路徑，就需要服務(wù)跟蹤了隅居。
- 服務(wù)監(jiān)控和服務(wù)跟蹤的區(qū)別可以簡單概括為宏觀和微觀的區(qū)別钠至。服務(wù)監(jiān)控記錄：請求次數(shù)，響應(yīng)時(shí)間平均值胎源、響應(yīng)時(shí)間最大值棉钧、錯(cuò)誤碼分布信息；服務(wù)跟蹤記錄：發(fā)起時(shí)間涕蚤、響應(yīng)時(shí)間宪卿、響應(yīng)錯(cuò)誤碼、請求參數(shù)万栅、返回的json數(shù)據(jù)
- 服務(wù)跟蹤技術(shù)：標(biāo)注點(diǎn)佑钾、跟蹤數(shù)和span；采樣跟蹤和染色跟蹤
11. 服務(wù)安全
- 系統(tǒng)拆分微服務(wù)后烦粒，數(shù)據(jù)分散在各個(gè)微服務(wù)節(jié)點(diǎn)上休溶。從系統(tǒng)連接的角度來說，任意微服務(wù)都可以訪問其他微服務(wù)節(jié)點(diǎn)扰她；但從業(yè)務(wù)角度來說兽掰，部分敏感數(shù)據(jù)或操作只能部分微服務(wù)可以訪問，而不是所有的微服務(wù)都可以訪問徒役。
- 服務(wù)安全分三部分：接入安全孽尽，數(shù)據(jù)安全，傳輸安全
- 服務(wù)安全可以集成到配置中心系統(tǒng)中忧勿，即配置中心配置微服務(wù)的接入安全策略和數(shù)據(jù)安全策略杉女，微服務(wù)節(jié)點(diǎn)從配置中心獲取這些配置信息瞻讽，然后在處理具體的微服務(wù)調(diào)用請求時(shí)，根據(jù)安全策略進(jìn)行處理熏挎。由于這些策略是通用的速勇，一般會(huì)把策略封裝成通用的庫提供給各個(gè)微服務(wù)調(diào)用。
