服务网格Istio概述
-
- [什么是服务网格(Service Mesh)？](#什么是服务网格(Service Mesh)？)
- istio简介
- 边车模式（Sidecar）
- 为什么istio能代替传统SpringCloud？
- 整体架构
首先奉上 istio官网
什么是服务网格(Service Mesh)？
服务网格（Service Mesh）是一个专门处理服务通讯的基础设施层。它的职责是在由云原生应用组成服务的复杂拓扑结构下进行可靠的请求传送。在实践中，它是一组和应用服务部署在一起的轻量级的网络代理，并且对应用服务透明。
服务网格从总体架构上来讲比较简单，不过是一堆紧挨着各项服务的用户代理，外加一组任务管理组件组成。
管理组件被称为控制层或控制平面（control plane），负责与控制平面中的代理通信，下发策略和配置。
代理在服务网格中被称为数据层或数据平面（data plane），直接处理入站和出站数据包，转发、路由、健康检查、负载均衡、认证、鉴权、产生监控数据等。
istio简介
istio是一款开源的服务网格平台， 在微服务项目中，若要对服务进行链路追踪，流量监控，指标监控、安全管理，日志管理等一系列操作，istio都可以以非嵌入式的方式对微服务项目进行服务治理，以透明层的方式构建在现有分布式应用中。它也是一个提供了各种API的平台，可以与任何日志平台、监控系统或策略系统集成。Istio的多样化特性可以让你高效地运行分布式微服务架构，并提供一种统一的方式来保护、连接和监控微服务。它是一个完全开源的服务网格，以透明层的方式构建在现有分布式应用中。它也是一个提供了各种API的平台，可以与任何日志平台、监控系统或策略系统集成。Istio的多样化特性可以让你高效地运行分布式微服务架构，并提供一种统一的方式来保护、连接和监控微服务。
从上面的定义中可以了解到，Istio为微服务应用提供了一个完整的解决方案，可以以统一的方式去检测和管理微服务。同时，它还提供了管理流量、实施访问策略、收集数据等功能，而所有这些功能都对业务代码透明，即不需要修改业务代码就能实现。
有了Istio，就几乎可以不需要其他的微服务框架，也不需要自己去实现服务治理等功能，只要把网络层委托给Istio，它就能帮助完成这一系列的功能。简单来说，Istio就是一个提供了服务治理能力的服务网格。
边车模式（Sidecar）
边车（Sidecar）模式设计思想的核心是将控制和逻辑分离，常用于我们在分布式架构中的逻辑和控制分离设计。迁移到我们的分布式架构中就是：我们不需要在服务中实现控制面上的东西，如监视、日志记录、限流、熔断、服务注册、协议适配转换等这些属于控制面上的东西，而只需要专注地做好和业务逻辑相关的代码，然后，由"边车"来实现这些与业务逻辑没有关系的控制功能。一文搞懂边车模式
为什么istio能代替传统SpringCloud？
在传统的SpringCloud应用中，举例以springcloudgateway作网关，nacos为注册中心，sentinel作流控，zipkin作链路追踪，这些操作想必java程序员都知道，最常用也是培训机构最喜欢以此录课一套，不可否认的是这一套的代码及结构都非常优秀，但是有一个极大的问题：与代码耦合，服务拓扑复杂之后难以管理，中间流控、链路追踪行为需针对每个服务与服务间去设置，耦合进代码。同时，若没有K8s的加持下，服务出现熔断或宕掉后，容灾操作也不便管理。
为了实现项目的多元化部署与容灾，Kubernetes应运而生，自然地，微服务的项目运行得以保障，随之而来的是以下问题：
- nacos或feign再套一层Kubernetes，服务间调用链路增加；
从ingress到网关再到项目，每个请求几乎都多一层调用 - 各个组件需要以不同方式嵌入进代码，非统一化，不易管控。
对于老项目的改造是非常谨慎的，若想给老项目加上一个新监控组件，指不定会影响项目本身运行 - 针对服务与服务间的东西流量不易监控
例如电商系统中有订单服务和商品服务以及优惠券服务，三个服务间相互调用，如何知晓哪两个服务间流量大？如何统一管控？ - 多语言的微服务，监控方式难以联动
- 传统的SpringCloud，针对feign请求要到注册中心找到对应服务，再到服务对应的service，不如直接通过kubernete路由到service，pod的数量由在service管控下，nacos也只能再路由service去，不能直接到达
以上问题 istio可以提供支持
功能例如
服务发现、负载均衡、故障恢复、度量和监控
A/B 测试、金丝雀发布、速率限制、访问控制和端到端认证
整体架构
Istio服务网格逻辑上分为数据面板和控制面板。
Istio的架构从逻辑上分成数据平面（Data Plane）和控制平面（Control Plane）。Kubernetes的架构也具有相似的结构，分为控制节点和计算节点。毫无疑问，这样的设计可以很好地解耦各个功能组件。
数据平面：由一组和业务服务成对出现的Sidecar代理（Envoy）构成，它的主要功能是接管服务的进出流量，传递并控制服务和Mixer组件的所有网络通信
控制平面：主要包括了Pilot、Mixer、Citadel和Galley共4个组件，主要功能是通过配置和管理Sidecar代理以非嵌入式代码的形式来进行流量控制，并配置Mixer去执行策略和收集遥测数据（Telemetry），最后在 Kiali仪表板上展示。
博主运行环境为kubernete1.27，已去除docker作为依赖，当利用ingressgateway作网关，没有了dockershim的限制，配上istio的支持，整个微服务与运维环境会显得异常干净整洁。
