作者：升学e网通研发部基建团队

杭州铭师堂，是一个致力于为人的全面发展而服务的在线教育品牌。杭州铭师堂秉持“用互联网改变教育，让中国人都有好书读”的使命，致力于用“互联网+教育”的科技手段让更多的孩子都能享有优质的教育，促进他们的全面成长。

在 2022 年之前，杭州铭师堂全栈系统主要搭建在 IDC 之上，仅在寒暑假高峰期时会在云上部署一定资源来应对预期外的流量，过程中初步享受到云计算的红利，了解到云的魅力，对云有了一个比较浅显的认知。具体架构为：基础设施层利用自建 K8s 进行应用部署管理，中间件层包含：自建注册配置中心、自建数据库（Redis、MySQL、MongoDB 等）、自建消息队列（Kafka、RabbitMQ）、自建大数据 Hadoop 集群，应用层为 Spring Cloud 构建的 Java 服务，网关层为基于 Zuul 1.0 开发 Gateway 服务，入口层通过 Nginx 进行统一管理，配套工具有自建 ELK、Pinpoint、Zabbix。

随着业务的高速发展，杭州铭师堂的业务流量在平峰期和高峰期之间的 Gap 从几倍增长到几十倍，原本的这套技术架构逐渐暴露出诸多问题：

1. 稳定性问题多：随着业务发展，高峰期流量逐年增长，以自建形式搭建的集群，会面临各种各样前所未有的挑战，导致问题频发、SLA 无法有效保障，业务发展带来系统压力和稳定性保障复杂度成为焦点矛盾。
2. 资源弹性能力不足：当实际流量超过预留值时，无法实现快速扩容和响应，复杂的招采流程导致时长以小时甚至日级别。
3. 成本管控难度高：IDC 机器不具备弹性能力，必然需要日常做好资源预留，导致资源空闲。
4. 运维成本和复杂高：采用大量自建服务，需要配套足够且专业的人员进行维护，一旦遇到复杂问题，排查起来非常棘手，响应速度无法跟上业务诉求。

基于以上的痛点，杭州铭师堂成立上云项目组，经过深入方案调研，最终选择阿里云，在上云项目组和阿里云专家团队的共同合作和努力下，在 2022 年杭州铭师堂成功完成了业务的全量上云，为下一步云原生化打好基础。

随着业务全量上云后，如何利用云更好的保障系统稳定性成为了杭州铭师堂的重点课题。不同于业界大厂 618、双十一的护航，杭州铭师堂的暑期高峰期长达 86 天，日活百万+，峰值 QPS 几万+，系统压力较平时有几十上百倍的差异，要保障好全栈系统不出问题，是一项非常有挑战性的任务。考虑到这一课题范围较广，涵盖微服务领域、大数据领域、运维领域、可观测性领域、安全领域等等，这里重点围绕微服务领域进行展开讲解，实践的整体思路先从基础设施，再到微服务应用，最后到统一入口层，逐步进行云原生化，建设一套规范化、先进化、灵活化的稳定性系统，助力业务快速发展，做好技术的充分赋能。

面临的问题

针对性的解法

杭州铭师堂联合阿里云一起共建，基于 MSE Sync 实现了 MST-Sync，让注册中心实现了丝滑平迁：

取得的成果

• namespace：环境，目前有四套，开发、测试、预发、生产
• group：组，定义为业务线
• dataId：配置标识，分为公共配置和应用私有配置：

• 全栈公共配置：要求 group 为 public，dataId 为 public-{配置文件名}.{扩展名}。
• 业务域公共配置：要求 group 为业务线，dataId 为 public-{配置文件名}.{扩展名}。
• 业务配置：group 为业务线，dataId 为{应用名称}.{扩展名}，如果有扩展配置，可定义为{应用名称}-{自定义名称}.{扩展名}。

• 业务敏感配置：group 为业务线，dataId 为{敏感配置文件名}.{扩展名}，提供给后续结合 KMS 实现敏感配置的加密处理。

高可用三大利器：限流、熔断、降级

面临的问题

• 防护能力不足，无法以 QPS 维度限制接口访问。

• 线程池隔离占用资源高：在暑期高峰期，复杂的核心应用因为使用线程池隔离策略，光内存占用就多了几个 GB，实在是过于繁重。

• 规则无法实时性等等。线上监控发现答题接口被刷，无法利用 Hystrix 立即进行防护手段的干预，需要调整代码才能处理，非常被动。

针对性的解法

• 多维的防护能力：基于 QPS 的限流、基于并发数的隔离、基于异常数或者慢调用的熔断机制等等。

• 轻量的资源占用：借助并发数的隔离机制，远远不需要像线程池方式这么重量级，内存资源占用节省至少 10 倍以上。

• 规则实时生效：针对突发情况能够快速进行响应，在关键时候能解燃眉之急。

• 在网关层进行粗粒度的限流控制，来防止当前超出系统容量下的流量，规则命中后日志接入 SLS，配套监控告警，及时感知后，进行干预，针对合理请求进行系统容量扩容，预留足够的响应时间。

• 在应用层进行细粒度的限流、熔断、降级组合控制，让强依赖在可控范围内进行调用，针对弱依赖可降级降级，不可降级进行熔断，避免被下游慢调用拖垮。配合应用各项指标监控告警，充分利用 MSE 流量治理的实时性能力，及时调整，保障应用高可用。

取得的成果

安全发布第一法宝：无损上下线

面临的问题

• 非优雅下线：

• 服务无法及时下线，导致上游应用还在继续调用已下线的副本实例，从而请求处理失败。

• 非优雅上线：

• 应用发布后，K8s 就绪检查以健康检查接口来判定，而健康检查接口里包含大量检测依赖服务的检查，耗时过久，造成健康检查不通过。
• 一些应用在初始化时存在复杂逻辑，导致时间比较长，此时流量过大，会造成大量请求超时、阻塞等问题。

针对性的解法

阶段一：采用自研方式

• 非优雅下线：

• 通过对 Nacos 源码的研究，了解到 Nacos 服务端存在 1 分钟对服务实例元数据记忆逻辑，借助 K8S preStop 机制，Sleep 60s，来达到应用及时准确的下线。

• 非优雅上线：

• 统一规范应用健康检查机制，在原有/health 接口里将逻辑变薄，去除原有复杂逻辑，让健康检查足够轻量。
• 针对初始化逻辑复杂的应用，增加延迟注册的时间，让其在初始化完成后对外提供服务。

阶段二：采用云产品能力

取得的成果

背后的原理

无损下线

无损上线

MSE Agent 结合延迟注册能力和小流量预热能力，有效保障在服务初始化完成后，才对外进行服务的提供。在外部流量进入实例时，采用线性增长的方式控制进入的请求数，避免流量过高导致超时、阻塞等问题。

安全发布第二法宝：全链路灰度

面临的问题

针对性的解法

• 早期，通过开源 Nepxion Discovery 框架自研了一套解决方案，在业务流量不高，场景不复杂的情况下，这套解决方案还是可以满足组织要求，慢慢随着使用深度的增加，SDK 升级不够灵活、性能达不到要求、改造成本越来越高的问题逐步暴露，此时，就需要一套更加轻量级的解决方案。

• MSE 全链路灰度产品提供以 Agent 方式进行动态接入，接入成本低；默认支持当下主流框架，不需要使用方进行开发，接入即可用，使用难度低；能力设计开放性强，满足个性化流量染色诉求，灵活性高。

接下来，针对目前现有的全链路灰度能力，做下详细讲解，大致分为几个核心模块：

• MST 发布系统：提供灵活的应用 MAM 模型，可以动态接入 MSE Agent。

• MST 流量治理平台：自研灰度规则的管理平台，提供符合 MST 特色的灰度场景使用规则。

• MST 统一入口网关：Go 语言开发的自研 wasm 插件，进行灰度规则判定，实现核心染色逻辑。

• MST 静态渲染服务：自研前端静态资源的控制服务，实现前端页面的灰度能力。

• 阿里云 MSE Agent：实现 Java 应用间染色标记透传。

取得的成果

• 业务需求上线，先通过内部用户进行功能充分验证。
  

• 验证通过后，则按照比例将新功能覆盖到外部用户中，1% -> 5% -> 10%。
  

• 选取一定比例外部用户使用新功能，观察符合预期后，则进行灰度转全量，将新版本代码推到 baseline 中，提供给所有用户使用。

面临的问题

讲完了基础设施层和微服务应用层，视角从下到上，聚焦到统一入口层。一方面，网关作为全栈业务的统一入口，它的重要性不言而喻。另一方面，在高峰期网关需要承载峰值数万+QPS，单日近数十亿次调用的访问压力。二者结合，要保障好网关的稳定性，是一件非常有难度的事情。

从 IDC 到上云，网关架构从 1.0 演变成 2.0：

• 2018、2019 年第一代网关架构，上层采用 Nginx 作为流量网关，下层采用 Spring Cloud Zuul 1.0 搭建的业务网关。规则管理和配置复杂度高，缺乏热加载能力，规则修改后生效时间长。

• 2022 年第二代网关架构，流量网关从 Nginx 替换为 APISIX，下层依旧是 Spring Cloud Zuul 1.0 搭建的业务网关。APISIX 较 Nginx，具备更好的灵活性和可扩展性，但是因为引入了 etcd 集群，增加运维复杂度。另外，针对自定义插件的更新成本较高，缺乏版本化管理和秒级升级与回滚能力。

针对性的解法

2023 年第三代网关架构，利用 MSE 云原生网关合并流量网关和业务网关，整体链路从两层变一层，作为 Higress 的商业版，其性能和稳定性较前两代网关架构而言具有非常显著的优势。

取得的成果

背后的原理

高可用

基于 MSE 体系的高可用能力建设，生产环境使用至今近 9 个月的时间，历经寒暑假 2 轮高峰期数十万在线人数的压力，从未发生过网关不可用问题。

高性能

高扩展