杭州铭师堂的云原生升级实践

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

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

公司介绍

Cloud Native

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

成立十余年以来，铭师堂不断汇聚优质的全国各地教育资源，并展开先进科学技术在学校教育智能化领域、学生个性化学习领域的应用研究。杭州铭师堂始终坚守使命，持续创新，“赋能学校、培养学生”，在教育信息化 2.0 趋势下，致力于促进线上教育与线下教育的高度融合，以学校为核心场景，与学校携手共建互联网学习空间，为学校与学生提供学习解决方案，极大促进教学效率的提升。

升学e网通是由杭州铭师堂公司运营的针对高中生的综合性在线教育品牌。重点打造了教育智能化系统、优质资源系统和大数据信息系统，涵盖互联网生涯规划、互联网在线学习以及互联网心理解决方案等内容。针对不同学校，打破物理空间的限制，量身定制虚拟的网络学习空间，希望用互联网教育推进个性化学习的实现，促进优质资源的跨地域流动，促进每一位高中生更全面发展。

业务全量上云，为云原生化打好基础

Cloud Native

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

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

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

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

全面拥抱云原生，保障稳定性

Cloud Native

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

基础设施：注册配置中心迁移

配置中心和注册中心的作用，技术发展至今，相比大家都已经非常清楚，这里就不做赘述。升级前，杭州铭师堂采用 Eureka 集群作为注册中心，采用 Apollo 管理业务应用配置，采用 Spring Cloud Config 管理中间件配置，在过往使用中，针对这三款组件，业界通用问题都遇到过，例如：如集群不可用、Eureka 无法及时摘除下线实例、配置推送不及时等，在业务关键时期，因为注册中心或者配置中心的不可用，是绝对不能容忍的。

针对性的解法

基于此，先解决微服务下这一关键基础设施的稳定性问题。通过充分调研和论证，MSE Nacos 产品能够很好的满足诉求，具体优势如下：

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

针对配置中心，因为使用 Apollo+Spring Cloud Config 两类组件，因此也针对性自研开发了配套迁移工具，同样实现了丝滑平迁。

取得的成果

配置注册中心 SLA 提升到 100%，再无一例因其稳定性或者功能性问题导致应用不可用案例发生。此外，杭州铭师堂实践了一套管理标准，让原本杂乱的配置实现了规范化。

namespace：环境，目前有四套，开发、测试、预发、生产group：组，定义为业务线dataId：配置标识，分为公共配置和应用私有配置：全栈公共配置：要求 group 为 public，dataId 为 public-{配置文件名}.{扩展名}。业务域公共配置：要求 group 为业务线，dataId 为 public-{配置文件名}.{扩展名}。业务配置：group 为业务线，dataId 为{应用名称}.{扩展名}，如果有扩展配置，可定义为{应用名称}-{自定义名称}.{扩展名}。业务敏感配置：group 为业务线，dataId 为{敏感配置文件名}.{扩展名}，提供给后续结合 KMS 实现敏感配置的加密处理。

服务治理全面落地与实践

随着上云后，虽然基础设施弹性问题得以解决，但系统所面临的压力与挑战并未减轻，问题和风险在变更态和运行态显得尤为突出。因此，杭州铭师堂结合 MSE 微服务引擎的多项能力，不断打磨和实践，成功做到了服务运行时的高可用防护 & 服务变更时的可观测、可灰度、可回滚。接下来，从高可用三大利器、安全发布两大法宝（无损上下线、全链路灰度），展开进行详细介绍。

针对单应用运行时的高可用，随着业界技术发展，已经形成了一套通用的解决方案，也就是今天说的三大利器：限流、熔断、降级。从 2018 年 .NET 转 Java 开始，杭州铭师堂一直沿用 Spring Cloud 这套微服务框架来搭建业务系统，在高可用防护这块，一直依赖于 Spring Cloud Hystrix 的能力。使用过 Hystrix 的同学应该都了解，它所具备的防护能力非常的局限，缺点非常明显：

防护能力不足，无法以 QPS 维度限制接口访问。线程池隔离占用资源高：在暑期高峰期，复杂的核心应用因为使用线程池隔离策略，光内存占用就多了几个 GB，实在是过于繁重。规则无法实时性等等。线上监控发现答题接口被刷，无法利用 Hystrix 立即进行防护手段的干预，需要调整代码才能处理，非常被动。针对性的解法

随着阿里开源的 Sentinel 这一神器，慢慢替代 Hystrix 成为业界高可用解决方案的标准。经过调研和对比，最终杭州铭师堂选择了商业版 Sentinel 产品 AHAS，后来统一合并到 MSE 微服务引擎流量治理中。对比 Hystrix，其具备了明显的优势：

多维的防护能力：基于 QPS 的限流、基于并发数的隔离、基于异常数或者慢调用的熔断机制等等。轻量的资源占用：借助并发数的隔离机制，远远不需要像线程池方式这么重量级，内存资源占用节省至少 10 倍以上。规则实时生效：针对突发情况能够快速进行响应，在关键时候能解燃眉之急。

如上图所示，杭州铭师堂在实践中落地了一套 SOP 机制：

在网关层进行粗粒度的限流控制，来防止当前超出系统容量下的流量，规则命中后日志接入 SLS，配套监控告警，及时感知后，进行干预，针对合理请求进行系统容量扩容，预留足够的响应时间。在应用层进行细粒度的限流、熔断、降级组合控制，让强依赖在可控范围内进行调用，针对弱依赖可降级降级，不可降级进行熔断，避免被下游慢调用拖垮。配合应用各项指标监控告警，充分利用 MSE 流量治理的实时性能力，及时调整，保障应用高可用。取得的成果

生产环境应用 100% 完成接入和应用，针对不同场景共配置几十项规则实现高可用防护。通过以上措施的落地实施，全栈系统未再出现过一例因外部突增流量或者下游慢调用而拖垮大盘的情况，效果可谓是立竿见影。

业务需求开发完成，在发版日准备发版，会发现应用发布后，总会有 5xx 相关的告警，通过 TraceId 一排查，就会发现是这个应用刚启动的新副本实例，经过深入分析，基本对应到以下这几类情况：

非优雅下线：服务无法及时下线，导致上游应用还在继续调用已下线的副本实例，从而请求处理失败。非优雅上线：应用发布后，K8s 就绪检查以健康检查接口来判定，而健康检查接口里包含大量检测依赖服务的检查，耗时过久，造成健康检查不通过。一些应用在初始化时存在复杂逻辑，导致时间比较长，此时流量过大，会造成大量请求超时、阻塞等问题。针对性的解法

针对以上问题，分成两个阶段进行针对性解决。

具体做法如下：

非优雅下线：通过对 Nacos 源码的研究，了解到 Nacos 服务端存在 1 分钟对服务实例元数据记忆逻辑，借助 K8S preStop 机制，Sleep 60s，来达到应用及时准确的下线。非优雅上线：统一规范应用健康检查机制，在原有/health 接口里将逻辑变薄，去除原有复杂逻辑，让健康检查足够轻量。针对初始化逻辑复杂的应用，增加延迟注册的时间，让其在初始化完成后对外提供服务。

经过上述尝试后，虽然有损发布的情况得到好转，但是在业务高峰期，总是还会遇到，问题并没有得到根本解决。于是，经过详细的方案调研，在自研和云产品之间，杭州铭师堂最终选择了使用 MSE 无损上下线的能力，避免了自己去针对各类场景投入资源进行处理的成本。

取得的成果

实现了 100+Java 应用，下线 100% 无损，上线（不使用 Sharding-JDBC 组件）应用 100% 无损，让发布更有底气，能够将更多的精力聚焦到业务需求本身。

无损下线

MSE Agent 实现上下游的主动通知机制，在下游应用副本下线时，能够做到及时的通知上游应用，剔除已下线副本实例，从而避免了上游应用仍旧调用下游已下线实例，造成 Connect Refused 等相关错误。

无损上线

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 的商业版，其性能和稳定性较前两代网关架构而言具有非常显著的优势。