下载文档原格式
istio项目实践近年来，微服务架构已经成为了构建大型、复杂应用程序的首选方法。
然而，随着微服务数量的增加，服务之间的通信和管理变得越来越困难。
这就是为什么需要一个可以简化微服务之间通信和管理的解决方案，而istio项目就是这样一个解决方案。
istio是由Google、IBM和Lyft共同开源的一个用于微服务的服务网格框架。
它提供了可观测性、流量管理、策略管控和安全性等功能，可以帮助开发者更好地管理和控制微服务架构。
在istio项目的实践中，首先需要进行istio安装和配置。
istio支持多种部署方式，可以根据实际需求选择适合的方式进行部署。
安装完成后，需要对istio进行配置，包括配置服务入口、配置路由规则等。
配置完成后，istio就可以开始对微服务进行管理和控制。
在istio项目实践中，一个重要的功能是流量管理。
istio可以通过流量管理功能实现灰度发布、AB测试等功能。
通过配置路由规则，可以将一部分流量导入到新版本的微服务中进行测试，以确保新版本的稳定性和兼容性。
同时，也可以通过配置故障注入规则，模拟出不同的故障场景，以测试应用程序的容错性和恢复能力。
另一个重要的功能是策略管控。
istio可以通过策略管控功能实现访问控制、限流、重试等功能。
通过配置策略规则，可以限制特定用户或服务的访问权限，确保系统的安全性。
同时，也可以配置限流规则，限制某些服务的请求速率，避免因为某个服务的过载导致整个系统的崩溃。
此外，通过配置重试规则，可以在服务调用失败时自动进行重试，提高系统的可用性。
在istio项目实践中，可观测性也是一个重要的方面。
istio提供了丰富的监控和日志功能，可以帮助开发者及时发现和解决问题。
istio可以通过配置监控规则，收集微服务的指标数据，并将其展示在监控面板上。
同时，也可以通过配置日志规则，将微服务的日志信息收集和存储起来，方便开发者进行故障排查和性能优化。
安全性也是istio项目实践中需要关注的一个方面。
istio中outlierdection的阈值-回复Istio中的Outlier Detection阈值Istio是一个用于微服务的开源平台，它提供了一些有用的功能，以帮助管理和控制服务之间的流量。
其中之一是Outlier Detection （异常检测）功能，它用于检测和处理具有异常行为的服务实例。
Outlier Detection 使用阈值来决定何时将一个服务实例标记为异常，从而避免它们对整体系统的影响。
在本文中，我们将深入研究Istio中Outlier Detection的阈值，并逐步回答以下问题：1. 什么是Outlier Detection？2. Outlier Detection在Istio中的作用是什么？3. 如何配置Outlier Detection阈值？4. 阈值的含义和如何选择最佳阈值？现在让我们一步一步回答这些问题。
1. 什么是Outlier Detection？Outlier Detection是一个用于检测和处理具有异常行为的服务实例的技术。
服务实例可能由于各种原因而表现不稳定，例如网络问题、资源不足或程序错误。
Outlier Detection通过分析服务实例的行为模式，掌握其正常运行的范围，并定期进行健康检查，以确保它们表现良好。
一旦一个服务实例被标记为异常，Outlier Detection可以采取相应的措施，例如停止将流量发送到该实例。
2. Outlier Detection在Istio中的作用是什么？在Istio中，Outlier Detection的作用是监控和管理流经网格中的服务实例。
它可以帮助我们发现并隔离那些可能影响整体系统的故障或不稳定的服务实例。
通过及时发现这些异常实例并停止将流量发送给它们，Outlier Detection可以提高系统的可用性和稳定性。
3. 如何配置Outlier Detection阈值？在Istio中，我们可以通过使用“DestinationRule”资源来配置Outlier Detection的阈值。
智慧园区公共服务平台从SpringCloud微服务架构升级到服务网格（ServiceMesh）的设计与实现发布时间：2021-09-18T03:17:30.144Z 来源：《中国科技人才》2021年第16期作者：赵立杰[导读] 园区公共服务平台是智慧园区建设中重要的组成部分，园区服务智慧化可以给园区企业营造更好的发展软件环境，提高园区从业者的生活满意度、从而助力园区打造更好的营商环境。
上海阿法析地数据科技有限公司上海 200023摘要：园区公共服务平台是智慧园区建设中重要的组成部分，园区服务智慧化可以给园区企业营造更好的发展软件环境，提高园区从业者的生活满意度、从而助力园区打造更好的营商环境。
公司作为智慧园区的服务商，也建设了智慧园区服务平台，本着提升降低园区运营成本以及提升园区数据处理效率的目的，建设了基于SpringCloud微服务架构的综合管理平台，随着园区业务的应用推广、服务的不断增多，逐渐发现了诸多因SpringCloud架构的不足而导致的问题，例如平台的扩展性、稳定性与体验感不能满足需要。
本文将研究如何利用Istio服务网格（ServiceMesh）对平台来改造升级，重塑一个平台更加稳定、资源更加开放、模块化功能更加丰富、体系更加独立的公共服务平台。
关键词：智慧园区；公共服务平台；微服务结构；服务网格；设计一．引言随着产业化的不断推进，产业园区的发展需求也在随之逐渐提升，不仅需要极强的数据处理能力以便加强企业与员工之间的交流，还需要对园区各项设备进行统一管理，以便降低园区运营过程当中所产生的能耗。
通过物联网技术，传统产业园区已经普遍升级成为了智慧型园区，不仅各个数据单元可以通过网络平台互相联通，公共服务平台课课面向移动端（手机和平板电脑）、PC端、自助终端等访问终端、提供园区的线上服务平台、整合产业园区的产业资源、并为园区管理者提出科学决策提供参考，让产业园区的从业者生活工作便利、促进企业高质量发展。
⼆、Istio原理架构摘要从架构设计上来看，Istio服务⽹格在逻辑上分为控制平⾯和数据平⾯两部分。
其中，控制平⾯Pilot负责管理和配置代理来路由流量，并配置Mixer以实施策略和收集遥测数据；数据平⾯由⼀组以Sidecar⽅式部署的智能代理（Envoy）组成，这些代理可以调节和控制微服务及Mixer之间所有的⽹络通信。
1、Istio整体架构拓扑2、Istio控制平⾯介绍Istio的控制平⾯和Envoy的数据平⾯共同构成了⼀个引⼈注⽬的服务⽹格实现。
两者都拥有蓬勃发展和充满活⼒的社区，并且⾯向下⼀代服务架构。
Istio是独⽴于平台的，可运⾏于各种环境中，包括跨云、内部部署、Kubernetes、Mesos等。
你可以在Kubernetes 上部署Istio或在具有Consul的Nomad上部署。
Istio⽬前⽀持在Kubernetes上部署的服务、使⽤Consul注册的服务以及在虚拟机上部署的服务。
控制平⾯部分包括了Pilot、Mixer、Citadel和Galley四个组件Pilot Istio的Pilot组件⽤于管理流量，可以控制服务之间的流量流动和API调⽤，通过Pilot可以更好地了解流量，以便在问题出现之前发现问题。
这使得调⽤更加可靠、⽹络更加强健，即使遇到不利条件也能让应⽤稳如磐⽯。
借助Istio的Pilot，你能够配置熔断器、超时和重试等服务级属性，并设置常见的连续部署任务，如⾦丝雀发布、A/B测试和基于百分⽐拆分流量的分阶段发布。
Pilot为Envoy代理提供服务发现功能，为智能路由和弹性能⼒（如超时、重试、熔断器等）提供流量管理功能。
Pilot将控制流量⾏为的⾼级路由规则转换为特定于Envoy代理的配置，并在运⾏时将它们传播到Envoy。
此外，Istio提供了强⼤的开箱即⽤故障恢复功能，包括超时、⽀持超时预算和变量抖动的重试机制、发往上游服务的并发连接和请求数限制、对负载均衡池中的每个成员进⾏的定期主动运⾏状况检查，以及被动运⾏状况检查。
微服务部署工具IstioIstio是一个开源的服务网格，它可以帮助用户在Kubernetes环境中部署和管理微服务。
它可以实现跨服务的认证、路由、监视、限流、负载均衡等功能，这些功能有助于提高应用的可靠性、可用性和可扩展性。
Istio是一个基于Kubernetes的服务网格，它可以帮助客户端在Kubernetes环境中部署和管理微服务，使得客户端可以更快捷、更安全地完成应用程序的部署。
Istio可以实现跨服务的认证、路由、监视、限流、负载均衡等功能，这些功能有助于提高应用的可靠性、可用性和可扩展性。
Istio的功能主要有：1、认证：Istio可以简化认证的配置，让每个服务之间的认证变得容易。
它的认证功能可以基于用户名和密码、访问令牌、数字证书等来实现认证，从而保护服务免受未经授权的访问。
2、路由：Istio可以根据服务之间的路由规则，控制客户端的流量，从而实现负载均衡和服务调度。
它还可以根据路由规则实现服务与服务之间的隔离，从而避免一些安全风险。
3、监视：Istio可以收集服务的运行日志，并通过视图和图形来显示服务的性能，从而帮助用户快速定位和解决问题。
4、限流：Istio可以根据服务的负载情况，控制客户端的流量，从而避免服务出现过载情况，同时也可以保护服务免受恶意攻击的威胁。
5、负载均衡：Istio可以实现基于服务的负载均衡，它可以根据服务的负载情况、服务器的性能、网络状况等，来分担客户端的流量，从而提高服务的性能。
用户使用Istio部署微服务的方式主要有两种：一种是简单部署，可以使用Istio提供的命令行工具来安装Istio；另一种是使用Helm部署，可以使用Helm的Charts来安装Istio。
使用Istio部署微服务的步骤如下：1、准备环境：首先，用户需要准备Kubernetes的集群环境，以及在集群中安装Istio 的服务器。
2、安装Istio：用户可以使用Istio提供的命令行工具或Helm的Charts来安装Istio。
istio应用成功案例一、Istio应用成功案例Istio是一个开源的服务网格技术，旨在简化微服务架构中的网络通信、安全性、可观测性等方面的管理。
下面列举了10个Istio应用成功的案例，展示了Istio在不同领域的应用和成果。
1. 支付宝：支付宝作为中国最大的第三方支付平台之一，使用Istio 来管理其庞大的微服务架构。
Istio帮助支付宝简化了服务发现、流量管理和故障恢复等方面的任务，提升了支付宝系统的可靠性和性能。
2. 腾讯：腾讯的微服务架构中应用了Istio来管理服务之间的通信和安全。
Istio的流量管理功能帮助腾讯实现了灰度发布、A/B测试和金丝雀发布等高级部署策略，提高了系统的灵活性和可维护性。
3. 美团：美团作为中国最大的在线外卖和生活服务平台之一，使用Istio来管理其庞大的微服务架构。
Istio的流量管理功能帮助美团实现了智能路由、负载均衡和流量控制等功能，提升了系统的性能和可用性。
4. 京东：京东的微服务架构中应用了Istio来提供服务之间的安全保护和流量控制。
Istio的身份认证和授权功能帮助京东保护了其核心服务不受未经授权的访问，提高了系统的安全性和可靠性。
5. 阿里云：阿里云作为中国最大的云计算服务提供商之一，使用Istio来提供服务之间的网络通信和可观测性。
Istio的流量管理和监控功能帮助阿里云实现了服务的动态伸缩和故障诊断，提升了系统的弹性和可维护性。
6. 蚂蚁金服：蚂蚁金服作为中国领先的金融科技公司，使用Istio来管理其庞大的微服务架构。
Istio的流量管理和安全保护功能帮助蚂蚁金服实现了服务的灵活部署和安全隔离，提高了系统的可靠性和安全性。
7. 百度：百度的微服务架构中应用了Istio来提供服务之间的流量管理和可观测性。
Istio的流量管理和监控功能帮助百度实现了服务的动态调度和性能优化，提升了系统的性能和可用性。
8. 网易：网易的微服务架构中应用了Istio来提供服务之间的安全保护和流量控制。
istio使用手册Istio是一个开源的、可扩展的服务网格平台，旨在简化容器间通信、监控和管理。
它提供了一些有用的功能，如流量管理、安全性、策略和故障注入等。
本手册将介绍如何安装、配置和使用Istio，以及它提供的一些核心功能。
1. 安装Istio安装Istio之前，确保您的环境符合以下要求：- Kubernetes版本为1.9.0或更高版本。
- 您有相关的管理权限。
- 计算资源足够支持Istio的部署。
下面是安装Istio的步骤：1. 下载Istio的最新版本。
2. 解压缩下载的文件，并将解压缩后的目录添加到系统的PATH环境变量中。
3. 在Kubernetes集群中创建一个Istio系统命名空间。
4. 安装Istio的核心组件：- 使用kubectl命令安装Istio的CRDs（Custom Resource Definitions）。
- 安装Istio的命名空间和核心组件（Pilot、Citadel、Galley和Mixer）。
2. 配置Istio成功安装Istio后，您需要配置它以适应您的应用程序和环境的需求。
以下是一些常见的配置任务：- 配置流量管理规则：使用Istio的流量管理功能，您可以定义如何路由和控制流量，例如使用版本化路由进行A/B测试。
- 配置安全性规则：Istio提供了用于服务间的身份验证、访问控制和加密等安全功能。
您可以配置这些规则以确保服务间的安全通信。
- 配置监控和跟踪：Istio集成了Prometheus和Jaeger等流行的监控和跟踪工具，您可以配置它们以监控和分析服务的性能和行为。
3. 使用Istio的核心功能Istio提供了许多有用的核心功能，让您更方便地管理和监控应用程序。
以下是其中几个功能的简要介绍：- 流量管理：使用Istio，您可以灵活地控制服务间的流量路由和分发。
您可以定义基于请求头、标签和版本等条件的路由规则，以实现请求流量的动态转发和分发。
- 安全性：Istio提供了强大的安全功能，包括服务间的身份验证、访问控制和数据加密。
istio destinationrule详解Istio DestinationRule详解Istio DestinationRule是一种规则，用于管理Istio服务网格中的流量路由和负载均衡。
它通常与Istio VirtualService一起使用，用于定义服务的基础设施规则。
DestinationRule主要用于定义服务的负载均衡方式、服务版本选择和故障恢复策略等。
下面我们来逐步介绍如何使用Istio DestinationRule。
1. 创建一个DestinationRule在Istio服务网格中，DestinationRule通常表示一个服务的后端集合，我们可以通过以下方式来创建一个DestinationRule。
```apiVersion: networking.istio.io/v1alpha3kind: DestinationRulemetadata:name: samplespec:host: sample-service.default.svc.cluster.localtrafficPolicy:loadBalancer:simple: ROUND_ROBIN```在上面的例子中，我们创建了一个名为“sample”的DestinationRule，它指定了服务的名称和负载均衡策略。
这里我们选择ROUND_ROBIN策略，表示将流量均匀地分配给后端服务。
2. 指定服务的版本在某些场景下，我们需要根据服务的版本选择不同的后端服务。
可以通过以下方式来指定服务的版本。
```apiVersion: networking.istio.io/v1alpha3kind: DestinationRulemetadata:name: samplespec:host: sample-service.default.svc.cluster.localsubsets:- name: v1labels:version: v1- name: v2labels:version: v2```在上面的例子中，我们为“sample”服务指定了v1和v2两个版本。
为什么需要ServiceMeshUCloud App Engine on Kubernetes(后简称“UAEK”)是UCloud内部打造的一个基于Kubernetes 的，具备高可用、跨机房容灾、自动伸缩、立体监控、日志搜集和简便运维等特性计算资源交付平台，旨在利用容器技术提高内部研发运维效率，让开发能将更多的精力投入在业务研发本身，同时，让运维能更从容应对资源伸缩、灰度发布、版本更迭、监控告警等日常工作。
考虑到Kubernetes本来就是为自动部署、伸缩和容器化而生，再加上UCloud UAEK团队完成IPv6组网调研和设计实现后，一个成熟的容器管理平台很快正式在北京二地域的多个可用区上线了。
相比于过去申请管理虚拟机部署应用服务，Kubernetes确实带来了实实在在的便利，例如方便灵活的自动伸缩以及触手可及的微服务架构，只需简单配置即可实现跨可用区容灾等。
然而，微服务化又为系统架构带来许多新的问题，例如服务发现、监控、灰度控制、过载保护、请求调用追踪等。
大家已经习惯自行运维一组Zookeeper集群用以实现服务发现和客户端负载均衡，使用UAEK后能否免去运维Zookeeper的工作?为了监控业务运行状态，大家都需要在代码里加上旁路上报逻辑，使用UAEK是否能无侵入零耦合地实现监控上报?此外，过去很多系统模块间调用缺少熔断保护策略，波峰流量一打就瘫，使用UAEK是否能帮助业务方免去大规模改造呢?过去排查问题，尤其是调用耗时环节排查总是费时费力，使用UAEK能否为定位瓶颈提供方便的工具?显然，仅凭一个稳定的Kubernetes平台不足以解决这些问题。
因此，在UAEK立项之初，团队就把ServiceMesh作为一个必须实现的目标，任何在UAEK上部署的TCP后台服务，都能享受到ServiceMesh带来的这些特性：∙SideCar模式部署，零侵入，微服务治理代码与业务代码完全解耦;∙与Kubernetes平台融合的服务发现机制和负载均衡调度;∙提供灵活，实时，无需重启、能根据7层业务信息进行流量灰度管理功能;∙提供统一抽象数据上报API层，用于实现监控和访问策略控制;∙使用分布式请求链路追踪系统，快速追溯Bug，定位系统性能瓶颈;∙过载保护机制，能在请求量超过系统设计容量时自动触发熔断;∙能在服务上线前提供故障模拟注入演习剧本，提前进行故障处理演练;∙这样，使用UAEK部署应用服务后，即可从小范围按账号灰度上线开始，通过陆续地监控观察，轻松掌握版本异常回退、扩大灰度范围、全量发布、过载保护、异常请求定位追踪等信息。
为什么是Istio?关于ServiceMesh的实现，我们重点考察了Istio。
通过前期的调研和测试，我们发现Istio的几个特性能很好满足UAEK的需求：∙完美支持Kubernetes平台;∙控制面和数据转发面分离;∙Sidecar部署，掌控所有服务间调用流量，无上限的控制力;∙使用Envoy作为Sidecar实现，Envoy使用C++11开发，基于事件驱动和多线程机制运行，性能好并发能力强，媲美NGINX;∙对业务的代码和配置文件零侵入;∙配置简单，操作方便，API完善。
整个服务网格分成控制面板和数据面两大部分。
数据面指的就是注入到应用Pod中的Envoy容器，它负责代理调度模块间的所有流量。
控制面分为Pilot，Mixer和Citadel三大模块，具体功能如下：∙Pilot负责向Kubernetes API获取并Watch整个集群的服务发现信息，并向Envoy下发集群服务发现信息和用户定制的路由规则策略。
∙Mixer分为Policy和Telemetry两个子模块。
Policy用于向Envoy提供准入策略控制，黑白名单控制，QPS流速控制服务;Telemetry为Envoy提供了数据上报和日志搜集服务，以用于监控告警和日志查询。
∙Citadel为服务和用户提供认证和鉴权、管理凭据和 RBAC。
∙此外Istio为运维人员提供了一个叫istioctl的命令行工具，类似kubernetes的kubectl。
运维编写好路由规则yaml文件后，使用istioctl即可向集群提交路由规则。
Istio整体工作的原理和流程细节非常复杂，所涉及到的技术栈有一定的深度和广度。
这里只概括一下大体过程：∙运维人员使用istioctl或者调用API向控制层创建修改路由规则策略。
∙Pilot向Kube APIServer获取并watch集群服务发现信息。
∙部署应用程序时，Istio会在pod的部署配置中注入Envoy容器，Envoy会通过iptables nat redirect劫持代理pod中的全部TCP流量。
∙Envoy会实时从Pilot更新集群的服务发现信息和路由规则策略，并根据这些信息智能调度集群内的流量。
∙Envoy会在每次请求发送前向Mixer Policy发送Check请求检查该请求是否收策略限制或者配额限制，每次请求接收后会向Mixer Telemetry上报本次请求的基本信息，如调用是否成功、返回状态码、耗时数据。
∙Citadel实现了双向TLS客户端证书生成与注入，服务端密钥和证书的下发注入，以及K8S RBAC访问控制。
Istio在UAEK环境下的改造之路经过上述的调研和与一系列测试，UAEK团队充分认可Istio的设计理念和潜在价值，希望通过利用Istio丰富强大的微服务治理功能吸引更多的内部团队将服务迁移到UAEK环境中。
然而，事实上，在UAEK上接入Istio的过程并非一帆风顺。
最早开始调研Istio的时候，Istio 还在0.6版本，功能并不完善，在UAEK环境中无法开箱即用。
IPv6问题的解决我们首先碰到的问题是，UAEK是一个纯IPv6网络环境，而Istio对IPv6流量的支持并不完备，部分组件甚至无法在IPv6环境下部署。
在介绍具体改造案例之前，先了解下Istio Sidecar是如何接管业务程序的流量。
如上图所描述，Istio会向应用Pod注入两个容器：proxy-init容器和envoy容器。
proxy-init容器通过初始化iptables设置，将所有的TCP层流量通过nat redirect重定向到Envoy监听的15001端口。
以入流量为例，Envoy的服务端口接收到被重定向到来的TCP连接后，通过getsocketopt(2)系统调用，使用SO_ORIGINAL_DST参数找到该TCP连接的真实目的地IP地址，并将该请求转发到真实目的IP。
然而，我们发现在IPv6环境下，Envoy无法劫持Pod的流量。
通过抓包观察和追溯源码发现，Pod启动的时候，首先会运行一个iptables初始化脚本，完成pod内的nat redirect配置，将容器内的TCP出入流量都劫持到Envoy的监听端口中，但这个初始化脚本没有ip6tables的对应操作并且discard了所有IPv6流量，因此我们修改了初始化脚本，实现了IPv6的流量劫持。
一波刚平，一波又起。
完成IPv6流量劫持后，我们发现所有访问业务服务端口的TCP流量都被Envoy重置，进入Envoy容器中发现15001端口并没有开启。
追溯Envoy和Pilot源码发现，Pilot给Envoy下发的listen地址为0:0:0:0:15001, 这是个IPv4地址，我们需要Envoy监听地址的为[::0]:15000，于是继续修改Pilot源码。
经过上述努力，应用服务端程序Pod终于能成功Accept我们发起的TCP连接。
但很快，我们的请求连接就被服务端关闭，客户端刚连接上就立刻收到TCP FIN分节，请求依然失败。
通过观察Envoy的运行日志，发现Envoy接收了TCP请求后，无法找到对应的4层流量过滤器(Filter)。
深入跟进源码发现，Envoy需要通过getsocketopt(2)系统调用获取被劫持的访问请求的真实目的地址，但在IPv6环境下Envoy相关的实现存在bug，如下代码所示。
由于缺少判定socket fd的类型， getsocketopt(2)传入的参数是IPv4环境下的参数，因此Envoy无法找到请求的真实目的地址，遂报错并立刻关闭了客户端连接。
发现问题后，UAEK团队立刻修改Envoy源码，完善了getsocketopt(2) 的SO_ORIGINAL_DST选项的IPv6兼容性，然后将这一修改提交到Envoy开源社区，随后被社区合并到当前的Master分支中，并在Istio1.0的Envoy镜像中得到更新使用。
到此为止，Istio SideCar终于能在UAEK IPv6环境下正常调度服务间的访问流量了。
此外，我们还发现Pilot、Mixer等模块在处理IPv6格式地址时出现数组越界、程序崩溃的情况，并逐一修复之。
性能评估Istio1.0发布之前，性能问题一直是业界诟病的焦点。
我们首先考察了增加了Envoy后，流量多了一层复制，并且请求发起前需要向Mixer Policy进行一次Check请求，这些因素是否会对业务产生不可接收的延迟。
经过大量测试，我们发现在UAEK环境下会比不使用Istio时增加5ms左右的延迟，对内部大部分服务来说，这完全可以接受。
随后，我们重点考察了整个Istio Mesh的架构，分析下来结论是，Mixer Policy和Mixer Telemetry很容易成为整个集群的性能短板。
由于Envoy发起每个请求前都需要对Policy服务进行Check请求，一方面增加了业务请求本身的延迟，一方面也给作为单点的Policy增大了负载压力。
我们以Http1.1请求作为样本测试，发现当整个网格QPS达到2000-3000的时候，Policy就会出现严重的负载瓶颈，导致所有的Check请求耗时显著增大，由正常情况下的2-3ms增大到100-150ms，严重加剧了所有业务请求的耗时延迟，这个结果显然是不可接受的。
更严重的是，在Istio 0.8以及之前的版本，Policy是一个有状态的服务。
一些功能，如全局的QPS Ratelimit配额控制，需要Policy单个进程记录整个Mesh的实时数据，这意味着Policy服务无法通过横向扩容实例来解决性能瓶颈。
经过取舍权衡，我们目前关闭了Policy服务并裁剪了一些功能，比如QPS全局配额限制。
前面提到过，Mixer Telemetry主要负责向Envoy收集每次请求的调用情况。
0.8版本的Mixer Telemetry也存在严重的性能问题。
压测中发现，当集群QPS达到2000以上时，Telemetry实例的内存使用率会一路狂涨。
经过分析定位，发现Telemetry内存上涨的原因是数据通过各种后端Adapter消费的速率无法跟上Envoy上报的速率，导致未被Adapter处理的数据快速积压在内存中。
