随着项目代码量的不断增加,冗余的代码量就像屋里的杂物越积越多,项目的维护和交接变得越来越困难。微服务的思想油然而生,未来微服务的数量将会非常庞大,如何治理微服务也变得非常重要。本文作者将带领大家对微服务管理工具 istio 进行初探,并对其组件 mixer 进行了详细分析。
我们现在正在尝试将业务微服务化,对现在热门的微服务治理 istio 也开始研究并试用。今天我们就对 istio 的 mixer 组件做一些初步的学习介绍。
既然是初学篇,先简单说一下 istio 的由来。
1 背景简介
单体应用的历史悠长,我们尝过它的优势,也吃过它的苦头。在业务不太大的时候,人力也有限的情况下。 单体应用只用一个 tar 包就可以搞定所有。mvc 是经典的模式。 但是随着项目的扩大,人员的更替。项目的代码量不断增加,接替的人员更容易写新的逻辑,冗余的代码量就像屋里的杂物,越积越多。导致后来,没人敢大胆的修改代码,将修改的代码上线也是异常惊心的旅程。所以我们想用微服务从根本上解决这样的问题,它轻便,松耦合,不限技术栈,给我们带来了希望。
当然我们知道采用微服务化,未来微服务的数量将会庞大。所以需要一个得力的工具能帮助我们治理微服务,就好比现在的 k8s 对容器。我们经过调研,最终选择 istio 做尝试。
我们今天主要学习 mixer 组件,采用拨洋葱的方式分析 mixer 和监控的那点关系。
2 mixer 主要有两个作用
策略:每次请求来,需要 check 是通过还是拒绝。
遥测: 每次请求的状态相关数据上报。
3 mixer 使用
策略对应 pod 的名字是 Policy,可以登陆容器,看一下进程的启动参数。
策略的优势明显,缺点也明显,即损失性能。 因为 Envoy 会在每次请求发送前向 Mixer Policy 发送 Check 请求,检查该请求是否受策略限制或者配额限制。
解决方式:
1.一种是关闭 check,不用每次请求都 check 一下。–set global.disablePolicyChecks=true 可以关闭策略检查。
2.一种是官方策略:mixer cache。
遥测对应 pod 的名字是 telemetry,可以登陆容器,看一下进程的启动参数,和 policy 的差别。
遥测的优势明显,收集到所有的数据。也有一个缺点,即负载问题。 因为 Envoy 每次请求接收后会向 Mixer Telemetry 上报本次请求的基本信息,如调用是否成功、返回状态码、耗时数据。
解决方式:
1.telemetry 起多个 pods,分担压力。
2.官方策略:Envoy report 采用异步模式,Envoy 会向 Mixer 上报日志、监控(log、metrics)等原始数据。
4 mixer 原理
策略缓存的原理
缓存结构定义:
referenced_map 用来保存哪些属性组合已经被缓存,比如 {“k1”: “a,b,c”} 这样表示当前只有一个属性组合”a,b,c”被保存。
cache 用来保存输入的签名(简单理解为有效输入内容”a=1,b=2,c=3”的 hash 结果)和 check 结果(简化为 true/false 表示是否通过),比如 { “a=1,b=2,c=3”: “true” }。
引入一个重要概念:absence key。 第一层缓存 referenced_map 可以为 {“k1”: “a,b,c”, “k2”: “a,b,c 不存在” }。
更详细的缓存过程,后面会有一篇单独的文章讲它。
遥测上报监控原理
上报的结构体定义。
通过日志查看,上报的数据格式为一些原始的属性值。
数据到达 mixs 端。再做一些加工处理。
然后把数据分发对应的 Template 里。Flush 再让 logentry 和 Metric 等调用各自的 adapter 对数据进行处理,由于各自的 adapter 没有依赖关系,所以这里使用了 golang 的协程进行异步处理。
这时候,登陆 istio 自带的 grafana,就能看到 istio 系统的监控。
本文转载自公众号 360 云计算(ID:hulktalk)。
原文链接:
https://mp.weixin.qq.com/s/V-NEmnEZ5ZYKRpRevMzQJQ
评论