【博客344】简述微服务新利剑：Istio

内容： 记录service msh的新代表产品：Istio

Istio的架构组成：

Istio 的架构可以说由两部分组成，分别是 Proxy 和 Control Plane。Proxy：就是SideCar，与应用程序部署在同一个主机上，应用程序之间的调用都通过Proxy 来转发，目前支持 HTTP/1.1、HTTP/2、gRPC 以及 TCP 请求。Control Plane：与 Proxy 通信，来实现各种服务治理功能，包括三个基本组件：
* Pilot
* Mixer
* Citadel

架构图：

Proxy：

ProxyIstio 的 Proxy 采用的是 Envoy，它是用 C++ 语言实现的，在性能和资源消耗上都
达到很好的效果。Proxy：既要作为服务消费者端的正向代理，又要作为服务提供者端的反向代理，一般需要具备：* 服务发现
* 服务注册
* 负载均衡
* 限流降级
* 超时熔断
* 动态路由
* 监控上报
* 日志推送Proxy主要包含以下几个特性：1、性能损耗低。因为采用了 C++ 语言实现，Envoy 能提供极高的吞吐量和极少的长尾延迟，
而且对系统的 CPU 和内存资源占用也不大，所以跟业务进程部署在一起不会对业务进程造成影响。2、可扩展性高。Envoy 提供了可插拔过滤器的能力，用户可以开发定制过滤器以满足自己特定需求。3、动态可配置。Envoy对外提供了统一的 API，包括 CDS（集群发现服务）、RDS（路由发现服务）
、LDS（监听器发现服务）、EDS（EndPoint 发现服务）、HDS（健康检查服务）、ADS（聚合
发现服务）等。通过调用这些 API，可以实现相应配置的动态变更，而不需要重启 Envoy。Envoy 是 Istio 中最基础的组件，所有其他组件的功能都是通过调用 Envoy 提供的 API，
在请求经过 Envoy 转发时，由 Envoy 执行相关的控制逻辑来实现的。

Pilot：

Pilot：作用是实现流量控制，它通过向 Envoy 下发各种指令来实现流量控制，它的架构如下图
所示。从架构图里可以看出，Pilot 主要包含以下几个部分：1、Rules API，对外封装统一的 API，供服务的开发者或者运维人员调用，可以用于流量控制。2、Envoy API，对内封装统一的 API，供 Envoy 调用以获取注册信息、流量控制信息等。3、抽象模型层，对服务的注册信息、流量控制规则等进行抽象，使其描述与平台无关。4、平台适配层，用于适配各个平台如 Kubernetes、Mesos、Cloud Foundry 等，把平台特定
的注册信息、资源信息等转换成抽象模型层定义的平台无关的描述。

Pilot 如何实现流量管理功能？

1. 服务发现和负载均衡

服务B也就是服务提供者注册到对应平台的注册中心中去，比如 Kubernetes 集群中的 Pod，启动
时会注册到注册中心 etcd 中。然后服务A也就是服务消费者在调用服务B时，请求会被Proxy拦截，
然后Proxy会调用Pilot查询可用的服务提供者节点，再以某种负载均衡算法选择一个节点发起调用。
除此之外，Proxy 还会定期检查缓存的服务提供者节点的健康状况，当某个节点连续多次健康检查
失败就会被从 Proxy 从缓存的服务提供者节点列表中剔除。

2. 请求路由Pilot 可以对服务进行版本和环境的细分，服务 B 包含两个版本 v1.5 和 v2.0-alpha，
其中 v1.5 是生产环境运行的版本，而 v2.0-alpha 是灰度环境运行的版本。当需要做A/B 测试时，希望灰度服务 B 的 1% 流量运行 v2.0-alpha 版本，就可以通过调用Pilot 提供的 Rules API，Pilot 就会向 Proxy 下发路由规则，Proxy 在转发请求时就按照给定的路由规则，把 1% 的流量转发给服务 B 的 v2.0-alpha 版本，99% 的流量转发给服务 B 的 v1.5 版本。

3. 超时重试缺省状态下，Proxy 转发 HTTP 请求时的超时是 15s，可以通过调用 Pilot 提供的 Rules API
来修改路由规则，覆盖这个限制。比如下面这段路由规则，表达的意思是 ratings 服务的超时时间
是 10s。

比如：
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:name: ratings
spec:hosts:- ratingshttp:- route:- destination:host: ratingssubset: v1timeout: 10s

除此之外，还可以通过修改路由规则，来指定某些 HTTP 请求的超时重试次数，
比如下面这段路由规则，表达的意思就是 ratings 服务的超时重试次数总共是 3 次，
每一次的超时时间是 2s。


apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:name: ratings
spec:hosts:- ratingshttp:- route:- destination:host: ratingssubset: v1retries:attempts: 3perTryTimeout: 2s

4. 故障注入Istio 还提供了故障注入的功能，能在不杀死服务节点的情况下，通过修改路由规则，
将特定的故障注入到网络中。它的原理是在 TCP 层制造数据包的延迟或者损坏，从而
模拟服务超时和调用失败的场景，以此来观察应用是否健壮。比如下面这段路由规则的
意思是对 v1 版本的 ratings 服务流量中的 10% 注入 5s 的延迟。


apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:name: ratings
spec:hosts:- ratingshttp:- fault:delay:percent: 10fixedDelay: 5sroute:- destination:host: ratingssubset: v1

而下面这段路由规则意思是对 v1 版本的 ratings 服务流量中的 10% 注入 HTTP 400 的错误。


apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:name: ratings
spec:hosts:- ratingshttp:- fault:abort:percent: 10httpStatus: 400route:- destination:host: ratingssubset: v1

Mixer：

Mixer 的作用是实现策略控制和监控日志收集等功能，实现方式是每一次 Proxy 转发的请求
都要调用 Mixer，它的架构请见下图。而且 Mixer 的实现是可扩展的，通过适配层来适配不
同的后端平台，这样的话 Istio 的其他部分就不需要关心各个基础设施比如日志系统、监控
系统的实现细节。

Mixer如何实现其功能的呢？

理论上每一次的服务调用 Proxy 都需要调用 Mixer，一方面检查调用的合法性，一方面要上报
服务的监控信息和日志信息，所以这就要求 Mixer 必须是高可用和低延迟的，那么 Mixer 是
如何做到的呢？下图是它的实现原理，从图中你可以看到 Mixer 实现了两级的缓存结构：Proxy 端的本地缓存。
为了减少 Proxy 对 Mixer 的调用以尽量降低服务调用的延迟，在 Proxy 这一端会有一层本
地缓存，但由于 Proxy 作为 SideCar 与每个服务实例部署在同一个节点上，所以不能对服务
节点有太多的内存消耗，所以就限制了 Proxy 本地缓存的大小和命中率。Mixer 的本地缓存。Mixer 是独立运行的，所以可以在 Mixer 这一层使用大容量的本地缓存，从而减少对后端基
础设施的调用，一方面可以减少延迟，另一方面也可以最大限度减少后端基础设施故障给服务调
用带来的影响。

Mixer如何进行策略监控与信息收集呢？

那么 Mixer 是如何实现策略控制和监控日志收集功能呢？1. 策略控制Istio 支持两类的策略控制，一类是对服务的调用进行速率限制，
一类是对服务的调用进行访问控制，它们都是通过在 Mixer 中配置规则来实现的。具体来讲，速率限制需要配置速率控制的 yaml 文件，每一次 Proxy 转发请求前都会先调用Mixer，Mixer 就会根据这个 yaml 文件中的配置，来对调用进行速率限制。比如下面这段配置表达的意思是服务默认访问的速率限制是每秒 5000 次，除此之外还定义了
两个特殊限制，第一个是 v3 版本的 reviews 服务请求 ratings 服务的速率限制是
每 5 秒 1 次，第二个是其他服务请求 ratings 服务的速率限制是每 10 秒 5 次。


apiVersion: config.istio.io/v1alpha2
kind: memquota
metadata:name: handlernamespace: istio-system
spec:quotas:- name: requestcount.quota.istio-systemmaxAmount: 5000validDuration: 1soverrides:- dimensions:destination: ratingssource: reviewssourceVersion: v3maxAmount: 1validDuration: 5s- dimensions:destination: ratingsmaxAmount: 5validDuration: 10s

而访问控制需要配置访问控制的 yaml 文件，每一次 Proxy 转发请求前都会先调用 Mixer，
Mixer 就会根据这个 yaml 文件中的配置，来对调用进行访问控制。比如下面这段配置表达的
意思是 v3 版本的 reviews 服务调用 ratings 服务就会被拒绝。


apiVersion: "config.istio.io/v1alpha2"
kind: rule
metadata:name: denyreviewsv3
spec:match: destination.labels["app"] == "ratings" &&source.labels["app"]=="reviews" && source.labels["version"] == "v3"actions:- handler: denyreviewsv3handler.denierinstances: [ denyreviewsv3request.checknothing ]

2. 监控和日志收集跟策略控制的实现原理类似，Mixer 的监控、日志收集功能也是通过配置监控
yaml 文件来实现的，Proxy 发起的每一次服务调用都会先调用 Mixer，把监控信息发给Mixer，
Mixer 再根据配置的 yaml 文件来决定监控信息该发到哪。

Cidatel：

Citadel：的作用是保证服务之间访问的安全，它的工作原理见下图，可见实际的安全保障并不是
Citadel 独立完成的，而是需要 Proxy、Pilot 以及 Mixer 的配合，具体来讲，Citadel
里存储了密钥和证书。通过 Pilot 把授权策略和安全命名信息分发给 Proxy。Proxy 与 Proxy 之间的调用使用双向 TLS 认证来保证服务调用的安全。最后由 Mixer 来
管理授权和审计。

总结：

1、Istio它是采用模块化设计，并且各个模块之间高度解耦2、Proxy专注于负责服务之间的通信，Pilot专注于流量控制，Mixer专注于策略控制以及
监控日志功能，而Citadel专注于安全。* 正是这种高度模块化的设计，使得 Istio 的架构极具扩展性和适配性，如果你想加强流量控制
方面的功能，可以在 Pilot 模块中定制开发自己的代码，而不需要修改其他模块；如果你想增加
一种监控系统支持，可以在 Mixer 模块中添加对这个监控系统的适配器，就能接入 Istio。3、虽然Istio由Google和IBM主导，但也没有完全与 Kubernetes 平台绑定，你也可以在Mesos
或者AWS运行Istio，可见它的适配性极强，这也是 Istio 的强大之处，以至于它的竞争对手
Linkerd 也开始支持 Istio，作为可选的 Proxy 组件之一。

【博客344】简述微服务新利剑：Istio相关推荐

客服系统微服务架构的演化
客服系统微服务架构的演化微服务要求服务协作服务治理服务治理 1 怀疑第三方坚持一条信念:"所有第三方服务都不可靠",不管第三方什么天花乱坠的承诺.基于这样的信念,我们需要 ...
奥运年08/07/19我正式加入博客园,开始.net的新征程^-^
今天,我正式加入博客园,开始.net的新征程,希望在此与各路高手学习交流,共同进步! 转载于:https://www.cnblogs.com/qjjnet/archive/2008/07/19/124 ...
WebAssembly 开启微服务新时代
整理 | 丁广辉责编 | 张红月出品 | CSDN(ID:CSDNnews) 如果从微服务的功能定义开始,很可能把这种模式定义为通过网络进行通信的REST服务.但当谈到编写微服务的程序 ...
博客凉凉，备份新浪博文图片或留下博友的评论要抓紧
博客时代结束了,新浪博客一直无法注册,博文列表也不显示了,提示系统维护中.最近访客模块没了,首页栏目没了,评论也丢了,每天都在删文.丢文.各种违禁词各种被加密被私密.. 再见了,博客. 新浪博客不显示 ...
终于在博客园安了个新家
终于在博客园安了个新家为什么是博客园安新家,是因为我原有的新浪博客太长的文章发不了. 附上我的新浪博客的链接 http://blog.sina.com.cn/szvitamin 转载于:https: ...
简述微服务框架中间件
CSDN话题挑战赛第2期参赛话题:Java微服务大家可分享关于Java微服务相关知识,包括但不限于Java微服务开发经验.架构组成.技术交流.中间件等内容,我们鼓励springcloud架构为基础 ...
微服务：简述微服务架构中的API网关
微服务:简述微服务架构中的API网关 API网关是任何微服务架构的重要组成部分.有了它我们可以在一个独立的模块上方便的处理一些非业务逻辑,可以让微服务本身专注在自身特定的功能上,使得每个微服务的开发更 ...
详解4种微服务框架接入Istio方案
本文分享自华为云社区<传统微服务框架接入Istio方案详解>,作者:香菜聊游戏 . 微服务的概念和原理微服务带来的问题微服务带来的好处: 解耦了业务,解耦了代码和架构,业务更紧凑,逻辑 ...
armbian nginx 部署博客_从零开始搭建服务器之更加优雅地部署项目
如果你需要经常性需要多处部署同样的项目,如果你曾经也遇到过"*明明在我电脑运行得好好的"问题,如果听说过 Docker 但还没用过,如果你不确定你到底需不需要 Docker ,那么 ...

【博客344】简述微服务新利剑：Istio

【博客344】简述微服务新利剑：Istio相关推荐

最新文章

热门文章