微服务引擎 MSE 企业版全新升级

作者：流士

随着企业应用大规模云上迁徙与应用微服务化步伐加快，微服务治理的重要性对企业不言而喻，但微服务治理本身的规范化与标准化尚未形成，导致很多企业在微服务治理方面正经历着痛苦的试错期，甚至难以满足线上环境的治理需求。此次MSE企业版升级，结合内部关联云产品治理的经验，经过长期打磨，指出阻碍微服务治理效率提升的主要问题，并提出对应的解决方案。本次分享介绍MSE企业版升级的内容，期望可以降低企业云化与微服务化的成本，提升治理效率。

当我们在谈论微服务治理时，我们在谈论什么？是否具备常用治理工具集就可以称为微服务治理平台？对此我们的回答是可以保障线上不出问题或者出问题时可以快速有效兜底的平台就是好的微服务治理平台，微服务治理的内涵和外延都在随微服务的变化而动态变化，但不变的是微服务对外的SLA与故障的快速响应能力，基于此，我们识别出当前阶段微服务治理在效率方面仍可改善的问题，并提供对应解决措施。

阻碍微服务治理效率提升的三大挑战

本次升级尝试解决以下三个问题：

1.限流降级监控能力不足导致的流量防护功能难以使用的问题

用户在使用流量防护功能时的效率会影响到治理的及时性和有效性，相比开源Sentinel，本次升级在强化流量防护能力的同时对配套的指标监控着重做了优化与调整，以期提供优质的微服务治理体验。

2.微服务洞察能力不足导致的故障根因识别困难的问题

分布式复杂度提升是微服务化的典型特点，本次升级推出微服务洞察能力，可动态采集任意点位日志，在故障识别及根因分析方面均做了增强，有效解决复杂分布式系统状态感知问题。

3.账号权限管理能力不足导致的子账号治理越权的问题

不同环境的人员或角色在不加以限制的情况下，往往会出现越权操作其他环境的应用情况，高危操作可能直接导致生产级故障，本次升级提出的按环境设置对应子账号管理权限的功能可有效解决这一问题。

MSE微服务治理版图：MSE 治理热点功能回顾解析

在介绍本次升级前，我们先回顾下MSE治理的版图。

在这里插入图片描述

按微服务生命周期，MSE治理范围覆盖开发、测试、发布及线上运维各个阶段，对治理常用的功能进行了产品化，如开发态的服务契约功能可自动生成服务契约，有效避免因文档过期造成的开发效率低下问题，测试态的服务测试功能则可快速验证服务的可用性与正确性；变更态的无损上下线功能可有效避免应用进行停止、部署、回滚、缩容、重置等操作时的流量损失，全链路灰度功能可通过灰度规则控制目标用户，在新功能验证后再逐步扩大灰度范围，确保充分验证后再全量开放，出现问题后可快速回滚，降低风险；运行态的流量控制可有效防止突增流量压垮系统，离群实例摘除功能可以屏蔽偶发异常的节点，等异常节点恢复后再继续提供服务，从而保证业务正常运行。

接入方面，Java语言支持Dubbo、SpringCloud框架，以Agent方式做到完全无侵入，开箱即用；多语言支持GoLang及Istio。

其中MSE治理专业版常用功能介绍如下：

无损上下线

通过开启无损上下线，可有效地防止发布阶段的调用异常。具体而言，对于任何一个线上应用来说，发布、扩容、缩容、重启等操作不可避免。在应用启动个阶段，无损上线能提供相应的保护能力，具体功能包含服务预热和延迟注册；无损下线的配置来保证应用正常下线，尽量保证客户端无感知，即从应用停止到重启恢复服务这个阶段不能影响正常的业务请求。

在这里插入图片描述

全链路灰度

在微服务场景中，当部署的Spring Cloud应用或Dubbo应用存在升级版本时，由于应用间的调用是随机的，会导致无法将具有一定特征的流量路由到应用的目标版本。全链路流量控制功能将应用的相关版本隔离成一个独立的运行环境（即泳道），通过设置泳道规则，将满足规则的请求流量路由到目标版本应用。

泳道的设置支持网关、RPC、RocketMQ、数据库等；具备流量一键动态切流能力，可通过监控查看切流效果；此外，也提供了端到端的稳定基线环境，方便用户快速、安全地验证新版本。

在这里插入图片描述

日常环境隔离

日常环境隔离是全链路灰度的最佳实践。主要解决微服务敏捷开发实践中联调测试阶段依赖其他环境应用的问题，如图中网关依赖A1应用，A应用依赖B2，需要做到流量可在不同环境内流转，以实现高效的敏捷开发。

MSE提供的日常隔离功能可以做到各环境逻辑隔离，只需要维护一套基线环境，大幅降低成本；另外在 IDEA中使用Cloud Toolkit的端云互联，可将本机启动的应用接入到开发环境，降低开发调测成本。

在这里插入图片描述

在完成了MSE微服务治理常用功能的回顾之后，我们再看这次升级的主要内容。

流量防护完善：Sentinel 企业版全新升级，提供全方位流量防护

对流量治理进行全面升级，包括服务端交互体验优化、流量防护核心功能完善及客户端性能提升等方面。本节围绕流量防护的核心功能展开。

核心功能

介绍微服务治理常用的流量防护核心功能。相比开源Sentinel，商业化能力建设方面更强调流量治理功能的完善性和易用性。

在这里插入图片描述

流量控制是我们在在双十一等大促时使用最多的防护功能，流量具有随机性、不可预测性。平稳运行的流量也随时可能出现流量洪峰（例如“双十一”零点的场景）。然而系统的容量总是有限的，如果突然而来的流量超过了系统的承受能力，可能会导致请求堆积且处理缓慢，CPU或Load过高，最终导致系统崩溃。通过MSE微服务治理提供的流量控制功能，可以对突发的流量进行限制，在尽可能处理请求的同时保障服务正常运行。其原理是实时监控应用或服务流量的QPS指标，当指标达到设定的阈值时立即拦截流量，避免应用被瞬时的流量高峰冲垮，从而保障应用高可用性。提供单机限流、分钟小时限流、关联限流等多种限流方式，支持滑动窗口、令牌桶、漏桶多种限流算法。

并发隔离适用场景是当强依赖的方法或接口不稳定的时候，可以通过配置并发线程数来限制不稳定的强依赖并发数，起到隔离异常的效果。在具体场景方面，强依赖可能是SQL或下游应用。其原理是通过控制接口或依赖的并发线程数，来保证系统的稳定性。通常适用于应用内部或下游依赖出现不稳定的场景，例如慢SQL、下游应用响应时间变长等。通过设定接口并发数，精准控制强依赖消耗的线程资源，避免过多的慢调用占满线程池导致服务不可用。

热点即经常被访问的数据。热点规则通过限制热点请求保护系统，如秒杀场景中需要针对一段时间内最频繁购买的商品ID进行限制，防止击穿缓存而导致大量请求到数据库的情形。另外当某一热点占用过高资源而影响别的业务接口时，也需进行热点限流。原理是通过分析统计参数，即资源调用过程中的调用次数较高的参数，并根据配置的热点规则对包含热点参数的资源调用进行限流，保护系统稳定性。可自动识别热点，支持设定单个热点流量请求大小，避免热点消耗过多系统资源。

除了上述原子防护能力外，MSE 也提供了场景化防护能力，如WEB防护是一种场景化的防护，面向提供Web服务的应用，针对访问请求中的一些参数项进行精细化的流量控制。对于使用了主流Web框架（Servlet容器、Spring Web、Spring Boot）的应用，MSE实现了API粒度的请求参数解析，通过配置Web防护规则，可以对请求中IP、Host、Header、URL Param等参数维度的资源调用进行流量控制，保护业务与系统的稳定性。在具体使用场景方面，比如我们识别出利用虚假信息恶意刷单的行为，则可以根据一段时间内频繁大量访问的来源IP进行限流。

防护规则使用

此次升级重在优化以监控为中心的辅助设置作为切入点提升微服务治理平台的易用性，其中在核心指标方面做了如下几点调整：

1.异常应用识别，应用列表透出总异常QPS和平均RT

微服务指标根据所在层次可分为操作系统指标、虚拟机(如JVM)指标、接口指标，微服务治理时首先会关注到接口指标进行针对性治理，在问题排查时再了解操作系统指标和虚拟机指标，故在列表页透出总QPS、总异常QPS和平均RT等参数。

2.异常接口识别，应用概览页透出Top接口

可根据通过QPS、平均RT等进行排序，识别出当前应用可能存在问题的接口，便于针对性治理。

3.异常资源识别，仅透出核心指标

如概览页中操作系统指标方面仅保留CPU和Load指标，JVM指标仅保留GC和线程数指标。

根据监控设置防护规则

在应用上线时，各项指标值均有其合理范围，当发现指标监控出现异常时可通过设置防护规则使监控水位恢复至合理值，保障系统稳定性。

以流控规则的设置为例，比如我们在接口详情中发现’/b’接口的请求量突增为到800+，而压测阶段摸高水位仅为200，为避免大量突增请求压垮节点，此时我们应设置限流规则。配置请求阈值为200，默认开启此流控规则，流控规则即刻生效，'/b’接口的请求量恢复至预期值。从而保障了当前接口的SLO。此案例的过程可拆解为如下三步：

一：通过监控指标发现接口QPS突增

在这里插入图片描述

二：新增流控防护规则

仅需设置流量防护阈值。

在这里插入图片描述

三：查看流控防护效果

从’/b’接口请求量我们看到配置流控规则后，接口请求量及时调整到预期值，有效保护了当前接口。

在这里插入图片描述

产品演进

通常，线上治理闭环按系统的稳定性保障角度在异常发生时的在线修复可用如下过程表示：

正常监控水位->发现异常->在线治理->纠偏控制->恢复正常水位。

在这里插入图片描述

在应用上线前，经过压测或历史经验数据可评估各项监控指标的合理水位范围，当超出水位的范围后，可认为系统可能存在问题，需设置合适的设置防护规则，同时观察监控指标是否恢复至正常水位，以判断设置的规则及规则的阈值是否合适并加以调整，直至监控指标恢复至正常水位。

如WEB场景防护迁移至接口详情，在出现异常时可针对性设置场景化防护规则，在治理规则设置后可通过监控指标与治理事件感知规则的有效度，从而进一步调整，最终完成系统的稳定性保障。

此部分介绍的闭环过程，就原子能力而言已经具备，如监控指标，防护规则及异常事件等，在原子能力的串联方面有待加强，也是产品的下一步规划。目前可通过上述过程手动完成治理闭环。

治理洞察升级：动态采集任意点位日志，轻松定位偶现异常等棘手问题

分布式系统的显著特点即为运维复杂度随应用数呈现爆炸式增长，一套完善的可感知系统内所有应用实时状态的可观测系统至关重要，MSE企业版推出的微服务洞察功能支持动态采集任意方法的信息，可快速感知系统行为，及时定位并处理问题。

在介绍微服务洞察前，我们先看下线上应用经常出现且比较难解的问题：

1.偶现异常，毫无规律可言，只能通过远程DEBUG或日志打印的方式，但线上环境往往不允许DEBUG，日志重新部署又非常耗时，而微服务洞察只需一条规则无需重启应用即可采集所需日志；

2.微服务治理本身的功能而言，应用的下线过程牵涉的实例范围较大，导致难以排查下线过程中的问题，而微服务洞察只需打开’上下线处理明细’开关，即可获取下线过程的事件详情，验证下线流程。

除上述适用场景外，我们看一个真实的用户案例，某用户在应用部署过程中发现流量有损，借助洞察能力，发现应用下线时并未触发后处理逻辑，导致消费者请求到已下线实例，定位问题后及时做了处理，有效防止问题扩散。

一句话总结就是：微服务洞察通过分析特定的日志信息可以排查问题或了解系统行为。

微服务洞察

在出现线上问题时，可以通过查看日志来排查和定位问题。在一般的实践中如需打印日志，往往要结合场景，在代码中加入对应的日志生成和输出的逻辑，然后重新部署应用，并在排查完成后去除相关逻辑并重新部署应用。该方式效率低下，对代码侵入性大且不支持在有强实效性的场景下排查问题。

使用MSE微服务洞察功能，只需在MSE治理中心控制台根据场景创建或开启对应的规则，即可得到包含指定信息的日志，无需编码也无需重启应用。

同时提供完善监控窗口，如事件统计，接口调用链路跟踪，详细日志查看等，极大程度提升运维效率。

微服务洞察的典型概览展示如下图。

在这里插入图片描述

无损上下线明细

无损上下线的核心能力包括上线阶段进行延迟注册和小流量预热及下线阶段的流量无损。

通过开启微服务洞察提供的’上下线处理明细’开关，即可观测到上线阶段明细事件：包括延迟注册实际生效详情及时间点、小流量预热开始和结束详情及对应时间点，方便运维同学检查应用行为是否符合预期；

和下线阶段的明细事件：包括主动通知情况下服务提供者何时发出下线消息及服务消费者收到消息后的处理详情，被动通知情况下服务消费者感知到服务提供者下线后刷新消费列表的处理详情。

其中典型的无损下线过程中事件明细及消费者列表如下图。

在这里插入图片描述

详细使用过程可参考文档。

一分钟使用

微服务洞察使用方面，可通过开关一键采集应用访问日志，按需采集任意方法的日志。

在日志存储方面既有本地存储的文件，也可基于SLS。

展示方面可以链路方式展示，洞察基于链路追踪和ARMS，在页面一键开通即可，无需额外付费。

在这里插入图片描述

下一期预计对全链路灰度的支持上可做到

支持查看流量打标的命中规则、打标结果及流量标签的透传结果。支持排查流量的标签及是否有流量逃逸。
支持查看流量路由的命中规则、筛选过程。支持查看流量经过的节点。
可根据灰度规则筛选流量，查看请求数、成功率、RT，观察灰度效果。

产品化提升：管理不同环境的应用，控制不同子账号权限

微服务团队往往需要维护多套环境，如生产、开发、测试环境等，在微服务的开发、测试及发布阶段不同的环境由对应的角色同学负责，完成分工协作。

但自构建的环境难以管理不同角色人员的应用操作权限，往往会出现越权操作其他环境的应用情况，存在高危操作的风险，比如开发同学直接修改了线上环境导致生产级故障。

基于此，我们推出治理环境的方案，在概念上MSE的命名空间(环境)与每个微服务团队所使用的生产、开发、测试环境是一致的。但不同角色可按需分配不同环境的治理权限，可有效提升治理效率，隔离越权操作风险。

MSE 命名空间

'命名空间’是微服务治理提供的逻辑隔离概念，用于区分用户自定义的不同环境，如生产、开发等，不同’命名空间’下的同名应用视为不同应用。在同一个地域内不允许创建两个同名的微服务空间。

'命名空间’隔离的对象是微服务治理规则，微服务治理规则仅在当前’命名空间’内生效，但不同’命名空间’的应用仍可以相互调用。对于命名空间内的资源对象可用标签加以区分，如全链路灰度的流量标。

'命名空间’的作用可以归纳为以下两点：

1.为应用提供逻辑隔离的环境，限制应用所属范围，方便应用管理

2.可按需分配不同子账号的环境管理权限，比如某些账号具备几个环境的读写权限，而某些账号仅有某个环境的读权限

注：与上文提到的‘日常环境隔离’的区别是‘日常环境隔离’仅对流量进行隔离。

用户权限管理

为什么需要权限管理

微服务治理中用户权限管理能够控制不同角色对不同环境的使用权限，如开发同学仅能使用开发环境，测试同学仅能使用测试环境。同时确保用户只拥有完成治理工作所需的权限，只能查看授权命名空间下的应用及授权的治理规则，可有效避免敏感数据泄漏。

如何使用权限管理

新旧权限控制模型的变动对比如下：

在这里插入图片描述

如果没有设置新的命名空间，原有的权限策略仍然有效，无需额外操作。

若设置了新的命名空间在授权方面有如下变更：

1.Action保持不变，仍然为mse:$popAction

2.Resource需要修改为：acs:mse:::namespace/ $n s / a ppl i c a t i o n /$ appName，如果是default命名空间，则acs:mse:::namespace/ $n s / a ppl i c a t i o n /$ appName和acs:mse:::application/$appName都支持。