作者：王彬 | 杏祉尧 | 黄枫
我的项目背景
贵州酒店团体有限公司于 2019 年 2 月 28 日注册成立，是经贵州省人民政府批准并受权省国资委履行出资人职责的省管大一型企业，全资及控股子企业 23 家，自营及委管酒店（我的项目）80 余家，客房近 1.3 万间。
酒店团体组建以来，构建了以酒店经营与治理为外围业务，以游览商品、教育培训、会议会展、电商科技、黔菜餐饮为支柱业务的“1+N”主营业务架构，正逐渐培养打造系列酒店、特色餐饮、教育培训等游览产业化服务品牌体系。
在 2020 年，成立了贵州乐旅网络科技有限公司专门负责酒店团体信息化建设，贵州乐旅网络科技有限公司肩负着建设酒店团体现代化信息系统的使命，初期在三四个人的疾速迭代下，疾速构建起了撑持全团体内外部业务的信息系统。随着公司的倒退和市场需求的迅速变动，乐旅网络科技也一直壮大，从最后的三四个人倒退到了十几人，零碎模块越来越多，同时各种问题也开始浮现。
现状问题 & 剖析
酒店团体的信息系统最后部署在阿里云 ECS 上。零碎依照微服务的架构拆分成多个组件，基于 ASP.NET Core 框架开发。在开发运维过程中遇到一系列问题：
组件短少扩展性 ：团体的业务有显著的峰谷个性，平台会定期上线一些流动，如土特产秒杀，酒店房间优惠，通过这些流动，用户能够获取抢购贵州名牌白酒的资格等。在流动期间访问量微小，峰值最高能达到几十万 qps，是平时的几十倍。同时信息系统仍旧连续第一代架构，扩展性不好，没法做到很好的弹性伸缩，对于越来越大的流量，零碎稳定性问题愈发凸显。
多环境建设不欠缺 ：线下测试环境与线上生产环境隔离，线下测试中并不能齐全笼罩线上生产环境的场景，在上线时会呈现须要上线的组件在线上实在环境中呈现预期之外的异样，须要疾速复原，这就须要有很好的版本治理，这一块也是缺失的。
团队协同效率低 ：整个零碎有多个模块，扩散在不同团队，ECS 机器也都是独立保护，发版过程须要上下游链路一起协同，依照依赖关系程序公布，耗费工夫长，协同难度大。
监控零碎不欠缺 ：运行状态没有对立的观测平台，遇到问题也只能子系统别离排查，且短少问题排查帮助工具。
技术选型 & 比照
为了更好的对应零碎倒退的须要，乐旅网络科技决定同阿里云达成策略单干，基于阿里云打造信息平台 2.0。
在新架构的设计上，针对以后遇到的痛点问题，项目组在技术选型时定下了以下几个指标：
- 自动化运维，团队需要多，开发工作重，专门负责运维的同学并不多，心愿 2.0 零碎能够借助体系化的运维平台，晋升运维效率，大幅加重运维压力。
- 自动弹缩，团队的业务流动较多，流动到来时有不可预知的流量波峰，之前通过预估扩容的形式存在预估不准和扩大艰难的问题，2.0 零碎心愿能够更加简略的扩缩零碎，最好可能通过自动化的形式防止反复的部署和下线操作。
- 版本治理，测试环境并不能齐全模仿线上生产环境，新上线的组件上线后可能会呈现问题，心愿可能有版本治理的工具，当遇到问题时，能够很不便的切换到指定版本，实现代码资产的可选治理。
- 团队协同，目前团队合作次要靠人为线下沟通，不同团队的组件都由本人保护，ECS 机器彼此也都权限隔离，2.0 版本心愿能够应用对立的零碎管理权限，实现不同团队，不同角色都能够应用同一套权限体系，简化团队之间协同的工作。
- 监控平台，目前的零碎短少监控，于实时运行状态监控简直没有，目前只有基于机器运行指标的监控。各组件依照开发人员设计自行打日志，当呈现问题时，排查问题链路简短，且没法做到对立的链路追踪。因为零碎短少量化指标，对系统的把控性偏低，没法做到异样预警，也没法很好的做针对性的继续优化。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 可能继续建设更多的性能，用在更多的场景，服务国内外更多的企业。