簡介： 系統上線 SAE 之後，開發運效率提升了 50%+，機器成本下降了 20%，運維人力成本下降了 60%，擴容速度更是比之前快了十幾倍，很好的完成了之前定下的目標。
作者：王彬、杏祉堯、黃楓
項目背景
貴州酒店集團有限公司於 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 活動、直播，用戶最佳實踐。