image

微服務(wù)的概念已經(jīng)在各大公司實踐開了怀大，以Java為代表的spring boot成為了微服務(wù)的代表凡简，K8S+Docker成為了微服務(wù)運(yùn)行的最佳環(huán)境逼友，微服務(wù)的概念已經(jīng)離我們沒有那么遙遠(yuǎn)了。

當(dāng)然微服務(wù)是復(fù)雜的秤涩，除了組件繁多還需要代碼做出很多改造才能享受到它帶來的優(yōu)勢帜乞，那么有沒有一種方式可以不需要太多代碼改動就能夠在多種不同的開發(fā)語言中靈活使用呢?

基于服務(wù)網(wǎng)格Istio就誕生了,撥云見日我們今天就來一同學(xué)習(xí)了解微服務(wù)和Istio相關(guān)的知識.

附上:

喵了個咪的博客: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é)會有些許不同筐眷！

一. 微服務(wù)

在開始講解Istio之前我們需要先了解微服務(wù)的概念黎烈，以及在微服務(wù)管理中常常需要使用到的一些列的組件：

image

• 服務(wù)注冊：服務(wù)提供方將自己調(diào)用地址注冊到服務(wù)注冊中心，讓服務(wù)調(diào)用方能夠方便地找到自己匀谣。
• 服務(wù)發(fā)現(xiàn)：服務(wù)調(diào)用方從服務(wù)注冊中心找到自己需要調(diào)用的服務(wù)的地址照棋。
• 負(fù)載均衡：服務(wù)提供方一般以多實例的形式提供服務(wù)，負(fù)載均衡功能能夠讓服務(wù)調(diào)用方連接到合適的服務(wù)節(jié)點(diǎn)武翎。并且烈炭，節(jié)點(diǎn)選擇的工作對服務(wù)調(diào)用方來說是透明的。
• 服務(wù)網(wǎng)關(guān)：服務(wù)網(wǎng)關(guān)是服務(wù)調(diào)用的唯一入口宝恶，可以在這個組件是實現(xiàn)用戶鑒權(quán)符隙、動態(tài)路由、灰度發(fā)布垫毙、A/B 測試霹疫、負(fù)載限流等功能。
• 配置中心：將本地化的配置信息（properties, xml, yaml 等）注冊到配置中心露久，實現(xiàn)程序包在開發(fā)更米、測試欺栗、生產(chǎn)環(huán)境的無差別性毫痕，方便程序包的遷移。
• API 管理：以方便的形式編寫及更新 API 文檔迟几，并以方便的形式供調(diào)用者查看和測試消请。
• 集成框架：微服務(wù)組件都以職責(zé)單一的程序包對外提供服務(wù)，集成框架以配置的形式將所有微服務(wù)組件（特別是管理端組件）集成到統(tǒng)一的界面框架下类腮，讓用戶能夠在統(tǒng)一的界面中使用系統(tǒng)臊泰。
• 分布式事務(wù)：對于重要的業(yè)務(wù)，需要通過分布式事務(wù)技術(shù)（TCC蚜枢、高可用消息服務(wù)缸逃、最大努力通知）保證數(shù)據(jù)的一致性针饥。
• 調(diào)用鏈：記錄完成一個業(yè)務(wù)邏輯時調(diào)用到的微服務(wù)，并將這種串行或并行的調(diào)用關(guān)系展示出來需频。在系統(tǒng)出錯時丁眼，可以方便地找到出錯點(diǎn)。
• 支撐平臺：系統(tǒng)微服務(wù)化后昭殉，系統(tǒng)變得更加碎片化苞七，系統(tǒng)的部署、運(yùn)維挪丢、監(jiān)控等都比單體架構(gòu)更加復(fù)雜蹂风，那么，就需要將大部分的工作自動化∏睿現(xiàn)在惠啄，可以通過 Docker 等工具來中和這些微服務(wù)架構(gòu)帶來的弊端。 例如持續(xù)集成任内、藍(lán)綠發(fā)布礁阁、健康檢查、性能健康等等族奢。嚴(yán)重點(diǎn)姥闭，以我們兩年的實踐經(jīng)驗，可以這么說越走，如果沒有合適的支撐平臺或工具棚品，就不要使用微服務(wù)架構(gòu)。

微服務(wù)架構(gòu)的優(yōu)點(diǎn)：

• 降低系統(tǒng)復(fù)雜度：每個服務(wù)都比較簡單廊敌，只關(guān)注于一個業(yè)務(wù)功能铜跑。
• 松耦合：微服務(wù)架構(gòu)方式是松耦合的，每個微服務(wù)可由不同團(tuán)隊獨(dú)立開發(fā)骡澈，互不影響锅纺。
• 跨語言：只要符合服務(wù) API 契約，開發(fā)人員可以自由選擇開發(fā)技術(shù)肋殴。這就意味著開發(fā)人員可以采用新技術(shù)編寫或重構(gòu)服務(wù)囤锉，由于服務(wù)相對較小，所以這并不會對整體應(yīng)用造成太大影響护锤。
• 獨(dú)立部署：微服務(wù)架構(gòu)可以使每個微服務(wù)獨(dú)立部署官地。開發(fā)人員無需協(xié)調(diào)對服務(wù)升級或更改的部署。這些更改可以在測試通過后立即部署烙懦。所以微服務(wù)架構(gòu)也使得 CI／CD 成為可能驱入。
• Docker 容器：和 Docker 容器結(jié)合的更好。
• DDD 領(lǐng)域驅(qū)動設(shè)計：和 DDD 的概念契合，結(jié)合開發(fā)會更好亏较。

微服務(wù)架構(gòu)的缺點(diǎn)：

• 微服務(wù)強(qiáng)調(diào)了服務(wù)大小莺褒，但實際上這并沒有一個統(tǒng)一的標(biāo)準(zhǔn)：業(yè)務(wù)邏輯應(yīng)該按照什么規(guī)則劃分為微服務(wù)，這本身就是一個經(jīng)驗工程雪情。有些開發(fā)者主張 10-100 行代碼就應(yīng)該建立一個微服務(wù)癣朗。雖然建立小型服務(wù)是微服務(wù)架構(gòu)崇尚的，但要記住旺罢，微服務(wù)是達(dá)到目的的手段旷余，而不是目標(biāo)。微服務(wù)的目標(biāo)是充分分解應(yīng)用程序扁达，以促進(jìn)敏捷開發(fā)和持續(xù)集成部署正卧。
• 微服務(wù)的分布式特點(diǎn)帶來的復(fù)雜性：開發(fā)人員需要基于 RPC 或者消息實現(xiàn)微服務(wù)之間的調(diào)用和通信，而這就使得服務(wù)之間的發(fā)現(xiàn)跪解、服務(wù)調(diào)用鏈的跟蹤和質(zhì)量問題變得的相當(dāng)棘手炉旷。
• 分區(qū)的數(shù)據(jù)庫體系和分布式事務(wù)：更新多個業(yè)務(wù)實體的業(yè)務(wù)交易相當(dāng)普遍，不同服務(wù)可能擁有不同的數(shù)據(jù)庫叉讥。CAP 原理的約束窘行，使得我們不得不放棄傳統(tǒng)的強(qiáng)一致性，而轉(zhuǎn)而追求最終一致性图仓，這個對開發(fā)人員來說是一個挑戰(zhàn)罐盔。
• 測試挑戰(zhàn)：傳統(tǒng)的單體WEB應(yīng)用只需測試單一的 REST API 即可，而對微服務(wù)進(jìn)行測試救崔，需要啟動它依賴的所有其他服務(wù)惶看。這種復(fù)雜性不可低估。
• 跨多個服務(wù)的更改：比如在傳統(tǒng)單體應(yīng)用中六孵，若有 A纬黎、B、C 三個服務(wù)需要更改劫窒，A 依賴 B本今，B 依賴 C。我們只需更改相應(yīng)的模塊主巍，然后一次性部署即可冠息。但是在微服務(wù)架構(gòu)中，我們需要仔細(xì)規(guī)劃和協(xié)調(diào)每個服務(wù)的變更部署煤禽。我們需要先更新 C铐达，然后更新 B，最后更新 A檬果。
• 部署復(fù)雜：微服務(wù)由不同的大量服務(wù)構(gòu)成。每種服務(wù)可能擁有自己的配置、應(yīng)用實例數(shù)量以及基礎(chǔ)服務(wù)地址选脊。這里就需要不同的配置杭抠、部署、擴(kuò)展和監(jiān)控組件恳啥。此外偏灿，我們還需要服務(wù)發(fā)現(xiàn)機(jī)制，以便服務(wù)可以發(fā)現(xiàn)與其通信的其他服務(wù)的地址钝的。因此翁垂，成功部署微服務(wù)應(yīng)用需要開發(fā)人員有更好地部署策略和高度自動化的水平。

總的來說（問題和挑戰(zhàn)）：API Gateway硝桩、服務(wù)間調(diào)用沿猜、服務(wù)發(fā)現(xiàn)、服務(wù)容錯碗脊、服務(wù)部署啼肩、數(shù)據(jù)調(diào)用以及測試。

二, 服務(wù)網(wǎng)格

第二點(diǎn)我們需要了解的是服務(wù)網(wǎng)格衙伶，Istio 提供了一個完整的解決方案祈坠，通過為整個服務(wù)網(wǎng)格提供行為洞察和操作控制來滿足微服務(wù)應(yīng)用程序的多樣化需求，Service Mesh這個術(shù)語通常用于描述構(gòu)成這些應(yīng)用程序的微服務(wù)網(wǎng)絡(luò)以及應(yīng)用之間的交互矢劲。

隨著規(guī)模和復(fù)雜性的增長赦拘，服務(wù)網(wǎng)格越來越難以理解和管理。它的需求包括服務(wù)發(fā)現(xiàn)芬沉、負(fù)載均衡另绩、故障恢復(fù)、指標(biāo)收集和監(jiān)控以及通常更加復(fù)雜的運(yùn)維需求花嘶，例如 A/B 測試笋籽、金絲雀發(fā)布、限流椭员、訪問控制和端到端認(rèn)證等车海。

2017 年底，非侵入式的 Service Mesh 技術(shù)從萌芽到走向了成熟隘击。如果用一句話來解釋什么是 Service Mesh侍芝，可以將它比作是應(yīng)用程序或者說微服務(wù)間的 TCP/IP，負(fù)責(zé)服務(wù)之間的網(wǎng)絡(luò)調(diào)用埋同、限流州叠、熔斷和監(jiān)控。對于編寫應(yīng)用程序來說一般無須關(guān)心 TCP/IP 這一層（比如通過 HTTP 協(xié)議的 RESTful 應(yīng)用）凶赁，同樣使用 Service Mesh 也就無須關(guān)系服務(wù)之間的那些原來是通過應(yīng)用程序或者其他框架實現(xiàn)的事情咧栗，比如 Spring Cloud逆甜、OSS，現(xiàn)在只要交給 Service Mesh 就可以了致板。

Service Mesh 的來龍去脈：

• 從最原始的主機(jī)之間直接使用網(wǎng)線相連
• 網(wǎng)絡(luò)層的出現(xiàn)
• 集成到應(yīng)用程序內(nèi)部的控制流
• 分解到應(yīng)用程序外部的控制流
• 應(yīng)用程序的中集成服務(wù)發(fā)現(xiàn)和斷路器
• 出現(xiàn)了專門用于服務(wù)發(fā)現(xiàn)和斷路器的軟件包/庫交煞，如 Twitter 的 Finagle 和 Facebook 的 Proxygen，這時候還是集成在應(yīng)用程序內(nèi)部
• 出現(xiàn)了專門用于服務(wù)發(fā)現(xiàn)和斷路器的開源軟件斟或，如 Netflix OSS素征、Airbnb 的 synapse 和 nerve
• 最后作為微服務(wù)的中間層 Service Mesh 出現(xiàn)

Service Mesh 有如下幾個特點(diǎn)：

• 應(yīng)用程序間通訊的中間層
• 輕量級網(wǎng)絡(luò)代理
• 應(yīng)用程序無感知
• 解耦應(yīng)用程序的重試/超時、監(jiān)控萝挤、追蹤和服務(wù)發(fā)現(xiàn)

Service Mesh 架構(gòu)圖：

image

關(guān)于微服務(wù)和服務(wù)網(wǎng)格的區(qū)別御毅，我的一些理解：微服務(wù)更像是一個服務(wù)之間的生態(tài)，專注于服務(wù)治理等方面怜珍，而服務(wù)網(wǎng)格更專注于服務(wù)之間的通信端蛆，以及和 DevOps 更好的結(jié)合。

三. Istio

最終萬眾期待的Istio誕生了绘面，Istio于 2017 年 5 月 24 日首發(fā)布欺税，由 Google、IBM 和 Lyft 聯(lián)合開發(fā)揭璃，就在前不久2018年8月份1.0正式版本已經(jīng)發(fā)布晚凿，簡單一句概況就是Istio 允許您連接、保護(hù)瘦馍、控制和觀測服務(wù)歼秽。

連接

• 智能控制服務(wù)之間的流量和 API 調(diào)用，進(jìn)行一系列測試情组，并通過紅/黑部署逐步升級燥筷。

保護(hù)

• 通過托管身份驗證、授權(quán)和服務(wù)之間通信加密自動保護(hù)您的服務(wù)院崇。

控制

• 應(yīng)用策略并確保其執(zhí)行使得資源在消費(fèi)者之間公平分配肆氓。

觀測

• 通過豐富的自動跟蹤、監(jiān)控和記錄所有服務(wù)底瓣，了解正在發(fā)生的情況谢揪。

PS: 以下內(nèi)容來自官網(wǎng)文檔

Istio 服務(wù)網(wǎng)格邏輯上分為數(shù)據(jù)平面和控制平面。

數(shù)據(jù)平面由一組以 sidecar 方式部署的智能代理（Envoy）組成捐凭。這些代理可以調(diào)節(jié)和控制微服務(wù)及 Mixer 之間所有的網(wǎng)絡(luò)通信拨扶。
控制平面負(fù)責(zé)管理和配置代理來路由流量。此外控制平面配置 Mixer 以實施策略和收集遙測數(shù)據(jù)茁肠。

下圖顯示了構(gòu)成每個面板的不同組件：

image

Envoy

Istio 使用 Envoy 代理的擴(kuò)展版本患民，Envoy 是以 C++ 開發(fā)的高性能代理，用于調(diào)解服務(wù)網(wǎng)格中所有服務(wù)的所有入站和出站流量垦梆。Envoy 的許多內(nèi)置功能被 istio 發(fā)揚(yáng)光大匹颤，例如：

• 動態(tài)服務(wù)發(fā)現(xiàn)
• 負(fù)載均衡
• TLS 終止
• HTTP/2 & gRPC 代理
• 熔斷器
• 健康檢查仅孩、基于百分比流量拆分的灰度發(fā)布
• 故障注入
• 豐富的度量指標(biāo)

Envoy 被部署為 sidecar，和對應(yīng)服務(wù)在同一個 Kubernetes pod 中惋嚎。這允許 Istio 將大量關(guān)于流量行為的信號作為屬性提取出來杠氢，而這些屬性又可以在 Mixer 中用于執(zhí)行策略決策站刑，并發(fā)送給監(jiān)控系統(tǒng)另伍，以提供整個網(wǎng)格行為的信息。

Sidecar 代理模型還可以將 Istio 的功能添加到現(xiàn)有部署中绞旅，而無需重新構(gòu)建或重寫代碼摆尝。可以閱讀更多來了解為什么我們在設(shè)計目標(biāo)中選擇這種方式因悲。

Mixer

Mixer 是一個獨(dú)立于平臺的組件堕汞，負(fù)責(zé)在服務(wù)網(wǎng)格上執(zhí)行訪問控制和使用策略，并從 Envoy 代理和其他服務(wù)收集遙測數(shù)據(jù)晃琳。代理提取請求級屬性讯检，發(fā)送到 Mixer 進(jìn)行評估。有關(guān)屬性提取和策略評估的更多信息卫旱，請參見 Mixer 配置人灼。

Mixer 中包括一個靈活的插件模型，使其能夠接入到各種主機(jī)環(huán)境和基礎(chǔ)設(shè)施后端顾翼，從這些細(xì)節(jié)中抽象出 Envoy 代理和 Istio 管理的服務(wù)投放。

Pilot

Pilot 為 Envoy sidecar 提供服務(wù)發(fā)現(xiàn)功能，為智能路由（例如 A/B 測試适贸、金絲雀部署等）和彈性（超時灸芳、重試、熔斷器等）提供流量管理功能拜姿。它將控制流量行為的高級路由規(guī)則轉(zhuǎn)換為特定于 Envoy 的配置烙样，并在運(yùn)行時將它們傳播到 sidecar。

Pilot 將平臺特定的服務(wù)發(fā)現(xiàn)機(jī)制抽象化并將其合成為符合 Envoy 數(shù)據(jù)平面 API 的任何 sidecar 都可以使用的標(biāo)準(zhǔn)格式蕊肥。這種松散耦合使得 Istio 能夠在多種環(huán)境下運(yùn)行（例如谒获，Kubernetes、Consul晴埂、Nomad）究反，同時保持用于流量管理的相同操作界面。

Citadel

Citadel 通過內(nèi)置身份和憑證管理可以提供強(qiáng)大的服務(wù)間和最終用戶身份驗證儒洛【停可用于升級服務(wù)網(wǎng)格中未加密的流量，并為運(yùn)維人員提供基于服務(wù)標(biāo)識而不是網(wǎng)絡(luò)控制的強(qiáng)制執(zhí)行策略的能力琅锻。從 0.5 版本開始卦停，Istio 支持基于角色的訪問控制向胡，以控制誰可以訪問您的服務(wù)。

四. 服務(wù)監(jiān)控鏈路監(jiān)控

Istio結(jié)合了鏈路監(jiān)控和服務(wù)監(jiān)控,對于K8S狀態(tài)監(jiān)控也自然而然也在其中

zipkin + jaeger 來對zipkin的數(shù)據(jù)進(jìn)行更加友好的展示

image

.

image

PS : 需要實現(xiàn)鏈路監(jiān)控需要代碼中做出基礎(chǔ)的適配

prometheus + grafana 來對prometheus獲取的數(shù)據(jù)進(jìn)行展示監(jiān)控報警配置

image

image