跨語言微服務框架-Istio簡紹和概念

微服務的概念已經在各大公司實踐開了，以Java為代表的spring boot成為了微服務的代表，K8S+Docker成為了微服務執行的最佳環境，微服務的概念已經離我們沒有那麼遙遠了。

當然微服務是複雜的，除了元件繁多還需要程式碼做出很多改造才能享受到它帶來的優勢，那麼有沒有一種方式可以不需要太多程式碼改動就能夠在多種不同的開發語言中靈活使用呢?

基於服務網格Istio就誕生了,撥雲見日我們今天就來一同學習瞭解微服務和Istio相關的知識.

附上:

喵了個咪的部落格:w-blog.cn

Istio官方地址:https://preliminary.istio.io/zh

Istio中文文件:https://preliminary.istio.io/zh/docs/

PS : 此處基於當前最新istio版本1.0.3版本進行搭建和演示，不同的版本各種細節會有些許不同！

一. 微服務

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

• 服務註冊：服務提供方將自己呼叫地址註冊到服務註冊中心，讓服務呼叫方能夠方便地找到自己。
• 服務發現：服務呼叫方從服務註冊中心找到自己需要呼叫的服務的地址。
• 負載均衡：服務提供方一般以多例項的形式提供服務，負載均衡功能能夠讓服務呼叫方連線到合適的服務節點。並且，節點選擇的工作對服務呼叫方來說是透明的。
• 服務閘道器：服務閘道器是服務呼叫的唯一入口，可以在這個元件是實現使用者鑑權、動態路由、灰度釋出、A/B 測試、負載限流等功能。
• 配置中心：將本地化的配置資訊（properties, xml, yaml 等）註冊到配置中心，實現程式包在開發、測試、生產環境的無差別性，方便程式包的遷移。
• API 管理：以方便的形式編寫及更新 API 文件，並以方便的形式供呼叫者檢視和測試。
• 整合框架：微服務元件都以職責單一的程式包對外提供服務，整合框架以配置的形式將所有微服務元件（特別是管理端元件）整合到統一的介面框架下，讓使用者能夠在統一的介面中使用系統。
• 分散式事務：對於重要的業務，需要通過分散式事務技術（TCC、高可用訊息服務、最大努力通知）保證資料的一致性。
• 呼叫鏈：記錄完成一個業務邏輯時呼叫到的微服務，並將這種序列或並行的呼叫關係展示出來。在系統出錯時，可以方便地找到出錯點。
• 支撐平臺：系統微服務化後，系統變得更加碎片化，系統的部署、運維、監控等都比單體架構更加複雜，那麼，就需要將大部分的工作自動化。現在，可以通過 Docker 等工具來中和這些微服務架構帶來的弊端。 例如持續整合、藍綠髮布、健康檢查、效能健康等等。嚴重點，以我們兩年的實踐經驗，可以這麼說，如果沒有合適的支撐平臺或工具，就不要使用微服務架構。

微服務架構的優點：

• 降低系統複雜度：每個服務都比較簡單，只關注於一個業務功能。
• 鬆耦合：微服務架構方式是鬆耦合的，每個微服務可由不同團隊獨立開發，互不影響。
• 跨語言：只要符合服務 API 契約，開發人員可以自由選擇開發技術。這就意味著開發人員可以採用新技術編寫或重構服務，由於服務相對較小，所以這並不會對整體應用造成太大影響。
• 獨立部署：微服務架構可以使每個微服務獨立部署。開發人員無需協調對服務升級或更改的部署。這些更改可以在測試通過後立即部署。所以微服務架構也使得 CI／CD 成為可能。
• Docker 容器：和 Docker 容器結合的更好。
• DDD 領域驅動設計：和 DDD 的概念契合，結合開發會更好。

微服務架構的缺點：

• 微服務強調了服務大小，但實際上這並沒有一個統一的標準：業務邏輯應該按照什麼規則劃分為微服務，這本身就是一個經驗工程。有些開發者主張 10-100 行程式碼就應該建立一個微服務。雖然建立小型服務是微服務架構崇尚的，但要記住，微服務是達到目的的手段，而不是目標。微服務的目標是充分分解應用程式，以促進敏捷開發和持續整合部署。
• 微服務的分散式特點帶來的複雜性：開發人員需要基於 RPC 或者訊息實現微服務之間的呼叫和通訊，而這就使得服務之間的發現、服務呼叫鏈的跟蹤和質量問題變得的相當棘手。
• 分割槽的資料庫體系和分散式事務：更新多個業務實體的業務交易相當普遍，不同服務可能擁有不同的資料庫。CAP 原理的約束，使得我們不得不放棄傳統的強一致性，而轉而追求最終一致性，這個對開發人員來說是一個挑戰。
• 測試挑戰：傳統的單體WEB應用只需測試單一的 REST API 即可，而對微服務進行測試，需要啟動它依賴的所有其他服務。這種複雜性不可低估。
• 跨多個服務的更改：比如在傳統單體應用中，若有 A、B、C 三個服務需要更改，A 依賴 B，B 依賴 C。我們只需更改相應的模組，然後一次性部署即可。但是在微服務架構中，我們需要仔細規劃和協調每個服務的變更部署。我們需要先更新 C，然後更新 B，最後更新 A。
• 部署複雜：微服務由不同的大量服務構成。每種服務可能擁有自己的配置、應用例項數量以及基礎服務地址。這裡就需要不同的配置、部署、擴充套件和監控元件。此外，我們還需要服務發現機制，以便服務可以發現與其通訊的其他服務的地址。因此，成功部署微服務應用需要開發人員有更好地部署策略和高度自動化的水平。

總的來說（問題和挑戰）：API Gateway、服務間呼叫、服務發現、服務容錯、服務部署、資料呼叫以及測試。

二, 服務網格

第二點我們需要了解的是服務網格，Istio 提供了一個完整的解決方案，通過為整個服務網格提供行為洞察和操作控制來滿足微服務應用程式的多樣化需求，Service Mesh這個術語通常用於描述構成這些應用程式的微服務網路以及應用之間的互動。

隨著規模和複雜性的增長，服務網格越來越難以理解和管理。它的需求包括服務發現、負載均衡、故障恢復、指標收集和監控以及通常更加複雜的運維需求，例如 A/B 測試、金絲雀釋出、限流、訪問控制和端到端認證等。

2017 年底，非侵入式的 Service Mesh 技術從萌芽到走向了成熟。如果用一句話來解釋什麼是 Service Mesh，可以將它比作是應用程式或者說微服務間的 TCP/IP，負責服務之間的網路呼叫、限流、熔斷和監控。對於編寫應用程式來說一般無須關心 TCP/IP 這一層（比如通過 HTTP 協議的 RESTful 應用），同樣使用 Service Mesh 也就無須關係服務之間的那些原來是通過應用程式或者其他框架實現的事情，比如 Spring Cloud、OSS，現在只要交給 Service Mesh 就可以了。

Service Mesh 的來龍去脈：

• 從最原始的主機之間直接使用網線相連
• 網路層的出現
• 整合到應用程式內部的控制流
• 分解到應用程式外部的控制流
• 應用程式的中整合服務發現和斷路器
• 出現了專門用於服務發現和斷路器的軟體包/庫，如 Twitter 的 Finagle 和 Facebook 的 Proxygen，這時候還是整合在應用程式內部
• 出現了專門用於服務發現和斷路器的開源軟體，如 Netflix OSS、Airbnb 的 synapse 和 nerve
• 最後作為微服務的中間層 Service Mesh 出現

Service Mesh 有如下幾個特點：

• 應用程式間通訊的中間層
• 輕量級網路代理
• 應用程式無感知
• 解耦應用程式的重試/超時、監控、追蹤和服務發現

Service Mesh 架構圖：

關於微服務和服務網格的區別，我的一些理解：微服務更像是一個服務之間的生態，專注於服務治理等方面，而服務網格更專注於服務之間的通訊，以及和 DevOps 更好的結合。

三. Istio

最終萬眾期待的Istio誕生了，Istio於 2017 年 5 月 24 日首發布，由 Google、IBM 和 Lyft 聯合開發，就在前不久2018年8月份1.0正式版本已經發布，簡單一句概況就是Istio 允許您連線、保護、控制和觀測服務。

連線

• 智慧控制服務之間的流量和 API 呼叫，進行一系列測試，並通過紅/黑部署逐步升級。

保護

• 通過託管身份驗證、授權和服務之間通訊加密自動保護您的服務。

控制

• 應用策略並確保其執行使得資源在消費者之間公平分配。

觀測

• 通過豐富的自動跟蹤、監控和記錄所有服務，瞭解正在發生的情況。

PS: 以下內容來自官網文件

Istio 服務網格邏輯上分為資料平面和控制平面。

資料平面由一組以 sidecar 方式部署的智慧代理（Envoy）組成。這些代理可以調節和控制微服務及 Mixer 之間所有的網路通訊。 控制平面負責管理和配置代理來路由流量。此外控制平面配置 Mixer 以實施策略和收集遙測資料。

下圖顯示了構成每個皮膚的不同元件：

Envoy

Istio 使用 Envoy 代理的擴充套件版本，Envoy 是以 C++ 開發的高效能代理，用於調解服務網格中所有服務的所有入站和出站流量。Envoy 的許多內建功能被 istio 發揚光大，例如：

• 動態服務發現
• 負載均衡
• TLS 終止
• HTTP/2 & gRPC 代理
• 熔斷器
• 健康檢查、基於百分比流量拆分的灰度釋出
• 故障注入
• 豐富的度量指標

Envoy 被部署為 sidecar，和對應服務在同一個 Kubernetes pod 中。這允許 Istio 將大量關於流量行為的訊號作為屬性提取出來，而這些屬性又可以在 Mixer 中用於執行策略決策，併傳送給監控系統，以提供整個網格行為的資訊。

Sidecar 代理模型還可以將 Istio 的功能新增到現有部署中，而無需重新構建或重寫程式碼。可以閱讀更多來了解為什麼我們在設計目標中選擇這種方式。

Mixer

Mixer 是一個獨立於平臺的元件，負責在服務網格上執行訪問控制和使用策略，並從 Envoy 代理和其他服務收集遙測資料。代理提取請求級屬性，傳送到 Mixer 進行評估。有關屬性提取和策略評估的更多資訊，請參見 Mixer 配置。

Mixer 中包括一個靈活的外掛模型，使其能夠接入到各種主機環境和基礎設施後端，從這些細節中抽象出 Envoy 代理和 Istio 管理的服務。

Pilot

Pilot 為 Envoy sidecar 提供服務發現功能，為智慧路由（例如 A/B 測試、金絲雀部署等）和彈性（超時、重試、熔斷器等）提供流量管理功能。它將控制流量行為的高階路由規則轉換為特定於 Envoy 的配置，並在執行時將它們傳播到 sidecar。

Pilot 將平臺特定的服務發現機制抽象化並將其合成為符合 Envoy 資料平面 API 的任何 sidecar 都可以使用的標準格式。這種鬆散耦合使得 Istio 能夠在多種環境下執行（例如，Kubernetes、Consul、Nomad），同時保持用於流量管理的相同操作介面。

Citadel

Citadel 通過內建身份和憑證管理可以提供強大的服務間和終端使用者身份驗證。可用於升級服務網格中未加密的流量，併為運維人員提供基於服務標識而不是網路控制的強制執行策略的能力。從 0.5 版本開始，Istio 支援基於角色的訪問控制，以控制誰可以訪問您的服務。

四. 服務監控鏈路監控

Istio結合了鏈路監控和服務監控,對於K8S狀態監控也自然而然也在其中

zipkin + jaeger 來對zipkin的資料進行更加友好的展示

.

 

PS : 需要實現鏈路監控需要程式碼中做出基礎的適配

prometheus + grafana 來對prometheus獲取的資料進行展示監控報警配置

本文來自雲棲社群合作伙伴“開源中國”

本文作者：喵了_個咪 

原文連結