著者𞓜 王晨雨𞓜 校订人 董梅𞓜 1、阅读指南 网易舒凡轻舟微服务团队很早就开始使用istio作为服务网格。在实践过程中，我们开发了多个istio外围模块，方便我们和网易集团内部客户使用 istio。为了回馈社区，我们系统地整理了这些模块，并选择其中一些模块在2021年初开放slim项目（github.com）/slime- io/粘液）。
slim项目旨在解决istio使用中的痛点，方便用户使用istio的高级功能，始终坚持无需任何定制转换即可无缝连接 istio的原则，这大大降低了使用门槛
过去一年来，slim在架构、功能和工程方面进行了许多改变和尝试，并且有了很大的改进。2021 12月，slime被邀请加入istio生态系统，正式成为 istio生态系统-集成成员
今天，本文将介绍slime现阶段的主要功能，重点介绍延迟加载和智能限流模块，并展望未来的发展。希望更多的ServiceMesher能够了解slime，参与slime，并更轻松地一起使用服务网格
2。延迟加载 2.1和后台 istio的全推性能是所有istio用户都必须面对的问题
众所周知，istio 在早期的配置和分发非常粗糙和直接的全推。这意味着，随着服务网格中业务规模的不断扩大，越来越多的内容需要通过控制面分发并通过数据面接收，这将不可避免地导致性能问题。集群中通常有多个业务系统。业务系统的应用程序感知所有业务系统的配置，这意味着推送大量冗余配置是不合理的。如下图左侧所示，a 仅与B相关，但C和D的配置被推送。另一个问题是推送的频率很高。当服务更改时，控制平面应通知数据平面的所有sidecarproxy
因此，istio版本1.1提供了一个解决方案-Sidecar CRD（本文将其称为sidecarscope，以区别于特使实现的 sidecarproxy）。用户可以在sidecarscope中描述sidecarproxy需要关注的服务信息，从而屏蔽不相关服务配置的发布。结果如上图右侧所示。为服务配置sidecarscope 后，简化接收的配置，不包括不相关的配置。同时，将不会再次通知不相关服务的配置更改，从而降低推送频率
一个典型的侧视镜示例如下。该示例表明，sidecarproxy感知的命名空间prod1和istio- 系统中的所有服务以及命名空间prod2中的评级服务配置信息
apiVersion：networking。istio公司。io/V1Alpha3Find:Sidecarmetadata：名称：默认 命名空间：prod1spec：出口：-主机：-“引用”；产品1/“引用”；- ”等；产品2/评级。prod2.svc。簇“本地”；- istio-系统/
istio提供的sidecarscope可以解决配置完全分布的问题。看来问题已经解决了。然而，在实践中，很难手动管理侧车镜。一方面，服务所依赖的信息不容易分类。另一方面，一旦配置错误，就会导致调用中出现问题。这对服务网格的大规模实现非常不利。我们渴望更智能地管理sidecarscope
2.2值延迟加载模块用于解决上述问题。延迟加载可以自动连接到服务网格，并在转发过程中支持istio的所有网络治理功能，从而解决无性问题。它可以帮助业务人员使用 sidecarscope而无需直接管理
我们认为服务依赖可以分为在操作过程中不断变化的动态服务依赖和业务人员可以提前知道的静态服务依赖。对于动态依赖，我们设计了实时获取服务依赖的机制，并修改了sidecarscope；对于静态依赖，我们重点简化配置规则，使其更加人性化
2.3动态配置更新 延迟加载包含Global-Sidecar和lazload控制器是两个组件
Global-侧车：侧车组件。当源服务找不到目标服务时，它会转发sidecar并生成相应的服务相关度量 lazload controller：要处理G的控制组件lobal-对于sidecar报告的度量，修改源服务的sidecarscope并向其添加相应的配置。简化的动态配置更新过程如下所示。服务a的sidecarscope最初为空，没有服务B的配置信息。服务a启动对服务B的首次访问。由于服务a的sidecarproxy没有服务B的配置信息，因此请求被发送到底部组件Global- 侧车𞓜 袋底组件Global-Sidecar具有完整的服务配置信息，其中自然包括服务B。它将请求转发给服务B。第一个请求成功，并生成Metric(A.->B)
Lazload控制器感应Metric(A.->B)，修改sidecarscope a以添加服务B的配置𞓜 当服务a第二次访问服务B时，服务a的sidecarproxy已经配置了服务B，请求直接访问服务B的详细流程图如下：𞓜 servicefence是在lazy loading中引入的一个CRD，用于存储与服务相关的度量并实现sidecarscope
2.4静态配置增强的更新𞓜 在延迟加载的早期开发中，我们重点关注动态服务依赖性的获取，这似乎是智能的、无需担心的。然而，在实践中，我们发现，出于安全原因，许多用户通常希望直接将一些规则配置到 sidecarscope中，即配置静态服务依赖项。因此，我们开始考虑如何灵活配置静态依赖项
因此，我们设计了一组有用的静态规则，并将其写入servicefence（是的，CRD用于在动态配置更新中存储度量，在这里起到了新的作用）。lazload控制器然后根据这些规则更新相应的sidecarscope
我们提供了三种类型的静态配置规则：𞓜 依赖某些命名空间中的所有服务 依赖具有某些标签的所有服务 依赖特定服务 此处以标签匹配为例。如果应用程序部署如下图所示 现在为服务productpage启用延迟加载，那么productpage的依赖规则是𞓜 所有带有label app的服务：详细信息 所有带有label app的服务：评论和版本：V2 然后相应的servicefence写入如下
-- -apiVersion：微服务。粘液io/V1Alpha1Find:ServiceFencemetadata： 名称：productpage命名空间：defaultspec：启用：true labelSelector：#匹配 服务标签，多个选择器是“或”关系-选择器：应用程序： 详细信息-选择器：#一个选择器中的标签是“and”关系应用程序： 审阅版本：v2 lazload controller将根据实际匹配结果填充sidecarscope。实际获得的侧视镜如下所示。选择上图中的所有绿色服务 apiVersion：网络。istio公司。io/v1beta1kind:Sidecarmetadata:name:
productpage命名空间：defaultspec：出口：-主机：- ‘/详细信息。ns1.svc。簇本地’- ‘/详细信息。ns2.svc。簇本地’- ‘/详细信息。ns3.svc。簇本地’- ‘/评论。ns2.svc。簇本地’- istio- 系统/* #istio部署的NS- mesh-操作员/* #lazload部署的NS workloadselector： 标签：app:productpage 最后，我们不需要在联机之前反复确认是否已填写所有服务依赖项，更不用说在服务依赖项更改时手动修改sidecarscope。配置两三个servicefence 规则来处理所有
2.5公制类型𞓜 在第2.3章中，我们解释了度量是动态依赖生成的根源。目前，延迟加载支持两种度量类型：Prometheus和accesslog
使用Prometheus模式，指标由每个业务应用程序的sidecarproxy生成。Lazload控制器查询普罗米修斯以获取指示器。此模式要求服务网格与Prometheus
接口；使用accesslog模式，指示器源为global-侧车检修日志。Global-Sidecar 在转发时，它将生成一个固定格式的accesslog，并将其发送给lazload controller进行处理。此模式不需要外部依赖项，并且更具可移植性
2.6使用模式-延迟加载模块有两种使用模式，命名空间模式和集群模式。在这两种模式中，lazload controller 是全局唯一的。区别在于Global-Sidecar是命名空间级别，即集群级别。如下图所示，对于n个名称空间，名称空间模式下延迟加载的组件数为o(N)群集模式为o(一)。 现在我们更喜欢使用集群模式。如上图所示，每个集群只需部署两次部署，简单明了
3。智能流量限制 3.1背景 随着istio移除混合器，在服务网格中实现流量限制变得困难
少数情况：特使的本地限流组件功能简单，并且无法实现全局共享、全局共享限流等高级使用 复杂配置：本地限流需要特使内置插件特使本地的帮助。Ratelimit，用户必须面对复杂的envoyfilter配置𞓜 条件是固定的：能够根据实际情况自动调整电流限制配置，如资源利用率 3.2值 为了解决问题，我们推出了智能电流限制模块。智能限流模块具有许多优点。具体来说，它有许多场景：支持局部限流、全局均布限流和全局共享限流。易于配置：易于配置且可读，无需配置envoyfilter。条件适应：可结合普罗米修斯度量动态计算限流触发的条件，实现自适应限流效果。3.3 我们设计了一个新的CRD-SmartLimitor，其配置规则接近自然语义。模块的逻辑分为两部分𞓜 smartlimit控制器获取监控数据，更新smartlimit Cr 将smartlimit Cr转换为envoyfilter 限流模块的架构如下 红色为本地限流，绿色为全局共享限流，蓝色为全局共享限流 3.4本地限流𞓜 局部限流是最基本的使用场景。SmartLimitor为服务的每个pod设置固定的电流限制值。底层依赖于特使内置插件 特使本地。费率限制标识字段为行动策略：单一。
例如，reviews服务的每个pod的9080端口限制为每分钟60次
apiVersion:microservice。粘液io/V1Alpha2Find:SmartLimitermetadata：名称： 审阅命名空间：defaultspec：集合：\uBase：#匹配所有服务、关键字\uBase或您定义的子集，例如V1描述符：-措施：#限流规则fill\uu间隔：秒：60配额： “100”策略：“single”条件：“true”#始终执行电流限制目标：端口：9080𞓜 3.5全局平均限流 全局平均限流功能，然后根据用户设置的总限流数平均分配给每个pod。底层依赖于特使内置插件 特使本地。费率限制标识字段为行动策略：平均值下面是一个示例，表明reviews服务的所有POD的9080端口限制了当前每分钟60次。每个pod的具体限制时间由配额
apiVersion:microservice计算的操作确定。粘液io/V1Alpha2Find:SmartLimitermetadata：名称： 审阅命名空间：defaultspec：集合：\uBase：描述符：-操作： fill\uu间隔：秒：60配额：“100/{.\u base.pod}}”#如果reviews实例数为2，则每个pod限制为每分钟50次策略：‘average’条件：‘true’目标：端口：9080 3.6全局共享流限制 全局共享流限制限制目标服务的所有pod可以访问的总次数，而不限制为作为全局共享流限制的平均值。它更适合访问不均匀的场景。此方案将维护一个全局计数器。底层取决于特使插件特使过滤器。提供的全局计数功能。标识字段为行动策略： 全局
下面是一个示例，它显示reviews服务的所有pod的9080端口将流量限制为每分钟60次，并且不均匀地分布到每个pod
apiVersion:microservice。粘液io/V1Alpha2Find:SmartLimitermetadata：名称： 审阅命名空间：defaultspec：集合：\uBase：#rls：“出站 18081
”rate- 限制。istio-系统svc。簇Local’如果未指定，默认地址为描述符：-操作： fill\u间隔：秒：60配额：‘100’策略：‘global’条件：‘true’ 目标：端口：9080 3.7自适应限流 在上述三种情况下，触发电流限制的条件字段可以是固定值（true），也可以是普罗米修斯查询的计算结果 。后者是自适应限流。此场景与上述三个场景交叉相关
用户可以自定义要获取的监控指标，例如定义一个处理器cpu总和，其值等于 sum(container\cpu\uuUsage\uSeconds\uTotal{命名空间=“$命名空间”，pod=~“$pod\u名称”，映像=“，”})稍后，您可以将条件 触发电流限制设置为{.\u base.cpu.sum}}>100实现自适应限流
示例如下，这意味着只有当CPU使用率值大于100时，reviews服务每个pod的9080端口才限制为每分钟60次。与3.4 中的示例相比，该条件不再总是正确的。智能限制器控制器根据实际应用状态判断是否触发限流，智能化程度更高
版本：微服务。粘液io/V1Alpha2Find:SmartLimitermetadata：名称： 审阅命名空间：defaultspec：集合：\uBase：#匹配所有服务、关键字\uBase或您定义的子集，例如V1描述符：-措施：#限流规则填充时间间隔：秒：60配额： “100”策略：“单一”条件：{{.\u base.cpu.sum}}>100’如果服务的所有负载都大于 100，则执行电流限制目标：端口：9080 4。项目架构 本节简要介绍slim的项目架构，以帮助您了解slim多模块场景中的代码仓库和部署形式。架构如下图所示𞓜
; “高内聚、低耦合”；设计思路包括三个模块：提供一定功能的独立模块，如延迟加载和智能限流，属于模块框架的基础：模块提供模块所需的基本功能，如日志输出和监控指标采集lime-启动：启动组件，该组件负责启动框架和指定模块 整个代码仓库分为1个+NSlime-靴筒和框架位于slime主仓库slime- Io/slim、lazy load等模块均位于独立仓库
部署形式也为1+N，也就是说，一个切片部署包含一个通用框架和用户想要的N个模块。优点是，无论使用多少“瘦”模块，部署都是部署，解决了微服务组件过度维护的痛点
5。展望 slice 开业至今的一年多，除了在模块层面增加新功能和改进现有功能外，它还经历了架构的重大调整和公制的重建。可以说，《切片》的发展已经走上了正轨，进入了一个新的阶段。未来的规划可分为现有模块的升级和新模块的引入，具体描述如下
灾难恢复能力 转型Global-Sidecar组件，提高了其底部覆盖能力，因此可以在某些灾难恢复场景中使用延迟加载 确定性 2022 Q2 多服务注册表支持延迟加载。目前，它主要适应kubernetes场景。计划通过支持serviceentry 确定性 2022 Q2 更灵活的静态配置 通过更高维度的抽象实现servicefence的自动配置，并支持更高级别的静态规则 确定性 2022 Q3 多协议延迟加载 延迟加载目前支持，并计划支持其他协议服务的延迟加载，如Dubbo和其他 Exploration 2022 H2 cross cluster lazy loading lazy loading当前支持相同的群集服务，并计划在多集群服务网格场景中支持跨集群服务延迟加载 探索 2022 H2 5.2智能限流规划 特征 特征描述 性质 计划发布时间
多服务注册支持 智能限流目前主要适应kubernetes场景。计划通过支持serviceentry Q2来适应多服务注册场景 确定性 2022 流出侧限流 智能限流当前支持流入侧限流，可以满足大多数场景。但从容量完整性来看，计划支持流出侧限流 确定性 2022 Q3 多协议智能流量限制 智能流量限制目前支持，并计划支持其他协议服务的智能流量限制，如Dubbo Exploration 2022 H2 cross cluster intelligent current limiting intelligent current limiting目前支持相同的群集服务，并计划在多群集服务网格场景中支持跨群集智能限流 Exploration 2022 H2 5.3新模块规划 模块名称（规划） 模块描述 性质 计划发布时间
Iperf 专门为istio创建的性能测试工具集，集成istio测试框架，添加自定义测试用例，并且可以直观地比较不同版本的性能变化 确定性 2022 H2 tracetio 服务网格的全链路自动运行和维护提高了障碍物清除效率，并给出类似于K9s的智能判断 确定性 2022 H2 i9s ，黑屏半命令行半图形化操作和维护工具 确定性 2022 H2𞓜 网易苏凡高级服务端开发工程师、istio社区成员、slim维护人员王晨宇，熟悉istio和kubernetes，主要负责 slim和网易苏凡轻舟服务网格的设计和研发，在云本地相关领域具有多年实践经验。