当前位置：首页 > news >正文

【云原生 | 从零开始学istio】一、Istio介绍—服务网格

news 来源：原创 2024/5/19 12:28:37

在这里插入图片描述

istio介绍

前言
Istio 介绍
- 服务注册和发现
- 负载均衡
- 故障恢复
- 服务度量
- 灰度发布
写在最后

前言

经过了docker与k8s的学习，终于到了服务网格这一章了，经过深思，决定到了两万粉丝再把docker和k8s的文章改成收费专栏，所以想看的小伙伴们抓紧了！

Istio 介绍

官方解释：An open platform to connect, secure, control and observe services.

翻译过来，就是”连接、安全加固、控制和观察服务的开放平台“。开放平台就是指它本身是开源的，服务对应的是微服务，也可以粗略地理解为单个应用。

在这里插入图片描述
1、连接（Connect）：智能控制服务之间的调用流量，能够实现灰度升级、AB 测试和蓝绿部署等功能

2、安全加固（Secure）：自动为服务之间的调用提供认证、授权和加密。

3、控制（Control）：应用用户定义的 policy，保证资源在消费者中公平分配。

4、观察（Observe）：查看服务运行期间的各种数据，比如日志、监控和 tracing，了解服务的运行情况。

Istio 是 ServiceMesh 的产品化落地，可以通过在现有的服务器新增部署边车代理(sidecar proxy)，应用程序不用改代码，或者只需要改很少的代码，就能实现如下基础功能：

1、帮助微服务之间建立连接，帮助研发团队更好的管理与监控微服务，并使得系统架构更加安全；

2、帮助微服务分层解耦，解耦后的 proxy 层能够更加专注于提供基础架构能力

例如：

（1）服务发现(discovery);
（2）负载均衡(load balancing);
（3）故障恢复(failure recovery);
（4）服务度量(metrics);
（5）服务监控(monitoring);
（6）A/B 测试(A/B testing);
（7）灰度发布(canary rollouts);
（8）限流限速(rate limiting);
（9）访问控制(access control);
（10）身份认证(end-to-end authentication)。

服务注册和发现

在这里插入图片描述

RPC：RPC（Remote Procedure Call）远程过程调用，简单的理解是一个节点请求另一个节点提供的服务

负载均衡

把前端的请求分发到后台多个服务器

故障恢复

出现故障具备自恢复的能力

服务度量

对于 HTTP，HTTP/2 和 GRPC 流量，Istio 生成以下指标：

1、请求计数（istio_requests_total）：这是一个用于累加每个由 Istio 代理所处理请求的 COUNTER 指标。

2、请求持续时间（istio_request_duration_seconds）：这是一个用于测量请求的持续时间的 DISTRIBUTION 指标。

3、请求大小（istio_request_bytes）：这是一个用于测量 HTTP 请求 body 大小的 DISTRIBUTION 指标。

4、响应大小（istio_response_bytes）：这是一个用于测量 HTTP 响应 body 大小的 DISTRIBUTION 指标。

对于 TCP 流量，Istio 生成以下指标：

1、Tcp 发送字节数（istio_tcp_sent_bytes_total）：这是一个用于测量在 TCP 连接下响应期间发送的总字节数的 COUNTER 指标。

2、Tcp 接收字节数（istio_tcp_received_bytes_total）：这是一个用于测量在 TCP 连接下请求期间接收的总字节数的 COUNTER 指标。

3、Tcp 打开连接数（istio_tcp_connections_opened_total）：这是一个用于累加每个打开连接的 COUNTER 指标。

4、Tcp 关闭连接数 (istio_tcp_connections_closed_total) : 这是一个用于累加每个关闭连接的 COUNTER 指标。

灰度发布

灰度发布也叫金丝雀发布，起源是，矿井工人发现，金丝雀对瓦斯气体很敏感，矿工会在下井之前，先放一只金丝雀到井中，如果金丝雀不叫了，就代表瓦斯浓度高。

在这里插入图片描述

在灰度发布开始后，先启动一个新版本应用，但是并不直接将流量切过来，而是测试人员对新版本进行线上测试，启动的这个新版本应用，就是我们的金丝雀。如果没有问题，那么可以将少量的用户流量导入到新版本上，然后再对新版本做运行状态观察，收集各种运行时数据，如果此时对新旧版本做各种数据对比，就是所谓的 A/B 测试。

当确认新版本运行良好后，再逐步将更多的流量导入到新版本上，在此期间，还可以不断地调整新旧两个版本的运行的服务器副本数量，以使得新版本能够承受越来越大的流量压力。直到将 100%的流量都切换到新版本上，最后关闭剩下的老版本服务，完成灰度发布。

如果在灰度发布过程中（灰度期）发现了新版本有问题，就应该立即将流量切回老版本上，这样，就会将负面影响控制在最小范围内。