作者: justmine
头条号: 大数据与云原生
微信公众号: 大数据与云原生
为了方便阅读, 微信公众号已按分类排版, 后续的文章将在移动端首发, 想学习云原生相关知识, 请关注我.
一, 回顾
云原生 - 体验 Istio 的完美入门之旅(一)
云原生 - Why is istio(二)
[请持续关注...]
如前所述, 业务微服务化后, 每个单独的微服务可能会有很多副本, 多个版本, 这么多微服务之间的相互调用, 管理和治理非常复杂, Istio 统一封装了这块内容在代理层, 最终形成一个分布式的微服务代理集群(服务网格). 管理员通过统一的控制平面来配置整个集群的应用流量, 安全规则等, 代理会自动从控制中心获取动态配置, 根据用户的期望来改变行为.
话外音: 借着微服务和容器化的东风, 传统的代理摇身一变, 成了如今炙手可热的服务网格.
Istio 就是上面 service mesh 架构的一种实现, 通过代理 (默认是 envoy) 全面接管服务间通信, 完全支持主流的通信协议 HTTP/1.1,HTTP/2,gRPC ,TCP 等; 同时进一步细分控制中心, 包括 Pilot,Mixer,Citadel 等.
话外音: 后面系列会详细介绍控制中心的各个组件, 请持续关注.
整体功能描述如下:
连接(Connect)
控制中心从集群中获取所有微服务的信息, 并分发给代理, 这样代理就能根据用户的期望来完成服务之间的通信(自动地服务发现, 负载均衡, 流量控制等).
保护(Secure)
所有的流量都是通过代理, 当代理接收到未加密流量时, 可以自动做一次封装, 把它升级成安全的加密流量.
控制(Control)
用户可以配置各种规则(比如 RBAC 授权, 白名单, rate limit ,quota 等), 当代理发现服务之间的访问不符合这些规则, 就直接拒绝掉.
观察(Observe)
所有的流量都经过代理, 因此代理对整个集群的访问情况知道得一清二楚, 它把这些数据上报到控制中心, 那么管理员就能观察到整个集群的流量情况.
二, 前言
作为服务网格的一个完整解决方案, 为了追求完美, Istio 高度抽象并设计了一个优雅的架构, 涉及到众多的组件, 它们分工协作, 共同组成了完整的控制平面. 为了更好地学习如何运用 Istio 的连接, 安全, 控制, 可观察性全面地治理分布式微服务应用, 先从战略上鸟瞰 Istio, 进一步从战术上学习 Istio 将更加容易, 故作者决定从可观察性开始 Istio 的布道, 先体验, 再实践, 最后落地, 一步步爱上 Istio, 爱上云原生, 充分利用云资源的优势, 解放应用开发工程师的双手, 使他们仅仅关注业务实现, 让专业的人做专业的事, 为企业创造更大的价值.
三, Why - 为什么需要分布式跟踪?
当业务微服务化后, 一次业务请求, 可能会涉及到多个微服务, 分布式跟踪可以对跨多个分布式服务网格的 1 个请求进行追踪分析, 并通过可视化的方式深入地了解请求的延迟, 序列化和并发, 充分地了解服务流量实况, 从而快速地排查和定位问题.
四, What - Istio 的分布式跟踪?
概述
Istio 利用 Envoy 的分布式追踪功能提供了开箱即用的追踪集成. 确切地说, Istio 提供了安装各种各种追踪后端服务的选项, 并且通过配置代理来自动发送追踪 span 到追踪后端服务.
话外音: Istio 目前支持的追踪后端服务包括 Zipkin,Jaeger,LightStep.
话外音: Istio 分布式追踪的整体功能, 请参考文末链接.
采样率
默认情况下, 使用 demo 配置文件安装时, Istio 会捕获所有请求的追踪信息, 即每次访问 /productpage 接口时, 都可以在 dashboard 中看到一条相应的追踪信息. 此采样频率适用于测试或低流量网格. 对于高流量网格(如: 生产环境), 请通过下面的两种方法之一来降低追踪采样频率:
在安装时, 使用可选项 values.pilot.traceSampling 来设置采样百分比.
在运行时, 通过编辑 istio-pilot deployment 并通过以下步骤来改变环境变量:
- root@just:~# kubectl -n istio-system get deploy istio-pilot -o YAML
- apiVersion: extensions/v1beta1
- kind: Deployment
- [...]
- name: istio-pilot
- namespace: istio-system
- [...]
- env:
- - name: PILOT_TRACE_SAMPLING
- value: "1"
- [...]
Istio 默认的追踪采样率为 1%, 即 100 个请求生成一次追踪报告, 有效值的范围从 0.0 到 100.0, 精度为 0.01.
五, How - Istio 如何配置分布式跟踪?
本篇以 zipkin 为例, 体验 Istio 的分布式追踪功能.
准备工作
请先部署 Istio 系统和在线书店例子, 详情请参考: 云原生 - 体验 Istio 的完美入门之旅(一).
部署
- istioctl manifest apply --set values.tracing.enabled=true \
- --set values.tracing.provider=zipkin
模拟请求
要查看追踪数据, 必须向服务发送请求. 请求的数量取决于 Istio 的追踪采样率, 默认为 1%, 即在第一个追踪报告可见之前, 需要发送至少 100 个请求.
使用如下命令向 productpage 服务发送 200 个请求:
for i in `seq 1 200`; do curl -s -o /dev/null http://$GATEWAY_URL/productpage; done
查看追踪报告
概览
从上可以看出, 产生了两份追踪报告, 完全符合追踪采集率.
请求完整链路
Span 详情
关于追踪报告的分析, 这里就不赘述了.
六, 总结
本篇先回顾了微服务架构的痛点, 以及服务网格的本质, 然后大致概述了 Istio 的整体功能, 最后从 why,what,how 的角度体验了 Istio 的可观察性特性. 除了分布式跟踪, Istio 的可观察性还包括: 日志, 监控, 敬请期待, 未完待续.
七, 最后
如果有什么疑问和见解, 欢迎评论区交流.
如果觉得本篇有帮助的话, 欢迎推荐和转发.
如果觉得本篇非常不错的话, 可以请作者吃个鸡腿, 创作的源泉将如滔滔江水连绵不断, 嘿嘿.
八, 参考
- https://istio.io/docs/tasks/observability/distributed-tracing/overview
- https://istio.io/docs/tasks/observability/distributed-tracing/zipkin
- https://www.envoyproxy.io/docs/envoy/v1.12.0/intro/arch_overview/observability/tracing
来源: https://www.cnblogs.com/justmine/p/12263558.html