（一）Istio-如何拆分微服務
1、概述
目前微服務的拆分方式眾說紛紜，每家的拆分方式也不盡相同，每家說的也都很有道理，但可惜沒有 銀彈（沒有簡單的方式解決復雜的軟件工程問題），在這種情況下我們只需明確 架構是演化來的，不是設計來的 這一准則便不會讓我們陷入糾結的泥潭，既然如此那我們隨心所欲的拆分就好了嘛，不用有太大的心里負擔，以下咱們根據微服務架構的設計模式還是能夠提煉出一些基本的拆分方式供我們選擇和借鑒
2、拆分粒度
我個人認為拆分粒度越細越好，咱們可以考慮一種面向未來的架構方式去做拆分，目前下一代架構基本就定在 Servless 這一概念上了（函數即服務，函數計算，一個函數一個服務），拆分的粒度足夠細的話在未來轉型雲架構時會變的輕松許多並且咱們勢必還要實現 全程異步通信 與 全服務無狀態 等
3、拆分方法
a、根據業務拆分
將系統中的業務模塊按照職責范圍識別出來，每個單獨的業務模塊拆分為一個獨立的服務，例如，做一個電商系統，可以划分為 商品、交易、用戶 3 個服務，也可以划分為商品、訂單、支付、發貨、買家、賣家 6 個服務
b、根據穩定性拆分
將系統中的業務模塊按照穩定性排序，將已經成熟和改動不大的服務拆分為 穩定服務，將經常變化和迭代的服務拆分為 變動服務，例如 日志 這種業務不怎么變化的就可以拆分成一個服務
c、根據可靠性拆分
將系統中的 可靠性要求高的核心服務 和 可靠性要求低的非核心服務 拆分開來，然后重點保證核心服務的高可用，其優點如下：
- 避免非核心服務故障影響核心服務，例如，日志上報是非核心服務，某一段時間內上報量可能會非常大，如果沒有拆分出來，那么就可能嚴重影響核心服務
- 核心服務高可用方案更簡單，核心服務單獨拆分出來后，涉及的數據、組件等都會更少，對其做高可用方案就簡單很多，需要考慮的點較少
- 降低高可用成本，拆分后，核心服務占用的機器、帶寬等資源比不拆分要少很多
d、根據性能拆分
將對性能壓力大的模塊拆出來，避免影響其他服務，而且對其做性能提升、高可用等優化都更簡單高效，例如電商的搶購，排隊功能的性能壓力很大，就可以將其獨立為一個服務
e、根據事務拆分
通過分解事務上的服務進行拆分，按照 事務發起者，事務參與者，事務完成者 拆分成鏈式調用的服務，最后由 事務協調者服務 向所有參與方發出提交或回滾命令
4、完整微服務架構生態
我這里給出的解決方案是 React / Vue + Spring Cloud Alibaba + Apache Dubbo + Kubernetes + Istio 的方式實現我們的完整微服務架構生態，真正意義上滿足三大指標（高可用、高性能、高並發），下一代 雲架構時代，我會嘗試采用 區塊鏈 的方式實現 Servless 函數即服務架構；下面我們看一下這幾套解決方案在完整微服務架構生態中起到的主要作用
a、React / Vue
前后分離；將 視圖層 解耦出來，使用 MVVM 模式實現雙向數據綁定，利用其提供的 模塊化 與 虛擬 DOM 開發前端應用程序
b、Aapche Dubbo
高性能 Java RPC 通信框架；它在咱們微服務架構體系中僅充當 RPC 通信功能，我主要將它作用於 數據訪問層，因為數據庫不允許被直接訪問，所以它在我們 三層架構 的最底層即可
c、Spring Cloud Alibaba
一站式微服務開發解決方案；我將它作用於 業務邏輯層，阿里巴巴提供的各種組件可以很好的為我們協調業務場景問題，比如 削峰填谷、熔斷降級、流量控制 等
d、Kubernetes
容器編排管理系統；K8S 的重要性不言而喻，它是咱們實現雲計算的重要工具，它有個缺點就是沒有提供很好的 服務治理 能力
e、Istio
Service Mesh 服務網格，讓你更好更輕松的解決服務治理問題；它補充了 K8S 缺失的服務治理能力，采用 Sidecar 模式為我們提供了一套 控制面，包括 Pilot (規則配置)、Mixer (策略配置)、Citadel (證書生成與下發)、Kiali (規則驗證)
5、Spring Cloud & Kubernetes
| 功能比較 | Spring Cloud Alibaba | Kubernetes |
|---|---|---|
| 配置管理 | Nacos | ConfigMap |
| 服務發現 | Nacos | Etcd |
| 負載均衡 | Ribbon | Service |
| API 網關 | 借用 Spring Cloud Gateway | Ingress |
| 認證授權 | 借用 Spring Security oAuth2 | Secrets |
| 日志收集 | ELK (LogStash) | EFK (Fluentd) |
| 指標收集 | - | Prometheus，Grafana |
| 鏈路追蹤 | 借用 Apache Skywalking | ZipKin |
| 熔斷限流 | Sentinel | 支持 |
| 自動擴縮容 | - | 支持 |
| 打包部署 | Spring Boot | Docker |
| 任務調度 | Spring Batch | Jobs |
6、一句話總結 Istio
Istio 是運行於分布式應用程序之上的 非侵入式（無代碼入侵）服務網格系統，它的主要目的是為了更好更輕松的解決服務治理問題
（二）什么是服務治理問題
首先這是一道思考題，我們是去治理服務而不是去管理服務，隨着業務和訪問量增大，架構也在慢慢的發生變化，從最早的 單應用 -> 三層架構 -> SOA -> 微服務，架構是根據業務和訪問量不斷演變的，你會發現在這一過程中各種問題層出不窮（按下葫蘆，起了瓢），由此可以看出我們根本就不可能有一種固定的方式去管理我們的服務，所以這么多服務不存在管理問題而是治理問題
服務治理到底在治理什么呢？其最主要的目的是 處理服務與服務之間的調用關系，比如誰是提供者？誰是消費者？出了故障怎么辦？如何保證服務質量？如何實現服務熔斷和降級？服務如何監控？如何最大化提高機器的利用率？
1、使用已知工具治理服務
從上面提的問題想必大家心里也都有了一些答案，按照我們現在掌握的工具，可按如下分類做與服務治理相關的工作
- 服務注冊與發現： Eurake，Nacos
- 服務外部化配置： Spring Cloud Config，Nacos，Apollo
- 服務熔斷降級： Hystrix，Sentinel
- API 網關： Zuul，Spring Cloud Gateway
- 負載均衡： Ribbon，Dubbo
- 鏈路追蹤： Zipkin，Skywalking
- 日志收集： ELK，EFK
- 服務監控： Promethues，Grafna，Spring Boot Admin
這些紛繁復雜的工具都是我們在做微服務時必不可少的組件，而這些組件都有一個問題就是代碼侵入性，能不能有一套系統來為我們解決服務治理問題，將這些組件徹底解耦，讓我們回歸業務本身
（三）Istio-非侵入式服務網格系統
1、什么是服務網格
術語服務網格（Service Mesh）用於描述微服務之間的網絡，以及通過此網絡進行的服務之間的交互。隨着服務數量和復雜度的增加，服務網格將變的難以理解和管理，對服務網格的需求包括：
- 服務發現
- 負載均衡
- 故障恢復
- 指標和監控
- A / B 測試
- 金絲雀發布
- 流量控制
- 訪問控制
- 端對端身份驗證
2、什么是 Istio
Istio 是運行於分布式應用程序之上的 非侵入式（無代碼入侵）服務網格系統，它的主要目的是為了更好更輕松的解決服務治理問題（Istio 是一套非侵入式一站式服務治理解決方案）
Istio 的實現原理是，為每個微服務部署一個 Sidecar，代理微服務之間的所有網絡通信。在此基礎上你可以通過 Istio 的控制平面實現：
- 針對 HTTP、gRPC、WebSocket、TCP 流量的負載均衡
- 細粒度的流量控制行為，包括路由、重試、故障轉移、故障注入
- 可拔插的策略層 + 配置 API，實現訪問控制、限速、配額
- 自動收集指標、日志，跟蹤集群內所有流量，包括 Ingress/Egress
- 基於強身份認證和授權來保護服務之間的通信
3、Istio 核心特性
a、流量管理
使用 Istio 你可以很容易的通過配置，對流量和 API 調用進行控制。服務級別的可配置屬性包括斷路器、超時、重試，Istio 支持基於流量百分比切分的 A/B 測試、金絲雀滾動發布、分階段滾動發布
b、安全性
可以提供安全信道，管理身份驗證和授權，加密通信流量，聯用 K8S 的網絡策略可以獲得更多益處，例如保護 Pod-to-Pod 之間的通信
c、可觀察性
Istio 強大的跟蹤、監控、日志能力，讓服務網格內部結構更容易觀察（一個服務的性能對上下游的影響可以直觀的展現在儀表盤上）
4、Istio 架構
從整體上看，Istio 的服務網格由數據平面、控制平面兩部分組成：
- 數據平面： 由一系列作為 Sidecar 部署的智能代理（Envoy）構成。這些代理聯合 Mixer， 中繼、控制所有微服務之間的網絡通信。需要注意，還有一些 Envoy 是獨立部署（而非 Sidecar）的，用來實現 K8S Ingress 控制器、Istio 的 Ingress/Egress 網關
- 控制平面： 負責管理、配置智能代理，實現流量路由；配置 Citadel 實現 TLS 證書管理；配置 Mixers 來應用策略、收集指標
Envoy
Istio 使用一個擴展過的 Envoy 版本。Envoy 是基於 C++ 開發的高性能代理，Istio 使用它的以下特性：
- 動態服務發現
- 負載均衡
- TLS termination（可將后端的 HTTP 服務包裝為 HTTPS）
- HTTP/2 和 gRPC 代理
- 斷路器
- 健康檢查
- 分階段（基於流量百分比）發布
- 故障注入
- 豐富的監控指標
一般情況下 Envoy 在和目標服務的相同 Pod 中，以 Sidecar 形式部署。少量的 Istio 組件的主進程就是 Envoy，包括 Ingress 控制器、Ingress/Egress 網關
Mixer
一個平台無關的組件：
- 為服務網格應用訪問控制策略
- 從 Envoy 和其它服務中收集指標
- Envoy 收集的請求級別的屬性，被發送到 Mixer 進行分析
Mixer 提供了一個靈活的插件模型，讓 Istio 能夠靈活的和多種宿主機環境、基礎設施后端進行對接
Pilot
該組件是 Istio 的控制器，它會監控各種規則、策略（通常存儲在 K8S 中），一旦配置文件發生變化，就會提取、處理，並同步給 Envoy：
- 為 Envoy 提供服務發現
- 為智能路由（AB 測試、金絲雀部署）提供流量管理能力
- 提供彈性（超時、重試、斷路器）
- 分發身份驗證策略給 Envoy
Pilot 將高級別的路由規則轉換為 Envoy 理解的配置信息，並在運行時將這些配置傳播到 Sidecars，Pilot 將平台相關的服務發現機制抽象為標准的（Envoy data plane API，xDS）格式，這讓 Istio 可以在 K8S、Consul、Nomad 等多種環境下運行
Citadel
提供服務與服務之間、或者針對終端用戶的身份驗證功能，可以加密服務網格中的流量
Kiali
為我們提供了查看相關服務與配置提供了統一化的可視化界面，並且能在其中展示他們的關聯；同時他還提供了界面讓我們可以很方便的驗證 istio 配置與錯誤提示
轉自：有夢想的咸魚