Istio-微服务治理
（一）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 配置与错误提示
转自：有梦想的咸鱼
