ServiceMesh实战
ServiceMesh是应用的网络通信层
Istio（ServiceMesh明星产品）
（ServiceMesh）概念
产生的原因
微服务架构的特性：
围绕业务构建团队
康威定律：一个团队的结构将决定一个产品的结构
去中心化的数据管理
微服务架构的优势：
团队层面：
内聚，独立开发业务，没有依赖
产品层面：
服务彼此独立，独立部署，没有依赖
微服务真的是软件架构中的银弹吗？
银弹理论：没有任何一种技术和管理上的进步，可以极大的提升生产效率。换句话说就是没有任何一种技术可以完美的解决软件开发中出现的问题。
微服务架构面临什么样的问题：
微服务节点间的网络通信的问题。如果在一个节点数较多的微服务架构中，出现了网络异常（超时，中断之类的），应该如何去排查。
为什么网络通信是微服务架构的痛点？
分布式计算的8个谬论：
网络是可靠的
网络延迟是0
带宽是无限的
网络是安全的
网络拓扑从不改变
只有一个管理员
传输成本是0
网络是同构的
如何管理和控制服务间的通信？
服务注册/发现
路由，流量转移
弹性能力（熔断、超时、重试）
安全
可观测性
演进过程
《ServiceMesh模式》详细介绍了ServiceMesh的演进过程，建议阅读
第一阶段：控制逻辑和业务逻辑耦合
第二阶段：公共库（优势是消除重复，缺点是时间上的成本 、人力的成本，如果更换语言那么还需要使用另外一个语言去实现。此外公共库还是需要在我们的项目中引入，本质上它依然和你的应用程序在同时运行）
第三阶段：代理模式（单独抽出一个模块，缺点是功能简陋）
第四阶段：边车模式（Sidecar）
第五阶段：ServiceMesh（可以理解为是Sidecar的网络拓扑结构）
定义
A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware. -- buyant.io: What‘s a service mesh? And why do I need one?
ServiceMesh是一个基础设施层，用来处理服务与服务之间的通信，它主要的功能是在云原生应用这种复杂的服务拓扑情况下进行可靠地请求分发。一般情况下它会实现为一组轻量化的网络代理，部署在你的应用代码的旁边，并且跟你的应用是完全透明的。
本质：是一个基础设施层
功能：请求的分发
产品形态（部署形式）：一组网络代理（Sidecar）
特点：完全和你的应用透明
所谓ServiceMesh就是一个用来进行请求转发的基础设施层，它通常是以Sidecar的形式部署，并且对你的应用透明。
ServiceMesh产品形态
第一代：
第二代（目前所应用的）：
第二代ServiceMesh可划分为两个部分：一部分是数据平面，也就是所有的Sidecar组合；另一部分是控制平面，用来进行整体控制。
核心功能
流量控制
路由：蓝绿部署、灰度发布、A/B测试
流量转移
超时重试
熔断
故障注入
流量镜像
策略
流量限制
黑白名单
网络安全
授权以及身份认证
可观测性
指标收集和展示
日志收集
分布式追踪
ServiceMesh和kubernetes的关系
kubernetes用以解决容器编排与调度问题，本质上是管理应用生命周期（调度器），会给予ServiceMesh支持和帮助
ServiceMesh用以解决服务间网络通信问题，本质上是管理服务通信（代理），给kubernetes在网络方面提供了扩展和延伸
kubernetes就像云原生应用的一个操作系统，serviceMesh就像是云原生应用的网络通信层。
ServiceMesh和API网关
ServiceMesh模型：
有sidecar去完全接管发送到应用的请求，处理完成之后再发送到另外的微服务。主要是用来对应用内部的网络细节进行一个描述。
API网关模型：
API网关是部署在应用边界的，它并没有侵入到应用内部，它主要的功能实际上是对内部的API进行进行一个聚合和抽象，以方便外部进行调用。API网关主要附着在应用的边界，对流量进行一个抽象
ServiceMesh技术标准
倾向于数据平面的UDPA（Universal Data Plane API）
倾向于控制平面的SMI（Service Mesh Interface）
产品对比、技术选型
Istio入门
优势：1.轻松构建服务网格；2.应用代码无需更改
功能强大
流量控制
路由和流量转移
流量进出（API网关）
网络弹性能力（超时控制、熔断）
测试相关（故障注入、流量镜像）
Istio的流量控制能力建立在以下核心资源（CRD）上：
虚拟服务
目标规则
网关
服务入口
Sidecar
虚拟服务：
将流量路由到给定目标地址
请求地址与真实的工作负载解耦
包含一组路由规则
通常和目标规则成对出现
丰富的路由匹配规则
目标规则：
定义虚拟服务路由目标地址的真实地址（也就是子集）
设置随机负载均衡（默认是轮询模式，另外支持随机、权重、最少请求数等模式）
网关：
管理进出网格的流量（其中管理入格流量的网关叫Ingress，管理出格流量的网关叫Egress，Egress网关不是必选的，你可以直接绕开它，直接指向外部服务）
处在网格边界
服务入口
把外部服务注册到网格内
为外部目标转发请求
添加超时重试等策略
扩展网格
Sidecar
调整Envoy代理接管的端口和协议（默认情况下Envoy是接管所有端口和协议的请求的，而Sidecar可以去调整它的接收范围，比如下图就限制只接收来自端口8090的HTTP协议的请求）
限制Envoy代理可访问的服务（默认情况下Envoy是可以访问网格内所有的服务的，通过Sidecar可以限制Envoy访问服务B）
弹性能力
超时
重试
熔断
测试能力
故障注入（比如增加延时、或者直接让你的服务中断）
流量镜像（把生产环境的流量镜像一份，让后发送到镜像服务中，这样就可以在镜像服务中调试了）
可观测性
可观测性 != 监控
监控指的是从运维人员的角度去审视系统的行为，审视系统的状态，他是一个被动的方式，是从系统之外去探究系统的运行状态。
可观测性指的是从开发人员的角度主动地去探究系统的运行情况，在开发的过程中开发人员就需要考虑上报哪些指标等（指标、日志、追踪）
指标（又称度量）以聚合的方式监控和理解系统行为。Istio中指标分类：
代理级别的指标（proxy-level）
收集目标：Sidecar 代理 资源粒度上的网格监控 容许指定收集的代理（针对性的调试）
服务级别的指标（service-level）
用于监控服务通信 四个基本的服务监控需求：延迟、流量、错误、饱和 默认指标导出到 Prometheus（可自定义和更改） 可根据需求开启或关闭
控制平面级指标（control plane）
对自身组件行为的监控 用于了解网格的健康情况
日志通过系统产生的时间来监控你的应用。（可以写入到ELK、EFK等）
分布式追踪通过追踪请求来了解服务之间的调用关系（主要用于问题排查和性能分析方面）
安全
Istio的安全主要分为认证和授权两部分
认证
认证方式
对等认证（Peer authentication）
用于服务间身份认证
Mutual TLS（mTLS）
请求认证（Request authentication）
用于终端用户身份认证
JSON Web Token（JWT）
策略及其存储
配置格式如下：
配置生效范围（可配置网格，命名空间，工作负载（服务））
策略的更新，需要注意避免策略更新的中断
对于对等认证，你需要设置MTLS，调试时选择兼容模式，在调试完毕后再使用严格模式。
对于身份认证，你可以把新旧两个JWT同时配置进你的策略当中，当请求全部迁移到新的JWT里面再把旧的删除就可以了。
支持兼容模式
授权
授权默认就是启动状态，无需显式启用
授权策略通过创建 AuthorizationPolicy 实现，由选择器（Selector）、行为（Action）以及规则列表（Rules）组成。对于规则包括来源（From）、操作（To）和匹配条件（When）
示例：
授权策略的设置：
范围（目标）设置：metadata/namespace，selector
值匹配：精确、模糊、前缀、后缀
全部容许和拒绝
自定义条件
实验
Istio的安装与部署
安装步骤
准备kubernetes环境
在mac上安装docker桌面版
下载并安装Istioctl
下载最新版：
curl -L https://istio.io/downloadIstio | sh -进入下载目录，添加环境变量
export PATH=$PWD/bin:$PATH确认是否安装成功：
istioctl version使用Istioctl安装Istio
生成清单通过“kubectl apply -f”安装
istioctl manifest generate > $HOME/generated-manifest.yamlkubectl apply -f $HOME/generated-manifest.yaml验证安装
istioctl verify-install -f $HOME/generated-manifest.yamlistioctl dashboard 方式；例如：istioctl dashboard kiali
示例：部署Bookinfo、HttpBin等应用并实验
注入Sidecar
自动：
kubectl label namespace default istio-injection=enabled手动：kubectl apply -f <(istioctl kube-inject -f samples/bookinfo/platform/kube/bookinfo.yaml)部署应用
kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml确认服务、Pod 已启动
创建Ingress网关以保证对外可访问
kubectl apply -f samples/bookinfo/networking/bookinfo-gateway.yaml确认网关和访问地址
vi samples/bookinfo/networking/bookinfo-gateway.yaml浏览器访问地址以确认安装是否成功
动态路由：用
Virtual Service（虚拟服务）和Destination Rule（目标规则）设置路由规则配置之前我们先尝试多刷新下bookinfo的页面，可以观察到页面会在不显示星号、显示黑色星号、显示红色星号等情况轮询出现。也就是说会轮询访问reviewsV1版本
接下来需要我们通过配置，让所有请求都只访问reviewsV1版本
运行
kubectl apply -f samples/bookinfo/networking/virtual-service-all-v1.yaml以及kubectl apply -f samples/bookinfo/networking/destination-rule-all.yaml接着我们去访问页面，发现如何刷新都不会出现星标了，访问的一直都是reviewsV1，说明配置生效了。
Virtual Service（虚拟服务）和Destination Rule（目标规则）的应用场景：按服务版本路由
按比例切分流量
根据匹配规则进行路由
定义各种策略（负载均衡、连接池等）
网关
一个运行在网格边缘的负载均衡器
接收外部请求，转发给网格内的服务
配置对外的端口、协议与内部服务的映射关系
配置选项：
应用场景：
暴露网格内的服务给外界访问
访问安全（HTTPS、mTLS）
统一应用入口，API聚合
现在市面已经有许多网关应用，那么Istio为什么还要有自己的网关服务？答：Istio最核心的功能就是做流量控制，除了网格间的流量控制以外，它希望对进入网格以及出网格的流量也进行一个整体的统一的控制，因此也需要在边界上设置这样的网关产品。
服务入口
添加外部服务到网格内
管理到外部服务的请求
扩展网格
流量转移
蓝绿部署：指的是在你的生产环境中同时有两套完全一致的应用，其中一套正在服务于线上环境，所有的请求都打到这套应用上，当你的服务需要更新时，你直接在另外一套系统中部署新的版本，然后把流量切换到新的版本中。
蓝绿部署的优点是你可以随意地去安装备份的那一套环境，而不需要动线上的环境，即便出错也没有关系，同时因为有两套环境的存在，你也可以及时地回滚。不过它的成本比较高。
灰度发布
最开始所有的请求都指向老的版本，新版本部署之后，比如说只把0.05的流量打到新的版本，用它来进行测试，如果测试没有问题，然后在把0.5的流量打到新的版本，如果测试没有问题，最后将所有的流量都打到新的版本，完成发布。
A/B测试
用来比较A、B这两个版本的优劣。
ingress：控制进入网格的流量
服务的访问入口，接收外部请求并转发到后端服务
Istio: 针对 L4-6 协议，只定义接入点，复用 Virtual Service 的 L7 路由定
（Kubernetes: 针对L7协议（资源受限），可定义路由规则）
egress：实现访问外部服务
访问外部服务的方法：
配置
global.outboundTrafficPolicy.mode = ALLOW_ANY（不推荐该方式）使用服务入口（ServiceEntry）
配置 Sidecar 让流量绕过代理
配置 Egress 网关（推荐方式，方便配置路由规则以及流控策略）
Egress定义了网格的出口点，允许你将监控、路由等功能应用于离开网格的流量
超时重试：提升系统的健壮性和可用性
超时：控制故障范围，避免故障扩散
重试：解决网络抖动时通信失败的问题
熔断：“秒杀”场景下的过载保护是如何实现的？
熔断是一种过载保护的手段，目的是避免服务的级联失败（也就是说当某一个服务发生故障的时候，我们通过熔断这种机制来避免调用它的下游服务，避免级联错误，不断地扩散到整个系统中）
关键点：三个状态、失败计数器（阈值）、超时时钟
如上图所示，但服务累计的失败次数到达一定次数时，就会打开熔断器，当你再次调用时就会快速失败避免异常扩散，在熔断器打开的情况下还维护了一个时钟周期，当超过了这个时间就切换为半打开（熔断器）状态，将尝试地调用一下下游服务，如果调用失败则又切换为打开熔断器状态，否则切换为关闭熔断器状态。
故障注入：在Istio中实现一个“Chaos Monkey”
有目的的给系统注入故障，然后修复以增强系统鲁棒性（类似注射疫苗，然后人体修复，接着产生抗体）
流量镜像：解决线上问题排查的难题
实时复制请求到镜像服务
应用场景：
线上问题排查
观察生产环境的请求处理能力（压力测试）
复制请求信息用于分析
洞察你的服务：使用kiali观测你的微服务应用
微服务架构可视化的重要性
痛点
服务间依赖关系错综复杂
问题排查困难，扯皮甩锅时有发生
优势
梳理服务的交互关系
了解应用的行为与状态
什么是kiali
kiali来源于希腊语，意为望远镜
Istio 的可观察性控制台 通过服务拓扑帮助你理解服务网格的结构 提供网格的健康状态视图 具有服务网格配置功能
功能：
架构
使用Prometheus收集指标
简介：
架构：
利用Grafana可视化展示
简介：
Mesh Dashboard：查看应用（服务）数据 网格数据总览 服务视图 工作负载视图 Performance Dashboard：查看 Istio 自身（各组件）数据 Istio 系统总览 各组件负载情况
日志：如何获取Envoy的日志并进行调试
使用Jeager完成分布式追踪
分布式追踪概念
分析和监控应用的监控方法；查找故障点、分析性能问题；起源于Google的Dapper；
OpenTracing：API 规范、框架、库的组合
什么是Jaeger
开源、端到端的分布式追踪系统；针对复杂的分布式系统，对业务链路进行监控和问题排查
术语：
Span：逻辑单元；有操作名、执行时间；嵌套、有序、因果关系。
Trace：数据/执行路径；Span组合
Jaeger架构
安全
配置 TLS 安全网关
双重保障：为应用设置不同级别的双向TLS
授权策略：如何实现JWT身份认证与授权？
实战
最后更新于
这有帮助吗？
