作者：王彬|杏祉尧|黄枫
项目布景
贵州酒店集团有限公司于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 能够继续建造更多的功用，用在更多的场景，服务国内外更多的企业。
