作者：王彬、杏祉堯、黃楓

專案背景

貴州酒店集團有限公司于 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 活動、直播，用戶最佳實踐，

標籤：其他

上一篇：VoVNet論文解讀

下一篇：Uni開發的app，使用Windows S10，放在ios上，全程跟著一個馬平川。