作者：流士
本次 MSE 治理中心在限流降级、数据库治理及同 AZ 优先方面进行了重磅升级，对微服务治理的弹性、依赖中间件的稳定性及流量调度的性能进行全面增强，致力于打造云原生时代的微服务治理平台。
在介绍升级能力之前，先简要回顾 MSE 产品的核心能力，分为开发态、测试态及运行态，其中在服务治理中较为常用的功能包括无损上下线、全链路灰度以及日常环境隔离三大功能。
支持小流量服务预热，避免新启动应用被流量击垮；而预热模型支持动态调节，可满足复杂场景需求；并且，预热过程支持关联 Kubernetes 检查。
可进行泳道设置，支持网关、RPC、RocketMQ 等；具备流量一键动态切流能力，可通过监控查看切流效果；此外，提供了端到端的稳定基线环境，方便用户快速、安全地验证新版本。
流量在 feature 环境内流转，实现高效的敏捷开发；各环境逻辑隔离，只需要维护一套基线环境，大幅降低成本；在 IDEA 中使用 Cloud Toolkit 的端云互联，可将本机启动的应用接入到开发环境，降低开发调测成本。
下面介绍流量治理、数据库治理及同 AZ 优先解决的问题和具体方案。
对应流量治理模型在流量防护方面形成可拓展闭环，围绕系统线上环境可能出现的各种问题，进行有效治理。模型始于‘故障识别’，发现不同层次的问题，如接口层的状态码与异常类型、操作系统层的指标异常；在识别出问题后，发出异常告警，方便用户进行针对性的流量治理，如进行自适应限流防护或场景化限流防护；防护规则设置后，系统便按照预设的阈值与防护手段保护系统，而系统防护的效果可通过监控查看，另一方面，也可通过监控反向审视流量防护规则设置的合理性，及时调整。
对于首次接入无历史数据参考的情况，可通过系统压测的方式，结合业务场景设置压测参数，为线上可能出现的问题配置流量治理规则，做好防护策略。
首先看流量控制，其原理是监控应用或服务流量的 QPS 指标，当指标达到设定的阈值时立即拦截流量，避免应用被瞬时的流量高峰冲垮，从而保障应用高可用性。本产品提供了提供单机限流、集群流控、分钟小时限流、关联限流等多种限流方式，支持滑动窗口、令牌桶、漏斗桶多种限流算法。
对于并发控制，当强依赖的方法或接口出现不稳定的时候，可以通过配置并发线程数来限制不稳定的强依赖并发数，起到隔离异常的效果。若运行该请求的响应时间变长，会导致线程的并发数变大。当并发数超过阈值以后，AHAS 将拒绝多余的请求，直到堆积的任务完成，并发线程数变少。达到将异常隔离，减小不稳定性的效果。
在系统保护方面，支持自适应流控或手动设置系统规则，自适应流控是根据系统的 CPU 使用率自动动态地调整应用程序的入口流量；系统规则是从整体维度手动设置规则，对应用入口流量进行控制。目的都是为了让系统的入口流量和系统的负载达到一个平衡，保证系统在最大吞吐量状态下稳定运行。
熔断防护可以监控应用内部或者下游依赖的响应时间或异常比例，当达到指定的阈值时立即降低下游依赖的优先级。在指定的时间内，系统不会调用该不稳定的资源，避免应用受到影响，从而保障应用高可用性。当指定时间过后，再重新恢复对该资源的调用。
主动降级防护可以指定对某些接口进行降级，被降级的接口会触发自定义的降级行为（如返回指定内容）而不会执行原有的逻辑。
热点防护通过分析资源调用过程中的调用次数较高的参数，并根据配置的热点规则对包含热点参数的资源调用进行限流，保护系统稳定性。
最后，当系统遇到一些非致命性的错误（如偶现的超时等）时，可以通过自动重试的方式来避免系统最终失败。
其中集群流量防护用于解决单机流控存在流量不均匀、机器数频繁变动以及均摊阈值太小的情况导致限流效果不佳的问题，集群流控可以精确地控制某个服务接口在整个集群的实时调用总量。较适用于以下场景：
1. 服务调用流量不均，需要缓解的情况
流量到每台服务实例不均衡导致单机限流不够精确（总量上“提前限流”），从而无法精确控制总量
2. 集群小流量精确场景
对集群总流量限制比较小的情况，单机限流将失效（比如某个接口每秒总量不超过 10QPS，但机器数为 50 台，即便单机阈值设为 1，仍会超出阈值）
3. 业务集群流控
对于有业务含义的分钟小时级流量控制，可保护下游系统不被（如网关层限制每个用户每分钟调用某个 API 不能超过多少次）压垮。
集群流控具有场景丰富、使用成本低以及全自动管控等优势：
场景丰富：全面覆盖从网关入口流量精确防护、Web/RPC 服务调用精确流控到分钟小时级业务维度流量控制的场景
低使用成本：无需特殊接入方式，开箱即用
全自动管控：自动化管控与分配 server 资源，自动化运维能力保障可用性，无需用户关注资源准备与分配细节，只需关注业务
网关流量防护则用于精确控制某个或某组 API 的流量，起到提前保护的作用，使多余流量不会打到后端系统。如果按照单机维度配置，一方面网关机器数变化难以感知，另一方面网关流量不均可能导致限流效果不佳。
网关防护具备四点核心能力：
API/Host 维度的实时监控与流量控制
动态规则配置，实时生效
集群流量控制，精确控制 API 调用总量
请求参数/header 维度的流控、熔断
MSE 升级后的流量治理可应用于微服务的全链路，比如在流量入口层，可通过网关方式接入、在微服务层面不仅可保护微服务自身，也可以保护微服务依赖的中间件、如缓存、数据库等三方依赖、若您通过 ACK 或者 Agent 方式接入，则无需改造一行代码即可轻松接入，若您有高阶流量治理的需求，如自定义埋点，可通过 SDK 方式接入。
某系统对外提供某查询接口，SQL 语句涉及多表 join，某些情况下会触发慢查询，耗时长达 30s，最终导致 DB 连接池/Tomcat 线程池满，应用整体不可用。
应用刚启动，由于数据库 Druid 连接池还在初始化中，但是此时已经大量请求进入，迅速导致 Dubbo 的线程池满，许多现场卡在初始化数据库连接的过程中，导致业务请求大量报错。
全链路灰度场景中，由于新的应用版本改了数据库表的内容，灰度流量导致线上数据库的数据错乱，业务同学连夜手动订正线上数据。
在项目初期没有对 SQL 的性能做好考量，随着业务的发展，用户量级的增加，线上遗留老接口的 SQL 逐渐成为性能瓶颈，因此需要有有效的 SQL 洞察能力帮助我们发现遗留的 SQL，并及时进行性能优化。
SQL 语句处理时间比较长导致线上业务接口出现大量的慢调用，需要快速定位有问题的慢 SQL，并且通过一定的治理手段进行隔离，将业务快速恢复。因此在微服务访问数据层时，实时的 SQL 洞察能力可以帮助我们快速定位慢的 SQL 调用。
其实针对大多数的后端应用来讲，系统的瓶颈主要受限于数据库，当然复杂度的业务肯定也离不开数据库的操作。因此数据库问题，也是优先级最高的工作，数据库治的理也是微服务治理中必不可少的一环。
慢 SQL 是比较致命的影响系统稳定性的因素之一，系统中出现慢 SQL 可能会导致 CPU、负载异常和系统资源耗尽等情况。严重的慢 SQL 发生后可能会拖垮整个数据库，对线上业务产生阻断性的风险。线上生产环境出现慢 SQL 可能原因如下：
网络速度慢、内存不足、I/O 吞吐量小、磁盘空间被占满等硬件原因。
没有索引或者索引失效。
系统数据过多。
在项目初期没有对 SQL 的性能做好考量。
连接池治理
连接池治理是数据库治理中非常重要的一个环节，通过一些链接池的实时指标，我们可以有效地提前识别系统中存在的风险，以下是一些常见的连接池治理的场景。
在应用发布或者弹性扩容的场景下，如果刚启动实例中的连接并有没完成建立，但此时实例已经启动完成，Readiness 检查已经通过，意味着此时会有大量的业务流量进入新启动的 pod。大量的请求阻塞在连接池获取连接的动作上，导致服务的线程池满，大量业务请求失败。如果我们的应用具备提前建连的能力，那么就可以在流量到达前，将连接请求数保证在 minIdle 之上，并且配合小流量预热的能力，那么就可以解决以上这个让人头疼的冷启动问题了。
有时候连接池中会存在一些有问题的连接，可能是底层的网络出现了抖动，也有可能是执行的业务出现了慢、死锁等问题。如果我们可以从连接池的视角出发，及时地发现异常的连接，并且进行及时地剔除与回收，那么就可以保证连接池整体的稳定性，不至于被个别有问题的业务处理或者网络抖动给拖垮。
理论上并不是全部数据库表都可以随便访问的，在某些时候，有些重要的表可能对于一些不太重要的服务来说，我们希望它是一个禁写、只读的状态，或者当数据库出现抖动、线程池满的情况下，我们希望减少一些耗时的读库 SQL 执行，又或者有一些敏感数据的表只允许某个应用去进行读写访问。那么我们就可以通过动态的访问控制能力，实时下发访问控制规则，来做到对于个别方法、应用的 SQL 面向数据库实例、表的禁读禁写等黑白名单的访问控制。
微服务体系架构中，服务之间的依赖关系错综复杂，有时某个功能发版依赖多个服务同时升级上线。我们希望可以对这些服务的新版本同时进行小流量灰度验证，这就是微服务架构中特有的全链路灰度场景，通过构建从网关到整个后端服务的环境隔离来对多个不同版本的服务进行灰度验证。MSE 通过影子表的方式，用户可以在不需要修改任何业务代码的情况下，实现数据库层面全链路灰度。
通过 MSE 提供的 SQL 洞察能力，结合我们对业务的理解，我们可以快速定位划分接口请求为弱请求。将对主库性能以及稳定性影响大的读操作，分流至 RDS 只读库，可以有效降低主库的读写压力，进一步提升微服务应用的稳定性。
以上这些是 MSE 即将推出的一个数据库治理能力的预告，我们从应用的视角出发整理抽象了我们在访问、使用数据库时场景的一些稳定性治理、性能优化、提效等方面的实战经验，对于每一个后端应用来说，数据库无疑是重中之重，我们希望通过我们的数据库治理能力，可以帮助到大家更好地使用数据库服务。
同城的特点是 RT 一般处在一个比较底的延迟（< 3ms 以内），所以在默认情况下，我们可以基于同城的不同机房搭建起来一个大的局域网，然后把我们应用跨机房分布在多个机房中，以此来应对单机房出现故障时的流量受损风险。相比异地多活，这种基础设施的建设成本较小，架构变动也比较小。不过在微服务体系之下，应用之间的链路错综复杂，随着链路深度越来越深，治理的复杂度也会随之增加，如下图所示的场景就是前端流量很有可能因为在不同的机房相互调用而导致 RT 突增，最终导致流量损失。
当应用部署在多个机房的时候，应用之间互相调用会出现跨机房的情况
机房 1 的 A 应用调用机房 2 的 B 应用，跨机房调用网络延时增加，导致 HTTP 响应时间增加。
开启同机房优先后，consumer 会优先调用同机房的 provider 服务：
根据路由规则，自动识别同可用区，并优先选择同可用区减少调用时延，提升性能，并可实现容灾场景下的流量切换，保障可用性。
MSE 治理中心在限流降级、数据库治理及同 AZ 优先方面的能力升级，有助于企业更便捷地做好系统弹性、及时感知系统 SQL 异常状态，做好针对性治理与防护，同 AZ 优先可提升系统整体性能，构建强健而稳定的运行环境。本次升级是治理中心升级的第一阶段，后续会不断推出治理手段，为您的系统保驾护航。
MSE 注册配置中心专业版首购享 9 折优惠，MSE 云原生网关预付费全规格享 9 折优惠。点击此处，即享优惠！
