微服務(wù)的概念已經(jīng)在各大公司實(shí)踐開(kāi)了，以Java為代表的spring boot成為了微服務(wù)的代表，K8S+Docker成為了微服務(wù)運(yùn)行的最佳環(huán)境，微服務(wù)的概念已經(jīng)離我們沒(méi)有那么遙遠(yuǎn)了。
當(dāng)然微服務(wù)是復(fù)雜的，除了組件繁多還需要代碼做出很多改造才能享受到它帶來(lái)的優(yōu)勢(shì)，那么有沒(méi)有一種方式可以不需要太多代碼改動(dòng)就能夠在多種不同的開(kāi)發(fā)語(yǔ)言中靈活使用呢?
基于服務(wù)網(wǎng)格Istio就誕生了,撥云見(jiàn)日我們今天就來(lái)一同學(xué)習(xí)了解微服務(wù)和Istio相關(guān)的知識(shí).
附上:
喵了個(gè)咪的博客:w-blog.cn
Istio官方地址:https://preliminary.istio.io/zh
Istio中文文檔:https://preliminary.istio.io/zh/docs/
PS : 此處基于當(dāng)前最新istio版本1.0.3版本進(jìn)行搭建和演示，不同的版本各種細(xì)節(jié)會(huì)有些許不同！
一. 微服務(wù)
在開(kāi)始講解Istio之前我們需要先了解微服務(wù)的概念，以及在微服務(wù)管理中常常需要使用到的一些列的組件：
- 服務(wù)注冊(cè)：服務(wù)提供方將自己調(diào)用地址注冊(cè)到服務(wù)注冊(cè)中心，讓服務(wù)調(diào)用方能夠方便地找到自己。
- 服務(wù)發(fā)現(xiàn)：服務(wù)調(diào)用方從服務(wù)注冊(cè)中心找到自己需要調(diào)用的服務(wù)的地址。
- 負(fù)載均衡：服務(wù)提供方一般以多實(shí)例的形式提供服務(wù)，負(fù)載均衡功能能夠讓服務(wù)調(diào)用方連接到合適的服務(wù)節(jié)點(diǎn)。并且，節(jié)點(diǎn)選擇的工作對(duì)服務(wù)調(diào)用方來(lái)說(shuō)是透明的。
- 服務(wù)網(wǎng)關(guān)：服務(wù)網(wǎng)關(guān)是服務(wù)調(diào)用的唯一入口，可以在這個(gè)組件是實(shí)現(xiàn)用戶(hù)鑒權(quán)、動(dòng)態(tài)路由、灰度發(fā)布、A/B 測(cè)試、負(fù)載限流等功能。
- 配置中心：將本地化的配置信息（properties, xml, yaml 等）注冊(cè)到配置中心，實(shí)現(xiàn)程序包在開(kāi)發(fā)、測(cè)試、生產(chǎn)環(huán)境的無(wú)差別性，方便程序包的遷移。
- API 管理：以方便的形式編寫(xiě)及更新 API 文檔，并以方便的形式供調(diào)用者查看和測(cè)試。
- 集成框架：微服務(wù)組件都以職責(zé)單一的程序包對(duì)外提供服務(wù)，集成框架以配置的形式將所有微服務(wù)組件（特別是管理端組件）集成到統(tǒng)一的界面框架下，讓用戶(hù)能夠在統(tǒng)一的界面中使用系統(tǒng)。
- 分布式事務(wù)：對(duì)于重要的業(yè)務(wù)，需要通過(guò)分布式事務(wù)技術(shù)（TCC、高可用消息服務(wù)、最大努力通知）保證數(shù)據(jù)的一致性。
- 調(diào)用鏈：記錄完成一個(gè)業(yè)務(wù)邏輯時(shí)調(diào)用到的微服務(wù)，并將這種串行或并行的調(diào)用關(guān)系展示出來(lái)。在系統(tǒng)出錯(cuò)時(shí)，可以方便地找到出錯(cuò)點(diǎn)。
- 支撐平臺(tái)：系統(tǒng)微服務(wù)化后，系統(tǒng)變得更加碎片化，系統(tǒng)的部署、運(yùn)維、監(jiān)控等都比單體架構(gòu)更加復(fù)雜，那么，就需要將大部分的工作自動(dòng)化?，F(xiàn)在，可以通過(guò) Docker 等工具來(lái)中和這些微服務(wù)架構(gòu)帶來(lái)的弊端。 例如持續(xù)集成、藍(lán)綠發(fā)布、健康檢查、性能健康等等。嚴(yán)重點(diǎn)，以我們兩年的實(shí)踐經(jīng)驗(yàn)，可以這么說(shuō)，如果沒(méi)有合適的支撐平臺(tái)或工具，就不要使用微服務(wù)架構(gòu)。
微服務(wù)架構(gòu)的優(yōu)點(diǎn)：
- 降低系統(tǒng)復(fù)雜度：每個(gè)服務(wù)都比較簡(jiǎn)單，只關(guān)注于一個(gè)業(yè)務(wù)功能。
- 松耦合：微服務(wù)架構(gòu)方式是松耦合的，每個(gè)微服務(wù)可由不同團(tuán)隊(duì)獨(dú)立開(kāi)發(fā)，互不影響。
- 跨語(yǔ)言：只要符合服務(wù) API 契約，開(kāi)發(fā)人員可以自由選擇開(kāi)發(fā)技術(shù)。這就意味著開(kāi)發(fā)人員可以采用新技術(shù)編寫(xiě)或重構(gòu)服務(wù)，由于服務(wù)相對(duì)較小，所以這并不會(huì)對(duì)整體應(yīng)用造成太大影響。
- 獨(dú)立部署：微服務(wù)架構(gòu)可以使每個(gè)微服務(wù)獨(dú)立部署。開(kāi)發(fā)人員無(wú)需協(xié)調(diào)對(duì)服務(wù)升級(jí)或更改的部署。這些更改可以在測(cè)試通過(guò)后立即部署。所以微服務(wù)架構(gòu)也使得 CI／CD 成為可能。
- Docker 容器：和 Docker 容器結(jié)合的更好。
- DDD 領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)：和 DDD 的概念契合，結(jié)合開(kāi)發(fā)會(huì)更好。
微服務(wù)架構(gòu)的缺點(diǎn)：
- 微服務(wù)強(qiáng)調(diào)了服務(wù)大小，但實(shí)際上這并沒(méi)有一個(gè)統(tǒng)一的標(biāo)準(zhǔn)：業(yè)務(wù)邏輯應(yīng)該按照什么規(guī)則劃分為微服務(wù)，這本身就是一個(gè)經(jīng)驗(yàn)工程。有些開(kāi)發(fā)者主張 10-100 行代碼就應(yīng)該建立一個(gè)微服務(wù)。雖然建立小型服務(wù)是微服務(wù)架構(gòu)崇尚的，但要記住，微服務(wù)是達(dá)到目的的手段，而不是目標(biāo)。微服務(wù)的目標(biāo)是充分分解應(yīng)用程序，以促進(jìn)敏捷開(kāi)發(fā)和持續(xù)集成部署。
- 微服務(wù)的分布式特點(diǎn)帶來(lái)的復(fù)雜性：開(kāi)發(fā)人員需要基于 RPC 或者消息實(shí)現(xiàn)微服務(wù)之間的調(diào)用和通信，而這就使得服務(wù)之間的發(fā)現(xiàn)、服務(wù)調(diào)用鏈的跟蹤和質(zhì)量問(wèn)題變得的相當(dāng)棘手。
- 分區(qū)的數(shù)據(jù)庫(kù)體系和分布式事務(wù)：更新多個(gè)業(yè)務(wù)實(shí)體的業(yè)務(wù)交易相當(dāng)普遍，不同服務(wù)可能擁有不同的數(shù)據(jù)庫(kù)。CAP 原理的約束，使得我們不得不放棄傳統(tǒng)的強(qiáng)一致性，而轉(zhuǎn)而追求最終一致性，這個(gè)對(duì)開(kāi)發(fā)人員來(lái)說(shuō)是一個(gè)挑戰(zhàn)。
- 測(cè)試挑戰(zhàn)：傳統(tǒng)的單體WEB應(yīng)用只需測(cè)試單一的 REST API 即可，而對(duì)微服務(wù)進(jìn)行測(cè)試，需要啟動(dòng)它依賴(lài)的所有其他服務(wù)。這種復(fù)雜性不可低估。
- 跨多個(gè)服務(wù)的更改：比如在傳統(tǒng)單體應(yīng)用中，若有 A、B、C 三個(gè)服務(wù)需要更改，A 依賴(lài) B，B 依賴(lài) C。我們只需更改相應(yīng)的模塊，然后一次性部署即可。但是在微服務(wù)架構(gòu)中，我們需要仔細(xì)規(guī)劃和協(xié)調(diào)每個(gè)服務(wù)的變更部署。我們需要先更新 C，然后更新 B，最后更新 A。
- 部署復(fù)雜：微服務(wù)由不同的大量服務(wù)構(gòu)成。每種服務(wù)可能擁有自己的配置、應(yīng)用實(shí)例數(shù)量以及基礎(chǔ)服務(wù)地址。這里就需要不同的配置、部署、擴(kuò)展和監(jiān)控組件。此外，我們還需要服務(wù)發(fā)現(xiàn)機(jī)制，以便服務(wù)可以發(fā)現(xiàn)與其通信的其他服務(wù)的地址。因此，成功部署微服務(wù)應(yīng)用需要開(kāi)發(fā)人員有更好地部署策略和高度自動(dòng)化的水平。
總的來(lái)說(shuō)（問(wèn)題和挑戰(zhàn)）：API Gateway、服務(wù)間調(diào)用、服務(wù)發(fā)現(xiàn)、服務(wù)容錯(cuò)、服務(wù)部署、數(shù)據(jù)調(diào)用以及測(cè)試。
二, 服務(wù)網(wǎng)格
第二點(diǎn)我們需要了解的是服務(wù)網(wǎng)格，Istio 提供了一個(gè)完整的解決方案，通過(guò)為整個(gè)服務(wù)網(wǎng)格提供行為洞察和操作控制來(lái)滿(mǎn)足微服務(wù)應(yīng)用程序的多樣化需求，Service Mesh這個(gè)術(shù)語(yǔ)通常用于描述構(gòu)成這些應(yīng)用程序的微服務(wù)網(wǎng)絡(luò)以及應(yīng)用之間的交互。
隨著規(guī)模和復(fù)雜性的增長(zhǎng)，服務(wù)網(wǎng)格越來(lái)越難以理解和管理。它的需求包括服務(wù)發(fā)現(xiàn)、負(fù)載均衡、故障恢復(fù)、指標(biāo)收集和監(jiān)控以及通常更加復(fù)雜的運(yùn)維需求，例如 A/B 測(cè)試、金絲雀發(fā)布、限流、訪問(wèn)控制和端到端認(rèn)證等。
2017 年底，非侵入式的 Service Mesh 技術(shù)從萌芽到走向了成熟。如果用一句話來(lái)解釋什么是 Service Mesh，可以將它比作是應(yīng)用程序或者說(shuō)微服務(wù)間的 TCP/IP，負(fù)責(zé)服務(wù)之間的網(wǎng)絡(luò)調(diào)用、限流、熔斷和監(jiān)控。對(duì)于編寫(xiě)應(yīng)用程序來(lái)說(shuō)一般無(wú)須關(guān)心 TCP/IP 這一層（比如通過(guò) HTTP 協(xié)議的 RESTful 應(yīng)用），同樣使用 Service Mesh 也就無(wú)須關(guān)系服務(wù)之間的那些原來(lái)是通過(guò)應(yīng)用程序或者其他框架實(shí)現(xiàn)的事情，比如 Spring Cloud、OSS，現(xiàn)在只要交給 Service Mesh 就可以了。
Service Mesh 的來(lái)龍去脈：
- 從最原始的主機(jī)之間直接使用網(wǎng)線相連
- 網(wǎng)絡(luò)層的出現(xiàn)
- 集成到應(yīng)用程序內(nèi)部的控制流
- 分解到應(yīng)用程序外部的控制流
- 應(yīng)用程序的中集成服務(wù)發(fā)現(xiàn)和斷路器
- 出現(xiàn)了專(zhuān)門(mén)用于服務(wù)發(fā)現(xiàn)和斷路器的軟件包/庫(kù)，如 Twitter 的 Finagle 和 Facebook 的 Proxygen，這時(shí)候還是集成在應(yīng)用程序內(nèi)部
- 出現(xiàn)了專(zhuān)門(mén)用于服務(wù)發(fā)現(xiàn)和斷路器的開(kāi)源軟件，如 Netflix OSS、Airbnb 的 synapse 和 nerve
- 最后作為微服務(wù)的中間層 Service Mesh 出現(xiàn)
Service Mesh 有如下幾個(gè)特點(diǎn)：
- 應(yīng)用程序間通訊的中間層
- 輕量級(jí)網(wǎng)絡(luò)代理
- 應(yīng)用程序無(wú)感知
- 解耦應(yīng)用程序的重試/超時(shí)、監(jiān)控、追蹤和服務(wù)發(fā)現(xiàn)
Service Mesh 架構(gòu)圖：
關(guān)于微服務(wù)和服務(wù)網(wǎng)格的區(qū)別，我的一些理解：微服務(wù)更像是一個(gè)服務(wù)之間的生態(tài)，專(zhuān)注于服務(wù)治理等方面，而服務(wù)網(wǎng)格更專(zhuān)注于服務(wù)之間的通信，以及和 DevOps 更好的結(jié)合。
三. Istio
最終萬(wàn)眾期待的Istio誕生了，Istio于 2017 年 5 月 24 日首發(fā)布，由 Google、IBM 和 Lyft 聯(lián)合開(kāi)發(fā)，就在前不久2018年8月份1.0正式版本已經(jīng)發(fā)布，簡(jiǎn)單一句概況就是Istio 允許您連接、保護(hù)、控制和觀測(cè)服務(wù)。
連接
- 智能控制服務(wù)之間的流量和 API 調(diào)用，進(jìn)行一系列測(cè)試，并通過(guò)紅/黑部署逐步升級(jí)。
保護(hù)
- 通過(guò)托管身份驗(yàn)證、授權(quán)和服務(wù)之間通信加密自動(dòng)保護(hù)您的服務(wù)。
控制
- 應(yīng)用策略并確保其執(zhí)行使得資源在消費(fèi)者之間公平分配。
觀測(cè)
- 通過(guò)豐富的自動(dòng)跟蹤、監(jiān)控和記錄所有服務(wù)，了解正在發(fā)生的情況。
PS: 以下內(nèi)容來(lái)自官網(wǎng)文檔
Istio 服務(wù)網(wǎng)格邏輯上分為數(shù)據(jù)平面和控制平面。
數(shù)據(jù)平面由一組以 sidecar 方式部署的智能代理（Envoy）組成。這些代理可以調(diào)節(jié)和控制微服務(wù)及 Mixer 之間所有的網(wǎng)絡(luò)通信。
控制平面負(fù)責(zé)管理和配置代理來(lái)路由流量。此外控制平面配置 Mixer 以實(shí)施策略和收集遙測(cè)數(shù)據(jù)。
下圖顯示了構(gòu)成每個(gè)面板的不同組件：
Envoy
Istio 使用 Envoy 代理的擴(kuò)展版本，Envoy 是以 C++ 開(kāi)發(fā)的高性能代理，用于調(diào)解服務(wù)網(wǎng)格中所有服務(wù)的所有入站和出站流量。Envoy 的許多內(nèi)置功能被 istio 發(fā)揚(yáng)光大，例如：
- 動(dòng)態(tài)服務(wù)發(fā)現(xiàn)
- 負(fù)載均衡
- TLS 終止
- HTTP/2 & gRPC 代理
- 熔斷器
- 健康檢查、基于百分比流量拆分的灰度發(fā)布
- 故障注入
- 豐富的度量指標(biāo)
Envoy 被部署為 sidecar，和對(duì)應(yīng)服務(wù)在同一個(gè) Kubernetes pod 中。這允許 Istio 將大量關(guān)于流量行為的信號(hào)作為屬性提取出來(lái)，而這些屬性又可以在 Mixer 中用于執(zhí)行策略決策，并發(fā)送給監(jiān)控系統(tǒng)，以提供整個(gè)網(wǎng)格行為的信息。
Sidecar 代理模型還可以將 Istio 的功能添加到現(xiàn)有部署中，而無(wú)需重新構(gòu)建或重寫(xiě)代碼。可以閱讀更多來(lái)了解為什么我們?cè)谠O(shè)計(jì)目標(biāo)中選擇這種方式。
Mixer
Mixer 是一個(gè)獨(dú)立于平臺(tái)的組件，負(fù)責(zé)在服務(wù)網(wǎng)格上執(zhí)行訪問(wèn)控制和使用策略，并從 Envoy 代理和其他服務(wù)收集遙測(cè)數(shù)據(jù)。代理提取請(qǐng)求級(jí)屬性，發(fā)送到 Mixer 進(jìn)行評(píng)估。有關(guān)屬性提取和策略評(píng)估的更多信息，請(qǐng)參見(jiàn) Mixer 配置。
Mixer 中包括一個(gè)靈活的插件模型，使其能夠接入到各種主機(jī)環(huán)境和基礎(chǔ)設(shè)施后端，從這些細(xì)節(jié)中抽象出 Envoy 代理和 Istio 管理的服務(wù)。
Pilot
Pilot 為 Envoy sidecar 提供服務(wù)發(fā)現(xiàn)功能，為智能路由（例如 A/B 測(cè)試、金絲雀部署等）和彈性（超時(shí)、重試、熔斷器等）提供流量管理功能。它將控制流量行為的高級(jí)路由規(guī)則轉(zhuǎn)換為特定于 Envoy 的配置，并在運(yùn)行時(shí)將它們傳播到 sidecar。
Pilot 將平臺(tái)特定的服務(wù)發(fā)現(xiàn)機(jī)制抽象化并將其合成為符合 Envoy 數(shù)據(jù)平面 API 的任何 sidecar 都可以使用的標(biāo)準(zhǔn)格式。這種松散耦合使得 Istio 能夠在多種環(huán)境下運(yùn)行（例如，Kubernetes、Consul、Nomad），同時(shí)保持用于流量管理的相同操作界面。
Citadel
Citadel 通過(guò)內(nèi)置身份和憑證管理可以提供強(qiáng)大的服務(wù)間和最終用戶(hù)身份驗(yàn)證。可用于升級(jí)服務(wù)網(wǎng)格中未加密的流量，并為運(yùn)維人員提供基于服務(wù)標(biāo)識(shí)而不是網(wǎng)絡(luò)控制的強(qiáng)制執(zhí)行策略的能力。從 0.5 版本開(kāi)始，Istio 支持基于角色的訪問(wèn)控制，以控制誰(shuí)可以訪問(wèn)您的服務(wù)。
四. 服務(wù)監(jiān)控鏈路監(jiān)控
Istio結(jié)合了鏈路監(jiān)控和服務(wù)監(jiān)控,對(duì)于K8S狀態(tài)監(jiān)控也自然而然也在其中
zipkin + jaeger 來(lái)對(duì)zipkin的數(shù)據(jù)進(jìn)行更加友好的展示
.
PS : 需要實(shí)現(xiàn)鏈路監(jiān)控需要代碼中做出基礎(chǔ)的適配
prometheus + grafana 來(lái)對(duì)prometheus獲取的數(shù)據(jù)進(jìn)行展示監(jiān)控報(bào)警配置
