为了更好应对业务的发展，乐旅网络科技决定同阿里云达成战略合作，基于阿里云打造信息平台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，迁移的过程比原计划的更加顺利，由于一开始设计系统时便是基于微服务理念的，所以ECS上的组件迁移到SAE过程中很顺滑，代码层面没有大的改动。

随着迁移工作的进行，项目组对SAE有了深入的了解，又发现了更多贴合业务的功能点，具体表现：

• 支持CICD

  SAE支持云效、Jenkins、源代码、Cloud Toolkit插件、容器镜像服务等多种部署方式，自动完成从代码提交到应用和任务部署的DevOps完整流程，高效替代业内部署复杂、迭代缓慢的传统方式，实现了高效的持续交付流程。

• 支持高可用和稳定性

  SAE支持批量发布，微服务无损上下线，使组件在发布更新时，不会影响整体链路的可用性，另外SAE还支持多可用区的部署，使得应用的稳定性得到进一步的加强。

• 权限助手

  权限助手可以对SAE的权限进行可视化配置，精确到应用、任务的读写操作，并在SAE控制台生成对应的权限语句，避免因直接在RAM控制台手动编辑权限语句而出现纰漏。

• 操作审计

  SAE记录了所有应用及资源相关的操作详情，包括操作时间、操作内容、操作人ID等信息，在出现问题时可以快速追溯原因。

结合这些SAE的能力，项目组无需对原有的代码逻辑进行大的改造，完成了本次信息平台2.0的建设。同时，在开发、运维和协作等方面建设了自己的流程规范，快速追平了业内的优秀实践。