istio组件mixer初学篇

 袁小花 360云计算

女主宣言

随着项目代码量的不断增长，冗余的代码量就像屋里的杂物越积越多，项目的维护和交接变得愈来愈困难。微服务的思想油然而生，将来微服务的数量将会很是庞大，如何治理微服务也变得很是重要。本文做者将带领你们对微服务管理工具istio进行初探，并对其组件mixer进行了详细分析。

PS：丰富的一线技术、多元化的表现形式，尽在“360云计算”，点关注哦！

咱们如今正在尝试将业务微服务化，对如今热门的微服务治理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系统的监控。