[導(dǎo)讀]什么是微服務(wù)？ 微服務(wù) Microservices 之父，馬丁.福勒，對(duì)微服務(wù)大概的概述如下： 就目前而言，對(duì)于微服務(wù)業(yè)界并沒(méi)有一個(gè)統(tǒng)一的、標(biāo)準(zhǔn)的定義（While there is no precise definition of this architectural style ) 。 但通常在其而言，微服務(wù)架構(gòu)是一種架構(gòu)
什么是微服務(wù)？
微服務(wù) Microservices 之父，馬丁.福勒，對(duì)微服務(wù)大概的概述如下：
就目前而言，對(duì)于微服務(wù)業(yè)界并沒(méi)有一個(gè)統(tǒng)一的、標(biāo)準(zhǔn)的定義（While there is no precise definition of this architectural style ) 。
但通常在其而言，微服務(wù)架構(gòu)是一種架構(gòu)模式或者說(shuō)是一種架構(gòu)風(fēng)格，它提倡將單一應(yīng)用程序劃分成一組小的服務(wù)，每個(gè)服務(wù)運(yùn)行獨(dú)立的自己的進(jìn)程中，服務(wù)之間互相協(xié)調(diào)、互相配合，為用戶提供最終價(jià)值。
服務(wù)之間采用輕量級(jí)的通信機(jī)制互相溝通（通常是基于 HTTP 的 RESTful API ) 。每個(gè)服務(wù)都圍繞著具體業(yè)務(wù)進(jìn)行構(gòu)建，并且能夠被獨(dú)立地部署到生產(chǎn)環(huán)境、類生產(chǎn)環(huán)境等。
另外，應(yīng)盡量避免統(tǒng)一的、集中式的服務(wù)管理機(jī)制，對(duì)具體的一個(gè)服務(wù)而言，應(yīng)根據(jù)業(yè)務(wù)上下文，選擇合適的語(yǔ)言、工具對(duì)其進(jìn)行構(gòu)建，可以有一個(gè)非常輕量級(jí)的集中式管理來(lái)協(xié)調(diào)這些服務(wù)。可以使用不同的語(yǔ)言來(lái)編寫(xiě)服務(wù)，也可以使用不同的數(shù)據(jù)存儲(chǔ)。
根據(jù)馬丁.福勒的描述，我總結(jié)了以下幾點(diǎn)：
①小服務(wù)
小服務(wù)，沒(méi)有特定的標(biāo)準(zhǔn)或者規(guī)范，但他在總體規(guī)范上一定是小的。
②進(jìn)程獨(dú)立
每一組服務(wù)都是獨(dú)立運(yùn)行的，可能我這個(gè)服務(wù)運(yùn)行在 Tomcat 容器，而另一個(gè)服務(wù)運(yùn)行在 Jetty 上。可以通過(guò)進(jìn)程方式，不斷的橫向擴(kuò)展整個(gè)服務(wù)。
③通信
過(guò)去的協(xié)議都是很重的，就像 ESB，就像 SOAP，輕通信，這意味著相比過(guò)去更智能更輕量的服務(wù)相互調(diào)用，就所謂 smart endpoints and dumb pipes。
這些 Endpoint 都是解耦的，完成一個(gè)業(yè)務(wù)通信調(diào)用串起這些 Micro Service 就像是 Linux 系統(tǒng)中通過(guò)管道串起一系列命令業(yè)務(wù)。
過(guò)去的業(yè)務(wù)，我們通常會(huì)考慮各種各樣的依賴關(guān)系，考慮系統(tǒng)耦合帶來(lái)的問(wèn)題。微服務(wù)，可以讓開(kāi)發(fā)者更專注于業(yè)務(wù)的邏輯開(kāi)發(fā)。
④部署
不止業(yè)務(wù)要獨(dú)立，部署也要獨(dú)立。不過(guò)這也意味著，傳統(tǒng)的開(kāi)發(fā)流程會(huì)出現(xiàn)一定程度的改變，開(kāi)發(fā)的適合也要有一定的運(yùn)維職責(zé)。
⑤管理
傳統(tǒng)的企業(yè)級(jí) SOA 服務(wù)往往很大，不易于管理，耦合性高，團(tuán)隊(duì)開(kāi)發(fā)成本比較大。
微服務(wù)，可以讓團(tuán)隊(duì)各思其政的選擇技術(shù)實(shí)現(xiàn)，不同的 Service 可以根據(jù)各自的需要選擇不同的技術(shù)棧來(lái)實(shí)現(xiàn)其業(yè)務(wù)邏輯。
微服務(wù)的利與弊
為什么用微服務(wù)呢？因?yàn)楹猛妫?/span>不是的。下面是我從網(wǎng)絡(luò)上找到說(shuō)的比較全的優(yōu)點(diǎn)：
-
優(yōu)點(diǎn)是每個(gè)服務(wù)足夠內(nèi)聚，足夠小，代碼容易理解這樣能聚焦一個(gè)指定的業(yè)務(wù)功能或業(yè)務(wù)需求。
-
開(kāi)發(fā)簡(jiǎn)單、開(kāi)發(fā)效率提高，一個(gè)服務(wù)可能就是專一的只干一件事。
-
微服務(wù)能夠被小團(tuán)隊(duì)單獨(dú)開(kāi)發(fā)，這個(gè)小團(tuán)隊(duì)是 2 到 5 人的開(kāi)發(fā)人員組成。
-
微服務(wù)是松耦合的，是有功能意義的服務(wù)，無(wú)論是在開(kāi)發(fā)階段或部署階段都是獨(dú)立的。
-
微服務(wù)能使用不同的語(yǔ)言開(kāi)發(fā)。
-
易于和第三方集成，微服務(wù)允許容易且靈活的方式集成自動(dòng)部署，通過(guò)持續(xù)集成工具，如 Jenkins，Hudson，bamboo。
-
微服務(wù)易于被一個(gè)開(kāi)發(fā)人員理解，修改和維護(hù)，這樣小團(tuán)隊(duì)能夠更關(guān)注自己的工作成果。無(wú)需通過(guò)合作才能體現(xiàn)價(jià)值。微服務(wù)允許你利用融合最新技術(shù)。
-
微服務(wù)只是業(yè)務(wù)邏輯的代碼，不會(huì)和 HTML，CSS 或其他界面組件混合。
-
每個(gè)微服務(wù)都有自己的存儲(chǔ)能力，可以有自己的數(shù)據(jù)庫(kù)，也可以有統(tǒng)一數(shù)據(jù)庫(kù)。
總的來(lái)說(shuō)，微服務(wù)的優(yōu)勢(shì)，就是在于，面對(duì)大的系統(tǒng)，可以有效的減少?gòu)?fù)雜程度，使服務(wù)架構(gòu)的邏輯更清晰明了。
但是這樣也會(huì)帶來(lái)很多問(wèn)題，就譬如分布式環(huán)境下的數(shù)據(jù)一致性，測(cè)試的復(fù)雜性，運(yùn)維的復(fù)雜性。
什么組織適合使用微服務(wù)？
微服務(wù)帶了種種優(yōu)點(diǎn)，種種弊端，那么什么組織適合使用微服務(wù)？
①墨菲定律（設(shè)計(jì)系統(tǒng)）和康威定律（系統(tǒng)劃分）
康威定律，是一個(gè)五十多年前就被提出來(lái)的微服務(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ì)，就能形象生動(dòng)的理解這句話。
感興趣的各位可以研究一下！
②架構(gòu)演化
架構(gòu)是不斷演化出來(lái)的，微服務(wù)也是這樣，當(dāng)從各大科技公司，規(guī)模大到一定程度，完全需要演化成更進(jìn)一步管理的技術(shù)架構(gòu)體系。
傳統(tǒng)的團(tuán)隊(duì)，都是面向過(guò)程化的，產(chǎn)品想完了去找策劃，策劃完了找開(kāi)發(fā)，接著順著一步一步找。
我們做技術(shù)都是為了產(chǎn)品的，一旦過(guò)程出來(lái)了什么問(wèn)題，回溯尋找問(wèn)題會(huì)非常耗時(shí)。
使用了微服務(wù)架構(gòu)體系，團(tuán)隊(duì)組織方式需要轉(zhuǎn)變成跨職能團(tuán)隊(duì)，即每個(gè)團(tuán)隊(duì)都有產(chǎn)品專家，策劃專家，開(kāi)發(fā)專家，運(yùn)維專家，他們使用 API 方式發(fā)布他們的功能，而平臺(tái)使用他們的功能發(fā)布產(chǎn)品。
微服務(wù)技術(shù)架構(gòu)體系
下面我分享一下大部分公司都使用的微服務(wù)技術(shù)架構(gòu)體系：
服務(wù)發(fā)現(xiàn)
主流的服務(wù)發(fā)現(xiàn)，分為三種：
第一種，開(kāi)發(fā)人員開(kāi)發(fā)了程序以后，會(huì)找運(yùn)維配一個(gè)域名，服務(wù)的話通過(guò) DNS 就能找到我們對(duì)應(yīng)的服務(wù)。
缺點(diǎn)是，由于服務(wù)沒(méi)有負(fù)載均衡功能，對(duì)負(fù)載均衡服務(wù)，可能會(huì)有相當(dāng)大的性能問(wèn)題。
第二種，是目前普遍的做法。可以參考 Zuul 網(wǎng)關(guān)，每一個(gè)服務(wù)都通過(guò)服務(wù)端內(nèi)置的功能注冊(cè)到注冊(cè)中心，服務(wù)消費(fèi)者不斷輪詢注冊(cè)中心發(fā)現(xiàn)對(duì)應(yīng)的服務(wù)，使用內(nèi)置負(fù)載均衡調(diào)用服務(wù)。
缺點(diǎn)是，對(duì)多語(yǔ)言環(huán)境不是很好，你需要單獨(dú)給消費(fèi)者的客戶端開(kāi)發(fā)服務(wù)發(fā)現(xiàn)和負(fù)載均衡功能。當(dāng)然了，這個(gè)方法通常都是用在 Spring Cloud 上的。
第三種，是將客戶端和負(fù)載均衡放在同一個(gè)主機(jī)，而不是同一個(gè)進(jìn)程內(nèi)。
這種方法相對(duì)第一種第二種方法來(lái)說(shuō)，改善了他們的缺點(diǎn)，但是會(huì)極大增加運(yùn)維成本。
網(wǎng)關(guān)
微服務(wù)的網(wǎng)關(guān)是什么？ 我們可以聯(lián)系生活實(shí)際想一下。每一個(gè)大的公司，都會(huì)有一偏屬于自己的建筑區(qū)，而這建筑區(qū)內(nèi)，都有不少的門(mén)衛(wèi)。如果有外來(lái)人員進(jìn)入公司，會(huì)先和門(mén)衛(wèi)打好招呼，才能進(jìn)去。
將生活實(shí)際聯(lián)系到微服務(wù)上，就不難理解網(wǎng)關(guān)的意思了：
網(wǎng)關(guān)的作用如下：
-
反向路由：很多時(shí)候，公司不想讓外部人員看到我們公司的內(nèi)部，就需要網(wǎng)關(guān)來(lái)進(jìn)行反向路由。即將外部請(qǐng)求轉(zhuǎn)換成內(nèi)部具體服務(wù)調(diào)用。
-
安全認(rèn)證：網(wǎng)絡(luò)中會(huì)有很多惡意訪問(wèn)，譬如爬蟲(chóng)，譬如黑客攻擊，網(wǎng)關(guān)維護(hù)安全功能。
-
限流熔斷：當(dāng)請(qǐng)求很多服務(wù)不堪重負(fù)，會(huì)讓我們的服務(wù)自動(dòng)關(guān)閉，導(dǎo)致不能用服務(wù)。限流熔斷可以有效的避免這類問(wèn)題。
-
日志監(jiān)控：所有的外面的請(qǐng)求都會(huì)經(jīng)過(guò)網(wǎng)關(guān)，這樣我們就可以使用網(wǎng)關(guān)來(lái)記錄日志信息。
-
灰度發(fā)布，藍(lán)綠部署。是指能夠平滑過(guò)渡的一種發(fā)布方式。在其上可以進(jìn)行 A/B testing。
即讓一部分用戶繼續(xù)用產(chǎn)品特性 A，一部分用戶開(kāi)始用產(chǎn)品特性 B，如果用戶對(duì) B 沒(méi)有什么反對(duì)意見(jiàn)，那么逐步擴(kuò)大范圍，把所有用戶都遷移到 B 上面來(lái)。
開(kāi)源網(wǎng)關(guān) Zuul 架構(gòu)：
Zuul 網(wǎng)關(guān)核心其實(shí)是一個(gè) Servlet，所有請(qǐng)求都會(huì)經(jīng)過(guò) Zuul Servlet 傳到 ZuulFilter Runner，然后分發(fā)到三種過(guò)濾器。
先說(shuō)說(shuō)架構(gòu)圖左半部分，分別是使用 Groovy 實(shí)現(xiàn)的前置路由過(guò)濾器，路由過(guò)濾器，后置路由過(guò)濾器。
一般請(qǐng)求都會(huì)先經(jīng)過(guò)前置路由過(guò)濾器處理，一般的自定義 Java 封裝邏輯也會(huì)在這里實(shí)現(xiàn)。
路由過(guò)濾器，實(shí)現(xiàn)的是找到對(duì)應(yīng)的微服務(wù)進(jìn)行調(diào)用。 調(diào)用完了，響應(yīng)回來(lái)，會(huì)經(jīng)過(guò)后置路由過(guò)濾器，通過(guò)后置路由過(guò)濾器我們可以封裝日志審計(jì)的處理。
可以說(shuō) Zuul 網(wǎng)關(guān)最大的特色就是它的三層過(guò)濾器。 架構(gòu)圖右半部分，是 Zuul 網(wǎng)關(guān)設(shè)計(jì)的自定義過(guò)濾器加載機(jī)制。
網(wǎng)關(guān)內(nèi)部會(huì)有生產(chǎn)者消費(fèi)者模型，自動(dòng)的將過(guò)濾器腳本發(fā)布到 Zuul 網(wǎng)關(guān)讀取加載運(yùn)行。
配置中心
以前，開(kāi)發(fā)人員把配置文件放在開(kāi)發(fā)文件里面，這樣會(huì)有很多隱患。譬如，配置規(guī)范不同，無(wú)法追溯配置人員。
一旦需要大規(guī)模改動(dòng)配置，改動(dòng)時(shí)間會(huì)很長(zhǎng)，無(wú)法追溯配置人員，從而影響整個(gè)產(chǎn)品，后果是我們承擔(dān)不起的。
因此就有配置中心這個(gè)嘍！ 現(xiàn)在的開(kāi)源中心有百度配置中心 Disconf，Spring Cloud Config，Apollo。
今天重點(diǎn)說(shuō)說(shuō)現(xiàn)在應(yīng)用質(zhì)量不錯(cuò)的配置中心，攜程開(kāi)源的阿波羅（Apollo）：
Apollo 的配置中心規(guī)模比較大，本地應(yīng)用會(huì)有響應(yīng)的配置中心客戶端，可以定時(shí)同步配置中心里的配置。如果配置中心怠機(jī)，會(huì)使用緩存來(lái)進(jìn)行配置。
通訊方式
關(guān)于通訊方式，一般市面也就是兩種遠(yuǎn)程調(diào)用方式，我整理了一個(gè)表格：
監(jiān)控預(yù)警
監(jiān)控預(yù)警對(duì)于微服務(wù)很重要，一個(gè)可靠的監(jiān)控預(yù)警體系對(duì)微服務(wù)運(yùn)行至關(guān)重要。
一般監(jiān)控分為如下層次：
從基礎(chǔ)設(shè)施到用戶端，層層有監(jiān)控，全方位，多角度，每一個(gè)層面都很重要。
總體來(lái)說(shuō)，微服務(wù)可分為 5 個(gè)監(jiān)控點(diǎn)：
-
日志監(jiān)控
-
Metrics 監(jiān)控
-
健康檢查
-
調(diào)用鏈檢查
-
告警系統(tǒng)
①監(jiān)控架構(gòu)
下面的圖是大部分公司的一種監(jiān)控架構(gòu)圖。每一個(gè)服務(wù)都有一個(gè) Agent，Agent 收集到關(guān)鍵信息，會(huì)傳到一些 MQ 中，為了解耦。
同時(shí)將日志傳入 ELK，將 Metrics 傳入 InfluxDB 時(shí)間序列庫(kù)。而像 Nagios，可以定期向 Agent 發(fā)起信息檢查微服務(wù)。
②調(diào)用鏈監(jiān)控 APM
很多公司都有調(diào)用鏈監(jiān)控，就譬如阿里有鷹眼監(jiān)控，點(diǎn)評(píng)的 Cat，大部分調(diào)用鏈監(jiān)控（沒(méi)錯(cuò)，我指的 Zipkin）架構(gòu)是這樣的：
當(dāng)請(qǐng)求進(jìn)入 Web 容器的時(shí)候，會(huì)經(jīng)過(guò)創(chuàng)建 Tracer，連接 Spans（模擬潛在的分布式工作的延遲，該模塊還包含在系統(tǒng)網(wǎng)絡(luò)間傳遞跟蹤上下文信息的工具包，如通過(guò) HTTP Headers）。
Spans 有一個(gè)上下文，其中包含 Tracer 標(biāo)識(shí)符，將其放在表示分布式操作的樹(shù)的正確位置。
當(dāng)我們把圖中的各種 Span 放到后端的時(shí)候，我們的服務(wù)調(diào)用鏈會(huì)動(dòng)態(tài)的生成調(diào)用鏈。
下面是一些市場(chǎng)上用的比較多的調(diào)用鏈監(jiān)控對(duì)比：
熔斷、隔離、限流、降級(jí)
面對(duì)巨大的突發(fā)流量下，大型公司一般會(huì)采用一系列的熔斷（系統(tǒng)自動(dòng)將服務(wù)關(guān)閉防止讓出現(xiàn)的問(wèn)題最大化）、隔離（將服務(wù)和服務(wù)隔離，防止一個(gè)服務(wù)掛了其他服務(wù)不能訪問(wèn)）、限流（單位時(shí)間內(nèi)之允許一定數(shù)量用戶訪問(wèn)）、降級(jí)（當(dāng)整個(gè)微服務(wù)架構(gòu)整體的負(fù)載超出了預(yù)設(shè)的上限閾值或即將到來(lái)的流量預(yù)計(jì)將會(huì)超過(guò)預(yù)設(shè)的閾值時(shí)，為了保證重要或基本的服務(wù)能正常運(yùn)行，我們可以將一些不重要或不緊急的服務(wù)或任務(wù)進(jìn)行服務(wù)的延遲使用或暫停使用）措施。
下面介紹一下 Hystrix 的運(yùn)行流程：
每一個(gè)微服務(wù)調(diào)用時(shí)，都會(huì)使用 Hystrix 的 Command 方式（上圖的左上角那個(gè)），然后使用 Command 同步的，或者是響應(yīng)式的，或者是異步的，判斷電路是否熔斷（順著圖從左往右看），如果斷路則走降級(jí) Fallback。
如果這個(gè)線閉合著，但是線程資源沒(méi)了，隊(duì)列滿了，則走限流措施（看圖的第 5 步）。
如果走完了，執(zhí)行成功了，則走 run() 方法，獲取 Response，但是這個(gè)過(guò)程如果出錯(cuò)了，則繼續(xù)走降級(jí) Fallback。
同時(shí)，看圖最上面有一個(gè)后綴是 Health 的，這是一個(gè)計(jì)算整個(gè)鏈路是否健康的組件，每一步操作都被它記錄著。
容器與服務(wù)編排引擎
從物理機(jī)到虛擬機(jī)，從虛擬機(jī)到容器；從物理集群到 OpenStack，OpenStack 到 Kubernetes；科技不斷的變化，我們的認(rèn)知也沒(méi)刷新。
我們從容器開(kāi)始說(shuō)起，它首先是一個(gè)相對(duì)獨(dú)立的運(yùn)行環(huán)境，在這一點(diǎn)有點(diǎn)類似于虛擬機(jī)，但是不像虛擬機(jī)那樣徹底。
虛擬機(jī)會(huì)將虛擬硬件、內(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í)例了，每臺(tái)虛擬機(jī)都能夠獲得唯一的操作系統(tǒng)和負(fù)載（應(yīng)用程序）。
簡(jiǎn)言之，虛擬機(jī)先需要虛擬一個(gè)物理環(huán)境，然后構(gòu)建一個(gè)完整的操作系統(tǒng)，再搭建一層 Runtime，然后供應(yīng)用程序運(yùn)行。
對(duì)于容器環(huán)境來(lái)說(shuō)，不需要安裝主機(jī)操作系統(tǒng)，直接將容器層（比如 LXC 或 Libcontainer）安裝在主機(jī)操作系統(tǒng)（通常是 Linux 變種）之上。
在安裝完容器層之后，就可以從系統(tǒng)可用計(jì)算資源當(dāng)中分配容器實(shí)例了，并且企業(yè)應(yīng)用可以被部署在容器當(dāng)中。
但是，每個(gè)容器化應(yīng)用都會(huì)共享相同的操作系統(tǒng)(單個(gè)主機(jī)操作系統(tǒng))。容器可以看成一個(gè)裝好了一組特定應(yīng)用的虛擬機(jī)，它直接利用了宿主機(jī)的內(nèi)核，抽象層比虛擬機(jī)更少，更加輕量化，啟動(dòng)速度極快。
相比于虛擬機(jī)，容器擁有更高的資源使用效率，因?yàn)樗⒉恍枰獮槊總€(gè)應(yīng)用分配單獨(dú)的操作系統(tǒng)——實(shí)例規(guī)模更小、創(chuàng)建和遷移速度也更快。這意味著相比于虛擬機(jī)，單個(gè)操作系統(tǒng)能夠承載更多的容器。
云提供商十分熱衷于容器技術(shù)，因?yàn)樵谙嗤挠布O(shè)備當(dāng)中，可以部署數(shù)量更多的容器實(shí)例。
此外，容器易于遷移，但是只能被遷移到具有兼容操作系統(tǒng)內(nèi)核的其他服務(wù)器當(dāng)中，這樣就會(huì)給遷移選擇帶來(lái)限制。
因?yàn)槿萜鞑幌裉摂M機(jī)那樣同樣對(duì)內(nèi)核或者虛擬硬件進(jìn)行打包，所以每套容器都擁有自己的隔離化用戶空間，從而使得多套容器能夠運(yùn)行在同一主機(jī)系統(tǒng)之上。
我們可以看到全部操作系統(tǒng)層級(jí)的架構(gòu)都可實(shí)現(xiàn)跨容器共享，惟一需要獨(dú)立構(gòu)建的就是二進(jìn)制文件與庫(kù)。
正因?yàn)槿绱?，容器才擁有極為出色的輕量化特性。 我們最常用的容器是 Docker。
①容器編排
過(guò)去虛擬機(jī)可以通過(guò)云平臺(tái) OpenStack 管理虛擬化，容器時(shí)代如何管理容器呢？這就要看看容器編排引擎了。
Apache Mesos： Mesos 是基于 Master，Slave 架構(gòu)，框架決定如何利用資源，Master 負(fù)責(zé)管理機(jī)器，Slave 會(huì)定期的將機(jī)器情況報(bào)告給 Master，Master 再將信息給框架。Master 是高可用的，因?yàn)?ZK，也有 Leader 的存在。
下面是架構(gòu)圖：
Kubernetes： Kubernetes 是最近十分火熱的開(kāi)源容器編排引擎：
Kubernetes 設(shè)計(jì)理念和功能其實(shí)就是一個(gè)類似 Linux 的分層架構(gòu)，先說(shuō)說(shuō)每一個(gè) Kubernetes 節(jié)點(diǎn)內(nèi)部，kubelet 管理全局全局 pod，而每一個(gè) pod 承載著一個(gè)或多個(gè)容器，kube-proxy 負(fù)責(zé)網(wǎng)絡(luò)代理和負(fù)載均衡。
Kubernetes 節(jié)點(diǎn)外部，則是對(duì)應(yīng)的控制管理服務(wù)器，負(fù)責(zé)統(tǒng)一管理各個(gè)節(jié)點(diǎn)調(diào)度分配與運(yùn)行。
②服務(wù)網(wǎng)格化
關(guān)于服務(wù)網(wǎng)絡(luò)化，后面會(huì)更加深入的為大家進(jìn)行講解。
資料與文獻(xiàn)：
作者： tengshe789，本文版權(quán)歸作者所有
https://juejin.im/post/5c0ba2bef265da614d08fefe
特別推薦一個(gè)分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒(méi)關(guān)注的小伙伴，可以長(zhǎng)按關(guān)注一下：
長(zhǎng)按訂閱更多精彩▼
如有收獲，點(diǎn)個(gè)在看，誠(chéng)摯感謝
免責(zé)聲明：本文內(nèi)容由21ic獲得授權(quán)后發(fā)布，版權(quán)歸原作者所有，本平臺(tái)僅提供信息存儲(chǔ)服務(wù)。文章僅代表作者個(gè)人觀點(diǎn)，不代表本平臺(tái)立場(chǎng)，如有問(wèn)題，請(qǐng)聯(lián)系我們，謝謝！
欲知詳情，請(qǐng)下載word文檔
下載文檔
本站聲明： 本文章由作者或相關(guān)機(jī)構(gòu)授權(quán)發(fā)布，目的在于傳遞更多信息，并不代表本站贊同其觀點(diǎn)，本站亦不保證或承諾內(nèi)容真實(shí)性等。需要轉(zhuǎn)載請(qǐng)聯(lián)系該專欄作者，如若文章內(nèi)容侵犯您的權(quán)益，請(qǐng)及時(shí)聯(lián)系本站刪除。
