作者 | tengshe789
來源 | https://juejin.im/post/5c0ba2bef265da614d08fefe

微服務(wù)的概念最早在 2012 年提出彤避，在 Martin Fowler 的大力推廣下，微服務(wù)在 2014 年后得到了大力發(fā)展夯辖。今天我們通過一組手繪圖來梳理下微服務(wù)的核心架構(gòu)琉预。

什么是微服務(wù)？

微服務(wù) Microservices 之父蒿褂，馬丁.福勒圆米，對微服務(wù)大概的概述如下：

就目前而言，對于微服務(wù)業(yè)界并沒有一個統(tǒng)一的啄栓、標(biāo)準(zhǔn)的定義（While there is no precise definition of this architectural style ) 娄帖。

但通常在其而言，微服務(wù)架構(gòu)是一種架構(gòu)模式或者說是一種架構(gòu)風(fēng)格昙楚，它提倡將單一應(yīng)用程序劃分成一組小的服務(wù)近速，每個服務(wù)運(yùn)行獨(dú)立的自己的進(jìn)程中，服務(wù)之間互相協(xié)調(diào)堪旧、互相配合削葱，為用戶提供最終價值。

服務(wù)之間采用輕量級的通信機(jī)制互相溝通（通常是基于 HTTP 的 RESTful API ) 淳梦。每個服務(wù)都圍繞著具體業(yè)務(wù)進(jìn)行構(gòu)建析砸，并且能夠被獨(dú)立地部署到生產(chǎn)環(huán)境、類生產(chǎn)環(huán)境等爆袍。

另外首繁，應(yīng)盡量避免統(tǒng)一的作郭、集中式的服務(wù)管理機(jī)制，對具體的一個服務(wù)而言蛮瞄，應(yīng)根據(jù)業(yè)務(wù)上下文所坯，選擇合適的語言、工具對其進(jìn)行構(gòu)建挂捅，可以有一個非常輕量級的集中式管理來協(xié)調(diào)這些服務(wù)芹助。可以使用不同的語言來編寫服務(wù)，也可以使用不同的數(shù)據(jù)存儲闲先。

根據(jù)馬丁.福勒的描述状土，我總結(jié)了以下幾點(diǎn)：

image

①小服務(wù)

小服務(wù)，沒有特定的標(biāo)準(zhǔn)或者規(guī)范伺糠，但他在總體規(guī)范上一定是小的蒙谓。

②進(jìn)程獨(dú)立

每一組服務(wù)都是獨(dú)立運(yùn)行的，可能我這個服務(wù)運(yùn)行在 Tomcat 容器训桶，而另一個服務(wù)運(yùn)行在 Jetty 上累驮。可以通過進(jìn)程方式舵揭，不斷的橫向擴(kuò)展整個服務(wù)谤专。

③通信

過去的協(xié)議都是很重的，就像 ESB午绳，就像 SOAP置侍，輕通信，這意味著相比過去更智能更輕量的服務(wù)相互調(diào)用拦焚，就所謂 smart endpoints and dumb pipes蜡坊。

這些 Endpoint 都是解耦的，完成一個業(yè)務(wù)通信調(diào)用串起這些 Micro Service 就像是 Linux 系統(tǒng)中通過管道串起一系列命令業(yè)務(wù)赎败。

過去的業(yè)務(wù)秕衙，我們通常會考慮各種各樣的依賴關(guān)系，考慮系統(tǒng)耦合帶來的問題僵刮。微服務(wù)灾梦，可以讓開發(fā)者更專注于業(yè)務(wù)的邏輯開發(fā)。

④部署

不止業(yè)務(wù)要獨(dú)立妓笙，部署也要獨(dú)立若河。不過這也意味著，傳統(tǒng)的開發(fā)流程會出現(xiàn)一定程度的改變寞宫，開發(fā)的適合也要有一定的運(yùn)維職責(zé)萧福。

⑤管理

傳統(tǒng)的企業(yè)級 SOA 服務(wù)往往很大，不易于管理辈赋，耦合性高鲫忍，團(tuán)隊(duì)開發(fā)成本比較大膏燕。

微服務(wù)，可以讓團(tuán)隊(duì)各思其政的選擇技術(shù)實(shí)現(xiàn)悟民，不同的 Service 可以根據(jù)各自的需要選擇不同的技術(shù)棧來實(shí)現(xiàn)其業(yè)務(wù)邏輯坝辫。

微服務(wù)的利與弊

為什么用微服務(wù)呢？因?yàn)楹猛嫔淇鳎坎皇堑慕ΑＯ旅媸俏覐木W(wǎng)絡(luò)上找到說的比較全的優(yōu)點(diǎn)：

• 優(yōu)點(diǎn)是每個服務(wù)足夠內(nèi)聚，足夠小智润，代碼容易理解這樣能聚焦一個指定的業(yè)務(wù)功能或業(yè)務(wù)需求及舍。

• 開發(fā)簡單、開發(fā)效率提高窟绷，一個服務(wù)可能就是專一的只干一件事锯玛。

• 微服務(wù)能夠被小團(tuán)隊(duì)單獨(dú)開發(fā)，這個小團(tuán)隊(duì)是 2 到 5 人的開發(fā)人員組成兼蜈。

• 微服務(wù)是松耦合的攘残，是有功能意義的服務(wù)，無論是在開發(fā)階段或部署階段都是獨(dú)立的为狸。

• 微服務(wù)能使用不同的語言開發(fā)歼郭。

• 易于和第三方集成，微服務(wù)允許容易且靈活的方式集成自動部署钥平，通過持續(xù)集成工具实撒，如 Jenkins姊途，Hudson涉瘾，bamboo。

• 微服務(wù)易于被一個開發(fā)人員理解捷兰，修改和維護(hù)立叛，這樣小團(tuán)隊(duì)能夠更關(guān)注自己的工作成果。無需通過合作才能體現(xiàn)價值贡茅。微服務(wù)允許你利用融合最新技術(shù)秘蛇。

• 微服務(wù)只是業(yè)務(wù)邏輯的代碼，不會和 HTML顶考，CSS 或其他界面組件混合赁还。

• 每個微服務(wù)都有自己的存儲能力，可以有自己的數(shù)據(jù)庫驹沿，也可以有統(tǒng)一數(shù)據(jù)庫艘策。

總的來說，微服務(wù)的優(yōu)勢渊季，就是在于贰逾，面對大的系統(tǒng)纵柿，可以有效的減少復(fù)雜程度免都，使服務(wù)架構(gòu)的邏輯更清晰明了。但是這樣也會帶來很多問題荷并，就譬如分布式環(huán)境下的數(shù)據(jù)一致性，測試的復(fù)雜性青扔，運(yùn)維的復(fù)雜性源织。

什么組織適合使用微服務(wù)？

微服務(wù)帶了種種優(yōu)點(diǎn)赎懦，種種弊端雀鹃，那么什么組織適合使用微服務(wù)？

①墨菲定律（設(shè)計(jì)系統(tǒng)）和康威定律（系統(tǒng)劃分）

康威定律励两，是一個五十多年前就被提出來的微服務(wù)概念黎茎。在康威的這篇文章中，最有名的一句話就是：

*Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. *

-Melvin Conway(1967)

中文直譯大概的意思就是：設(shè)計(jì)系統(tǒng)的組織当悔，其產(chǎn)生的設(shè)計(jì)等同于組織之內(nèi)傅瞻、組織之間的溝通結(jié)構(gòu)。

看看下面的圖片盲憎，再想想 Apple 的產(chǎn)品嗅骄、微軟的產(chǎn)品設(shè)計(jì)，就能形象生動的理解這句話饼疙。

image

感興趣的各位可以研究一下溺森！②架構(gòu)演化

架構(gòu)是不斷演化出來的，微服務(wù)也是這樣窑眯，當(dāng)從各大科技公司屏积，規(guī)模大到一定程度，完全需要演化成更進(jìn)一步管理的技術(shù)架構(gòu)體系磅甩。

image

傳統(tǒng)的團(tuán)隊(duì)炊林，都是面向過程化的，產(chǎn)品想完了去找策劃卷要，策劃完了找開發(fā)渣聚，接著順著一步一步找。

我們做技術(shù)都是為了產(chǎn)品的僧叉，一旦過程出來了什么問題奕枝，回溯尋找問題會非常耗時。

image

使用了微服務(wù)架構(gòu)體系瓶堕，團(tuán)隊(duì)組織方式需要轉(zhuǎn)變成跨職能團(tuán)隊(duì)隘道，即每個團(tuán)隊(duì)都有產(chǎn)品專家，策劃專家，開發(fā)專家薄声，運(yùn)維專家当船，他們使用 API 方式發(fā)布他們的功能，而平臺使用他們的功能發(fā)布產(chǎn)品默辨。

image

image

微服務(wù)技術(shù)架構(gòu)體系

下面我分享一下大部分公司都使用的微服務(wù)技術(shù)架構(gòu)體系：

image

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

主流的服務(wù)發(fā)現(xiàn)德频，分為三種：

image

第一種，開發(fā)人員開發(fā)了程序以后缩幸，會找運(yùn)維配一個域名壹置，服務(wù)的話通過 DNS 就能找到我們對應(yīng)的服務(wù)。

缺點(diǎn)是表谊，由于服務(wù)沒有負(fù)載均衡功能钞护，對負(fù)載均衡服務(wù)，可能會有相當(dāng)大的性能問題爆办。

image

第二種难咕，是目前普遍的做法【嗔荆可以參考 Zuul 網(wǎng)關(guān)余佃，每一個服務(wù)都通過服務(wù)端內(nèi)置的功能注冊到注冊中心，服務(wù)消費(fèi)者不斷輪詢注冊中心發(fā)現(xiàn)對應(yīng)的服務(wù)跨算，使用內(nèi)置負(fù)載均衡調(diào)用服務(wù)爆土。

缺點(diǎn)是，對多語言環(huán)境不是很好诸蚕，你需要單獨(dú)給消費(fèi)者的客戶端開發(fā)服務(wù)發(fā)現(xiàn)和負(fù)載均衡功能步势。當(dāng)然了，這個方法通常都是用在 Spring Cloud 上的背犯。

image

第三種坏瘩，是將客戶端和負(fù)載均衡放在同一個主機(jī)，而不是同一個進(jìn)程內(nèi)媳板。這種方法相對第一種第二種方法來說桑腮，改善了他們的缺點(diǎn)泉哈，但是會極大增加運(yùn)維成本蛉幸。

網(wǎng)關(guān)

微服務(wù)的網(wǎng)關(guān)是什么？我們可以聯(lián)系生活實(shí)際想一下丛晦。每一個大的公司奕纫，都會有一偏屬于自己的建筑區(qū)，而這建筑區(qū)內(nèi)烫沙，都有不少的門衛(wèi)匹层。如果有外來人員進(jìn)入公司，會先和門衛(wèi)打好招呼，才能進(jìn)去升筏。

將生活實(shí)際聯(lián)系到微服務(wù)上撑柔，就不難理解網(wǎng)關(guān)的意思了：

image

網(wǎng)關(guān)的作用如下：

• 反向路由：很多時候，公司不想讓外部人員看到我們公司的內(nèi)部您访，就需要網(wǎng)關(guān)來進(jìn)行反向路由铅忿。即將外部請求轉(zhuǎn)換成內(nèi)部具體服務(wù)調(diào)用。

• 安全認(rèn)證：網(wǎng)絡(luò)中會有很多惡意訪問灵汪，譬如爬蟲檀训，譬如黑客攻擊，網(wǎng)關(guān)維護(hù)安全功能享言。

• 限流熔斷：當(dāng)請求很多服務(wù)不堪重負(fù)峻凫，會讓我們的服務(wù)自動關(guān)閉，導(dǎo)致不能用服務(wù)览露。限流熔斷可以有效的避免這類問題荧琼。

• 日志監(jiān)控：所有的外面的請求都會經(jīng)過網(wǎng)關(guān)，這樣我們就可以使用網(wǎng)關(guān)來記錄日志信息差牛。

• 灰度發(fā)布铭腕，藍(lán)綠部署。是指能夠平滑過渡的一種發(fā)布方式多糠。在其上可以進(jìn)行 A/B testing累舷。

  即讓一部分用戶繼續(xù)用產(chǎn)品特性 A，一部分用戶開始用產(chǎn)品特性 B夹孔，如果用戶對 B 沒有什么反對意見被盈，那么逐步擴(kuò)大范圍，把所有用戶都遷移到 B 上面來搭伤。

開源網(wǎng)關(guān) Zuul 架構(gòu)：

image

Zuul 網(wǎng)關(guān)核心其實(shí)是一個 Servlet只怎，所有請求都會經(jīng)過 Zuul Servlet 傳到 ZuulFilter Runner，然后分發(fā)到三種過濾器怜俐。先說說架構(gòu)圖左半部分身堡，分別是使用 Groovy 實(shí)現(xiàn)的前置路由過濾器，路由過濾器拍鲤，后置路由過濾器贴谎。一般請求都會先經(jīng)過前置路由過濾器處理，一般的自定義 Java 封裝邏輯也會在這里實(shí)現(xiàn)季稳。路由過濾器擅这，實(shí)現(xiàn)的是找到對應(yīng)的微服務(wù)進(jìn)行調(diào)用。調(diào)用完了景鼠，響應(yīng)回來仲翎，會經(jīng)過后置路由過濾器，通過后置路由過濾器我們可以封裝日志審計(jì)的處理∷菹悖可以說 Zuul 網(wǎng)關(guān)最大的特色就是它的三層過濾器鲫构。架構(gòu)圖右半部分，是 Zuul 網(wǎng)關(guān)設(shè)計(jì)的自定義過濾器加載機(jī)制玫坛。網(wǎng)關(guān)內(nèi)部會有生產(chǎn)者消費(fèi)者模型芬迄，自動的將過濾器腳本發(fā)布到 Zuul 網(wǎng)關(guān)讀取加載運(yùn)行。

配置中心

以前昂秃，開發(fā)人員把配置文件放在開發(fā)文件里面禀梳，這樣會有很多隱患。譬如肠骆，配置規(guī)范不同算途，無法追溯配置人員。一旦需要大規(guī)模改動配置蚀腿，改動時間會很長嘴瓤，無法追溯配置人員，從而影響整個產(chǎn)品莉钙，后果是我們承擔(dān)不起的廓脆。因此就有配置中心這個嘍！現(xiàn)在的開源中心有百度配置中心 Disconf磁玉，Spring Cloud Config停忿，Apollo。

今天重點(diǎn)說說現(xiàn)在應(yīng)用質(zhì)量不錯的配置中心蚊伞，攜程開源的阿波羅（Apollo）：

image.png

Apollo 的配置中心規(guī)模比較大席赂，本地應(yīng)用會有響應(yīng)的配置中心客戶端，可以定時同步配置中心里的配置时迫。如果配置中心怠機(jī)颅停，會使用緩存來進(jìn)行配置。

通訊方式

關(guān)于通訊方式掠拳，一般市面也就是兩種遠(yuǎn)程調(diào)用方式癞揉，我整理了一個表格：

image

監(jiān)控預(yù)警

監(jiān)控預(yù)警對于微服務(wù)很重要，一個可靠的監(jiān)控預(yù)警體系對微服務(wù)運(yùn)行至關(guān)重要溺欧。

一般監(jiān)控分為如下層次：

image

從基礎(chǔ)設(shè)施到用戶端喊熟，層層有監(jiān)控，全方位胧奔，多角度逊移，每一個層面都很重要预吆×睿總體來說，微服務(wù)可分為 5 個監(jiān)控點(diǎn)：

• 日志監(jiān)控

• Metrics 監(jiān)控

• 健康檢查

• 調(diào)用鏈檢查

• 告警系統(tǒng)

①監(jiān)控架構(gòu)下面的圖是大部分公司的一種監(jiān)控架構(gòu)圖。每一個服務(wù)都有一個 Agent岩遗，Agent 收集到關(guān)鍵信息扇商，會傳到一些 MQ 中，為了解耦宿礁。

同時將日志傳入 ELK案铺，將 Metrics 傳入 InfluxDB 時間序列庫。而像 Nagios梆靖，可以定期向 Agent 發(fā)起信息檢查微服務(wù)控汉。

image

②調(diào)用鏈監(jiān)控 APM

很多公司都有調(diào)用鏈監(jiān)控，就譬如阿里有鷹眼監(jiān)控返吻，點(diǎn)評的 Cat姑子，大部分調(diào)用鏈監(jiān)控（沒錯，我指的 Zipkin）架構(gòu)是這樣的：

image

當(dāng)請求進(jìn)入 Web 容器的時候测僵，會經(jīng)過創(chuàng)建 Tracer街佑，連接 Spans（模擬潛在的分布式工作的延遲，該模塊還包含在系統(tǒng)網(wǎng)絡(luò)間傳遞跟蹤上下文信息的工具包捍靠，如通過 HTTP Headers）沐旨。Spans 有一個上下文，其中包含 Tracer 標(biāo)識符榨婆，將其放在表示分布式操作的樹的正確位置磁携。當(dāng)我們把圖中的各種 Span 放到后端的時候，我們的服務(wù)調(diào)用鏈會動態(tài)的生成調(diào)用鏈良风。下面是一些市場上用的比較多的調(diào)用鏈監(jiān)控對比：

image.png

熔斷颜武、隔離、限流拖吼、降級

面對巨大的突發(fā)流量下鳞上，大型公司一般會采用一系列的熔斷（系統(tǒng)自動將服務(wù)關(guān)閉防止讓出現(xiàn)的問題最大化）、隔離（將服務(wù)和服務(wù)隔離吊档，防止一個服務(wù)掛了其他服務(wù)不能訪問）篙议、限流（單位時間內(nèi)之允許一定數(shù)量用戶訪問）、降級（當(dāng)整個微服務(wù)架構(gòu)整體的負(fù)載超出了預(yù)設(shè)的上限閾值或即將到來的流量預(yù)計(jì)將會超過預(yù)設(shè)的閾值時怠硼，為了保證重要或基本的服務(wù)能正常運(yùn)行鬼贱，我們可以將一些不重要或不緊急的服務(wù)或任務(wù)進(jìn)行服務(wù)的延遲使用或暫停使用）措施。

下面介紹一下 Hystrix 的運(yùn)行流程：

image

每一個微服務(wù)調(diào)用時香璃，都會使用 Hystrix 的 Command 方式（上圖的左上角那個）这难，然后使用 Command 同步的，或者是響應(yīng)式的葡秒，或者是異步的姻乓，判斷電路是否熔斷（順著圖從左往右看）嵌溢，如果斷路則走降級 Fallback。如果這個線閉合著蹋岩，但是線程資源沒了赖草，隊(duì)列滿了，則走限流措施（看圖的第 5 步）剪个。如果走完了秧骑，執(zhí)行成功了，則走 run() 方法扣囊，獲取 Response乎折，但是這個過程如果出錯了，則繼續(xù)走降級 Fallback侵歇。同時笆檀，看圖最上面有一個后綴是 Health 的，這是一個計(jì)算整個鏈路是否健康的組件盒至，每一步操作都被它記錄著酗洒。

容器與服務(wù)編排引擎

從物理機(jī)到虛擬機(jī)，從虛擬機(jī)到容器枷遂；從物理集群到 OpenStack樱衷，OpenStack 到 Kubernetes；科技不斷的變化酒唉，我們的認(rèn)知也沒刷新矩桂。我們從容器開始說起，它首先是一個相對獨(dú)立的運(yùn)行環(huán)境痪伦，在這一點(diǎn)有點(diǎn)類似于虛擬機(jī)侄榴，但是不像虛擬機(jī)那樣徹底。 虛擬機(jī)會將虛擬硬件网沾、內(nèi)核（即操作系統(tǒng)）以及用戶空間打包在新虛擬機(jī)當(dāng)中癞蚕，虛擬機(jī)能夠利用“虛擬機(jī)管理程序”運(yùn)行在物理設(shè)備之上。虛擬機(jī)依賴于 Hypervisor辉哥，其通常被安裝在“裸金屬”系統(tǒng)硬件之上桦山，這導(dǎo)致 Hypervisor 在某些方面被認(rèn)為是一種操作系統(tǒng)。一旦 Hypervisor 安裝完成醋旦， 就可以從系統(tǒng)可用計(jì)算資源當(dāng)中分配虛擬機(jī)實(shí)例了恒水，每臺虛擬機(jī)都能夠獲得唯一的操作系統(tǒng)和負(fù)載（應(yīng)用程序）。簡言之饲齐，虛擬機(jī)先需要虛擬一個物理環(huán)境钉凌，然后構(gòu)建一個完整的操作系統(tǒng)，再搭建一層 Runtime捂人，然后供應(yīng)用程序運(yùn)行御雕。對于容器環(huán)境來說矢沿，不需要安裝主機(jī)操作系統(tǒng)，直接將容器層（比如 LXC 或 Libcontainer）安裝在主機(jī)操作系統(tǒng)（通常是 Linux 變種）之上饮笛。在安裝完容器層之后咨察，就可以從系統(tǒng)可用計(jì)算資源當(dāng)中分配容器實(shí)例了论熙，并且企業(yè)應(yīng)用可以被部署在容器當(dāng)中福青。但是，每個容器化應(yīng)用都會共享相同的操作系統(tǒng)(單個主機(jī)操作系統(tǒng))脓诡。容器可以看成一個裝好了一組特定應(yīng)用的虛擬機(jī)无午，它直接利用了宿主機(jī)的內(nèi)核，抽象層比虛擬機(jī)更少祝谚，更加輕量化宪迟，啟動速度極快。相比于虛擬機(jī)交惯，容器擁有更高的資源使用效率次泽，因?yàn)樗⒉恍枰獮槊總€應(yīng)用分配單獨(dú)的操作系統(tǒng)——實(shí)例規(guī)模更小、創(chuàng)建和遷移速度也更快席爽。這意味著相比于虛擬機(jī)意荤，單個操作系統(tǒng)能夠承載更多的容器。云提供商十分熱衷于容器技術(shù)只锻，因?yàn)樵谙嗤挠布O(shè)備當(dāng)中玖像，可以部署數(shù)量更多的容器實(shí)例。此外齐饮，容器易于遷移捐寥，但是只能被遷移到具有兼容操作系統(tǒng)內(nèi)核的其他服務(wù)器當(dāng)中，這樣就會給遷移選擇帶來限制祖驱。因?yàn)槿萜鞑幌裉摂M機(jī)那樣同樣對內(nèi)核或者虛擬硬件進(jìn)行打包握恳，所以每套容器都擁有自己的隔離化用戶空間，從而使得多套容器能夠運(yùn)行在同一主機(jī)系統(tǒng)之上捺僻。我們可以看到全部操作系統(tǒng)層級的架構(gòu)都可實(shí)現(xiàn)跨容器共享睡互，惟一需要獨(dú)立構(gòu)建的就是二進(jìn)制文件與庫。正因?yàn)槿绱肆晗瘢萜鞑艙碛袠O為出色的輕量化特性就珠。我們最常用的容器是 Docker。①容器編排過去虛擬機(jī)可以通過云平臺 OpenStack 管理虛擬化醒颖，容器時代如何管理容器呢妻怎？這就要看看容器編排引擎了。Apache Mesos：Mesos 是基于 Master泞歉，Slave 架構(gòu)逼侦，框架決定如何利用資源匿辩，Master 負(fù)責(zé)管理機(jī)器，Slave 會定期的將機(jī)器情況報(bào)告給 Master榛丢，Master 再將信息給框架铲球。Master 是高可用的，因?yàn)?ZK晰赞，也有 Leader 的存在稼病。

下面是架構(gòu)圖：

image

Kubernetes：Kubernetes 是最近十分火熱的開源容器編排引擎：

image

Kubernetes 設(shè)計(jì)理念和功能其實(shí)就是一個類似 Linux 的分層架構(gòu)，先說說每一個 Kubernetes 節(jié)點(diǎn)內(nèi)部掖鱼，kubelet 管理全局全局 pod然走，而每一個 pod 承載著一個或多個容器，kube-proxy 負(fù)責(zé)網(wǎng)絡(luò)代理和負(fù)載均衡戏挡。Kubernetes 節(jié)點(diǎn)外部芍瑞，則是對應(yīng)的控制管理服務(wù)器，負(fù)責(zé)統(tǒng)一管理各個節(jié)點(diǎn)調(diào)度分配與運(yùn)行褐墅。②服務(wù)網(wǎng)格化關(guān)于服務(wù)網(wǎng)絡(luò)化拆檬，后面會更加深入的為大家進(jìn)行講解。

資料與文獻(xiàn)：

• 馬丁.福勒對微服務(wù)的描述

• 微服務(wù)架構(gòu)的理論基礎(chǔ) - 康威定律

• 調(diào)用鏈選型之Zipkin妥凳，Pinpoint竟贯，SkyWalking，CAT