作者:王彬|杏祉尧|黄枫

项目布景

贵州酒店集团有限公司于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 可以继续建造更多的功用,用在更多的场景,服务国内外更多的企业。