译者：张斌斌：Nacos&SentinelCommitter
前段时间ChatGPT AI 科学知识却是Goolgle正式发布新一代演算法的这时候。彼时我考量呢要改行去搞 AI，要不然就有被出局的信用风险，随著修完麻省理工学院的 AI 讲座，忽然就忧愁了。我辨认出那个金融行业很少天才少年去重构演算法，绝大部分人而已体能训练和修正模块利用到相同的情景。但前段时间ChatGPT火了，又引发了我的恐惧和疑惑，旋即试著考验呵呵 AI 潜能，问了两个难题。
做为Nacos的Committer，想看呵呵 AI 究竟若想认知控制技术，因此问了两个暗含情感美感的难题，结论让人愤慨。我传道Nacos也就从开放源码功能定位、竞争优势结构化的去撷取，要晓得形式化是圣默内技师的核心理念观念明确要求，AI 能达至圣默内的观念水准了？多试著数次，结论每天都不那样，或许越问越简化，最终竟然能总结提问，太妙啦～
能够形式化按照功能定位、竞争优势提问
能够做提炼精简
能够用总体来说-归纳
为了发挥程序员和测试的观念，我把电脑切成英文，看看他的提问是否专业，看到数次结论后，我笑了。看来也不是万能的嘛，但想了呵呵，应该是Nacos海外影响力不够，因此结论不能很好命中。
总的来说，ChatGPT 超出了预期，激发了我的热情。晚上睡觉的这时候都在考量怎么问 ChatGPT，想看看他是怎么提问的，要晓得上一次有这么高热情却是谈恋爱的这时候，哈哈～
继续提问。。。
ChatGPT能自我认知吗？但这次提问，竟然崩了。。
开闭了。。我疑惑的是，AI 也会开闭？AI 能写开闭代码吗？看来 Java 程序员那个工作却是能继续干下去的，哈哈。
做为一名从事微服务架构和稳定性的程序员，我立马就想了ChatGPT开闭用的是什么控制技术呢？
基于 IP 开闭？
我想基于 IP 开闭是不能搞定的，因为 IP 是变化的，一定是跟采用了服务开闭，背后需要采用类似 Sentinel 的服务级别的开闭控制技术。
那开闭是在出口处做的，却是在后端应用，或者演算法层面做的呢？
猜测应该是在出口处或者前端业务做的，因为这样能快速的构建出口处高可用防线，类似Higress+Sentinel的开放源码组合。可以从出口处快速进行服务级别的开闭。
那为什么要开闭呢？是系统却是单体应用撑不住了呢？却是不具备弹性水准扩容潜能呢？呢采用微服务+容器架构能够大幅提升并发潜能，快速弹性伸缩呢？
如果ChatGPT的后端已经云原生化，那么猜测是类似Higress + Sentinel + Dubbo + Nacos + K8s的控制技术栈，这样可以快速构建高并发、高可用、自动弹性的后端体系。（由于目前未从官方公开文档找到 ChatGPT的后端架构，因此这里而已假设情况）
做为云计算从业者，就在思考了，ChatGPT的现象级爆火，让很多公司都羡慕不已，在那个信息大爆炸的时代，每个公司都有着在短时间迅速爆火的可能，在机遇到来时，能不能抗住流量洪峰，保证服务的质量，抓住这次机遇呢？怎样快速构建高并发、高可用的微服务架构呢？我初步构思了两个架构，仅供参考讨论：
那么怎样结合云原生网关与服务治理来保障业务的稳定性与连续性呢？下面来为大家进行揭秘。
全链路服务治理，全方位保障业务稳定性
在分布式系统架构中，每个请求都会经过很多层处理，从出口处网关再到 Web Server 再到服务之间的调用，再到服务访问缓存或 DB 等存储。在高可用防护体系中，我们通常遵循流量漏斗原则进行高可用流量防护。在流量链路的每一层，我们都需要进行针对性的流量防护与容错手段，来保障服务的稳定性；同时，我们要尽可能地将流量防护进行前置，比如将一部分请求的流量控制前置到网关层，这样可以避免多余的流量打到后端，对后端造成压力同时也造成资源的浪费。
网关出口处流控
网关做高可用出口处防护为什么重要？一言以蔽之，网关具备将大促的各种不确定性因素转化为确定性因素的潜能，并且这种潜能是不可替代的。分别从三个方面来看：
第一点是应对流量峰值的不确定性，必须通过流控规则将不确定的流量变为确定。实现流量防护有个前提，承载这突发流量的服务仍能保持正常的 CPU 负载。业务服务模块即使实现了应用层的 QPS 流控，在瞬时高并发情景下，仍可能因为网络层大量的新建连接导致 CPU 猛涨，还没有到流控这道“保险杠”就崩溃了。业务模块应该专注在应用层业务逻辑上，若要通过扩容去应对其不擅长的网络层开销，所需的资源成本是相当高的。而网关做为业务流量入口的地位，决定了其必须擅长应对高并发的网络流量，并且这块性能也是衡量网关潜能的两个重要指标，应对高并发的性能越强，所需的资源成本就越低，将大促流量从不确定变为确定的潜能就越强。我们推荐在流量出口处进行前置流量防护，提前粗粒度地限制一部分超容流量，避免多余的流量打到后端，对后端造成压力同时也造成资源的浪费。
第二点是应对用户行为的不确定性，需要根据相同的大促情景，模拟用户行为进行多轮压测演练，提前辨认出系统的瓶颈和优化点。网关既是用户访问的流量出口处，也是后端业务应答的最终出口。这决定了网关是模拟用户行为进行流量压测的必经一站，也决定了是观测压测指标评估用户体验的必须环节。在网关上边压测，边观察，边修正开闭配置，对大促高可用体系的建设，可以起到事半功倍的效果。
第三点是应对安全攻击的不确定性。在业务峰值时，大量异常的流量，甚至是普通用户的重试流量，都很可能导致整体流量超出业务承载范围，从而影响正常用户的访问。基于网关的流量安全防护潜能，例如 WAF 等功能，通过识别出异常流量提前拦截，以及将异常 IP、cookie 自动加入黑名单等手段，既可以使这部分流量排除在流控阈值之外，也可以保障后端业务逻辑安全。这也从出口处层面保障业务稳定性的重要一环。
Higress云原生网关内置了 Sentinel 高可用模块，历经多年双十一大促洪峰流量考验，提供了丰富的高可用防护潜能，包括流控、并发控制、熔断，可以从出口处层面保障服务稳定性；此外，Higress商业版MSE 还具备流量预热潜能，通过小流量预热方法，可以有效解决大促情景下，资源初始化慢所导致的大量请求响应慢、请求阻塞难题，避免刚扩容的节点无法提供正常服务，影响用户体验。
那么，仅仅依靠出口处流量防护来保障整体业务稳定性是否是足够的？随著我们业务规模、量级的不断增长，业务架构趋于复杂，微服务间的调用拓扑关系呈复杂网状结构。影响稳定性的因素有非常多，除了流量超过承载潜能导致不可用的情景之外，服务之间调用的稳定性难题也是不可忽视的一点。比如ChatGPT可能依赖两个第三方服务，假设某个搜索服务出现异常，慢调用、超时的请求非常多，而调用端又没有有效地进行预防与处理，则调用端的线程池会被占满，影响服务自身正常运转。在分布式系统中，调用关系是网状的、错综复杂的，某个服务出现故障可能会导致级联反应，导致整个链路不可用，整体 RT 升高，并发升高，此时仅在网关层面做流控是无法保障业务稳定性的。我们需要在应用层结合流控、慢调用熔断、并发隔离等手段，配合网关层的流控来达至整体业务稳定的目标。
应用视角的稳定性治理手段
通过细粒度流控与热点防护，避免业务超过承载潜能导致不可用
面对突发的流量，流控潜能可以将超出系统服务潜能以外的请求拒绝掉。在应用层，建议结合容量评估，通过压测等手段评估流量阈值，针对核心理念API、接口、方法进行细粒度的流控配置，起到“安全气囊”的作用。注意并不是只有大流量情景才需要流控，任何服务与接口都有其容量上限，对于核心理念接口，无论流量大小，都需要配置流控来起到保护作用。
同时，针对热点流量的防护也是保障服务稳定性的重要一环。比如请求中的某些 UID、某些 IP 具有热点访问性质，业务方事先无法准确预知热点属性；这些突发的热点流量会击穿缓存，将 DB 打挂，影响了正常流量的业务处理，造成整体不可用。这种情景下，通过借助 Sentinel 的热点模块流控潜能，自动识别模块中的TopN访问热度的模块值，并对这些模块分别进行流控，避免单个热点访问过载导致系统不可用。
通过并发隔离与熔断，保障调用端不被不稳定服务拖垮
想象这样两个情景，某系统对外提供某查询接口，SQL 语句涉及多表 join，某些情况下会触发慢查询，耗时长达30s，最终导致 DB 连接池/Tomcat 线程池满，应用整体不可用。这种情景下，借助 Sentinel 的并发隔离潜能，可以给重要服务调用、SQL 访问配置并发线程数限制，相当于一道“软保险”，防止不稳定调用过多挤占正常连接池、线程池资源造成服务被拖垮。
业务高峰期，某些下游的服务提供者遇到性能瓶颈，甚至影响业务。我们可以对部分非关键服务消费者（弱依赖服务）配置熔断规则，当一段时间内的慢调用比例或错误比例达至一定条件时自动触发熔断，后续一段时间服务调用直接返回Mock的结论，这样既可以保障调用端不被不稳定服务拖垮，又可以给不稳定下游服务一些“喘息”的时间，同时可以保障整个业务链路的正常运转。
通过离群实例摘除解决实例单点异常难题
在业务峰值时刻，应用的某几台机器由于磁盘满，或者是宿主机资源争抢导致load很高，导致 consumer 出现调用超时，从而影响系统的整体稳定性。我们可以通过配置离群实例摘除规则，自动摘除异常的实例，避免单点故障引发的整体不可用难题。
展望
如今是 AI 控制技术突破爆发的时代，我们再脑洞大开一些，是否可以把 AI 控制技术结合到流量防护体系，基于AI+大数据的潜能与策略来做到智能化保障服务稳定性呢？其实，Sentinel 一直在进行自适应、智能化流量治理的探索，结合控制论、排队论、强化学习等理论与策略来达至自动化保障业务稳定性的目标。目前Sentinel提供的基于 load + BBR 的自适应过载保护策略已经可以保障一部分情景下稳定性兜底，我们也在持续探索与重构，针对更多的稳定性情景进行落地。
做为控制技术小伙伴，大家是怎么看待ChatGPT，怎样将ChatGPT运营在自己的业务和控制技术领域呢？欢迎交流，留言点赞最高的 TOP10，我们将送出Nacos + Sentinel 的社区礼物。
十亿人都在用的健康码，运维体系是怎么设计的？
vivo 低代码平台【后羿】的探索与实践
分布式系统关键路径延迟分析实践
美团外卖搜索基于Elasticsearch的优化实践
本文由高可用架构首
