作者：王彬、杏祉堯、黃楓
專案背景
貴州酒店集團有限公司於 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 能夠持續建設更多的功能，用在更多的場景，服務國內外更多的企業。