传统大型国企云原生转型，如何解决弹性、运维和团队协同等问题？
作者：王彬、杏祉尧、黄枫
项目背景
贵州酒店集团有限公司于 2019 年 2 月 28 日注册成立，是经贵州省人民政府批准并授权省国资委履行出资人职责的省管大一型企业，全资及控股子企业 23 家，自营及委管酒店（项目）80 余家，客房近 1.3 万间。
酒店集团组建以来，构建了以酒店运营与管理为核心业务，以旅游商品、教育培训、会议会展、电商科技、黔菜餐饮为支柱业务的“1+N”主营业务架构，正逐步培育打造系列酒店、特色餐饮、教育培训等旅游产业化服务品牌体系。
在 2020 年，成立了贵州乐旅网络科技有限公司专门负责酒店集团信息化建设，贵州乐旅网络科技有限公司肩负着建设酒店集团现代化信息系统的使命，初期在三四个人的快速迭代下，快速构建起了支撑全集团内外部业务的信息系统。随着公司的发展和市场需求的迅速变化，乐旅网络科技也不断壮大，从最初的三四个人发展到了十几人，系统模块越来越多，同时各种问题也开始显现。现状问题&分析酒店集团的信息系统最初部署在阿里云 ECS 上。
系统按照微服务的架构拆分成多个组件，基于 ASP.NET Core 框架开发。在开发运维过程中遇到一系列问题：
组件缺少扩展性：集团的业务有明显的峰谷特性，平台会定期上线一些活动，如土特产秒杀，酒店房间优惠，通过这些活动，用户可以获取抢购贵州名牌白酒的资格等。在活动期间访问量巨大，峰值最高能达到几十万 qps，是平时的几十倍。
同时信息系统依旧延续第一代架构，扩展性不好，没法做到很好的弹性伸缩，对于越来越大的流量，系统稳定性问题愈发凸显。多环境建设不完善：线下测试环境与线上生产环境隔离，线下测试中并不能完全覆盖线上生产环境的场景，在上线时会出现需要上线的组件在线上真实环境中出现预期之外的异常，需要快速恢复，这就需要有很好的版本管理，这一块也是缺失的。
团队协同效率低：整个系统有多个模块，分散在不同团队，ECS 机器也都是独立维护，发版过程需要上下游链路一起协同，按照依赖关系顺序发布，消耗时间长，协同难度大。
监控系统不完善：运行状态没有统一的观测平台，遇到问题也只能子系统分别排查，且缺少问题排查协助工具。技术选型&对比为了更好的对应系统发展的需要，乐旅网络科技决定同阿里云达成战略合作，基于阿里云打造信息平台 2.0。在新架构的设计上，针对当前遇到的痛点问题，项目组在技术选型时定下了以下几个目标：
1. 自动化运维，团队需求多，开发任务重，专门负责运维的同学并不多，希望 2.0 系统可以借助体系化的运维平台，提升运维效率，大幅减轻运维压力。
2. 自动弹缩，团队的业务活动较多，活动到来时有不可预知的流量波峰，之前通过预估扩容的方式存在预估不准和扩展困难的问题，2.0 系统希望可以更加简单的扩缩系统，最好能够通过自动化的方式避免重复的部署和下线操作。
3. 版本管理，测试环境并不能完全模拟线上生产环境，新上线的组件上线后可能会出现问题，希望能够有版本管理的工具，当遇到问题时，可以很方便的切换到指定版本，实现代码资产的可选管理。
4. 团队协同，目前团队协作主要靠人为线下沟通，不同团队的组件都由自己维护，ECS 机器彼此也都权限隔离，2.0 版本希望可以使用统一的系统管理权限，实现不同团队，不同角色都可以使用同一套权限体系，简化团队之间协同的工作。
5. 监控平台，目前的系统缺少监控，于实时运行状态监控几乎没有，目前只有基于机器运行指标的监控。各组件按照开发人员设计自行打日志，当出现问题时，排查问题链路冗长，且没法做到统一的链路追踪。由于系统缺少量化指标，对系统的把控性偏低，没法做到异常预警，也没法很好的做针对性的持续优化。2.0 系统希望在这方面有所改观，能多维度的对系统进行监控，增强对系统的控制力。
为此，项目组在阿里云上进行了第一轮全面筛选，很快选型目标缩小到了自建 K8s 和 SAE，并对这两种技术进行了一系列的比对，主要比对指标如下：
对比这两种技术后，考虑到自建 K8s 本身的复杂性，对技术栈的深度，技术的持续投入和业务的收益，项目组进行了多方面衡量，最终选择了 SAE。
SAE 这款产品在免运维，自动弹缩，可观测等方面都深度符合酒店集团当前项目的需求，项目组在最初选型时就对以下几个功能非常感兴趣：
免运维：SAE 能够免运维底层基础设施，例如 IaaS、K8s、微服务组件和 APM 组件等，无需自建 ZooKeeper、Eureka、Consul 和 Skywalking 等，极大降低开发运维成本。提供商业化稳定性兜底。
自动弹缩：SAE 提供了精准容量+弹性+限流降级一整套高可用产品化解决方案。通过该方案，SAE 能够帮助应用轻松应对流量高峰，在保证业务 SLA 的同时也节省了资源成本。
体系化监控：SAE 无缝集成的 ARMS 产品，具有白屏化应用监控和诊断能力，可用定位到慢 SQL、慢方法、方法的调用堆栈、对于线上问题的分析、排查、预警和解决，提供强有力支持，节省大量的排查时间。
所以，最终项目组毫无疑问的选择了 SAE。项目开发过程&效果在项目组确定选型之后，项目组很快开始着手迁移系统到 SAE，迁移的过程比原计划的更加顺利，由于一开始设计集团的系统时便是基于微服务理念的，所以 ECS 上的组件迁移到 SAE 能够做到很顺滑，代码层面没有大的改动，迁移过程见下图：
随着迁移工作的进行，项目组对 SAE 有了深入的了解，项目组又发现了更多贴合业务的功能点，具体表现：
对 CICD 的支持：SAE 支持云效、Jenkins、源代码、Cloud Toolkit 插件、容器镜像服务等多种部署方式，自动完成从代码提交到应用和任务部署的 DevOps 完整流程，高效替代业内部署复杂、迭代缓慢的传统方式，实现了高效的持续交付流程。
高可用和稳定性的支持：SAE 支持批量发布，微服务无损上下线，使组件在发布更新时，不会影响影响整体链路的可用性，另外 SAE 还支持多可用区的部署，使得应用的稳定性得到进一步的加强。
权限助手：权限助手可以对 SAE 的权限进行可视化配置，精确到应用、任务的读写操作，并在 SAE 控制台生成对应的权限语句，避免因直接在 RAM 控制台手动编辑权限语句而出现纰漏。
操作审计：SAE 记录了所有应用及资源相关的操作详情，包括操作时间、操作内容、操作人 ID 等信息，在出现问题时可以快速追溯原因。
结合这些 SAE 的能力，本次信息平台 2.0 的建设，项目组没有大的改造原来代码逻辑的同时，基本完成了最初定下的目标，同时在开发，运维和协作的几个方面建设了自己的流程规范，快速追平了业内的优秀实践。
总结&展望
项目组最终在 2022 年 2 月份完成了整体的迁移，新系统上线后，通过 SAE 白屏化的操作界面，运维难度和压力都大大降低。根据 rt 和定时的混合策略，应用有了很好的弹缩表现，并且这一切都是自动化的，不再需要运维同学人为的介入，这一点大大的降低了重复劳动。
在团队协作方面，通过阿里云的 RAM 体系，开发，测试，运维同学都统一在 SAE 控制台各司其职，减少了很多不必要的沟通消耗。总体来看，系统上线 SAE 之后，开发运效率提升了 50%+，机器成本下降了 20%，运维人力成本下降了 60%，扩容速度更是比之前快了十几倍，很好的完成了之前定下的目标。第一期上线后，项目组计划信息平台还会有更多的技术优化点，其中有些 SAE 目前还有所欠缺，后面还需要与SAE团队共同探讨解决：
●对多语言的支持：目前系统基于.net 框架 C#语言，SAE 的微服务治理和链路追踪没有很好的支持，这方面需要加强建设。
●多应用版本的联动：SAE 的灰度发布是对单应用操作，单次发布有时会发布多个应用，不同应用之间还有依赖关系，项目组希望能够提供多应用的联动，根据依赖关系自动完成多应用的发布更新。
最后，相信 SAE 这个产品能够越来越好，希望 SAE 能够持续建设更多的功能，用在更多的场景，服务国内外更多的企业。
更多内容关注 Serverless 微信公众号（ID：serverlessdevs），汇集 Serverless 技术最全内容，定期举办 Serverless 活动、直播，用户最佳实践。
