完美日記創立于2017年，這家公司上線不到兩年即成為天貓彩妝銷冠，2019年成為11年來第一個登上天貓雙十一彩妝榜首的國貨品牌，包攬天貓2019全年彩妝銷冠；2020年4月成為首個亮相天貓超級品牌日的國貨彩妝品牌，同時勇破彩妝品牌銷售紀錄。另外，完美日記已在全國各地開設了100家線下店，計劃至2022年底開店超600家。截至2020年4月，品牌SKU超過700個，全網用戶粉絲數量超過2500萬，月曝光量10億+。

“輕研發、重營銷”是流量思維企業的通病，為了“打造互聯網時代新的美妝集團”，在依靠流量和營銷快速占據市場的同時，完美日記也在不斷夯實其技術底座。今年4月，完美日記已完成IT系統全面容器化，保證了每一次大促活動的系統穩定性和可用性，同時利用阿里云ACK容器快速彈性擴縮容，節約服務器成本50%以上。

1、完美日記容器化改造之路

對于一家創業公司而言，常常有三個問題擺在面前：

如何高效、低成本地搭建系統，同時確保安全穩定？
如何敏捷構建和發布應用，滿足業務需求？
如何提高團隊開發效率，確保開發質量？

早期大部分互聯網公司都是直接購買服務器，租用IDC機房的機架部署，應用是直接運行在物理機上，如果要擴展必須購買新的服務器。IDC會頻繁出現各種故障，如果遇到IDC遷移就更麻煩，必須半夜搬機器，天亮前上線，對于企業來說，在成本、服務穩定性、工作效率上都是很大的消耗。

2019年雙11前期，完美日記小程序剛剛上線兩個月，就經歷雙11大促的磨礪。在這兩個月里，傳統的部署方式，特別是有部分應用需要（openrestry）在SLB上面配置，那么運維人員就要在SLB上一個個勾選服務器，這會導致發布版本的時間需要半個小時以上。如果發版過程中出現問題，往往時間還會延長到一個小時以上。

在擴容機器的時候，使用其中2臺服務器在阿里云打OS鏡像，采用開機自啟動腳本方式啟動應用，針對每次運營活動的實際情況進行擴容。為了保持系統的穩定性，運維人員就需要在每晚23:00點以后通過人工操作進行擴容，手工配置SLB。最后測試人員進行測試，平均每次擴容都需要半個小時以上。并且由于雙11期間處于大流量、高并發的場景，整個運維人員對服務器維護、版本迭代、數據庫運維等都必須格外謹慎，稍有不慎會導致線上生產事故，服務器運維壓力巨大。

2019年雙11之后，完美日記就開始針對性測試阿里云容器服務ACK，并開始容器化改造。

之所以選擇容器技術，是因為完美日記要構建一套現代化IT系統以滿足快速變化的需求和挖掘更多的數據價值。具體來看，一方面，完美日記對業務的快速創新以及現有業務的實時性和交互性需求都在不斷地增長；另外一方面，完美日記對數據的重視程度也在不斷提高，尤其是用戶數據的重要性。如何提供優于競爭對手的服務和用戶體驗，如何合理、有效地發掘更多的數據價值，成為完美日記迫切的需求。容器技術以其獨有的高效敏捷和易于擴展的特性，加之龐大的生態系統，可以充分滿足完美日記不同階段的IT需求，這也是完美日記最終選擇IT系統全面容器化改造的原因。

完美日記最開始是自建K8s，使用的是K8s開源版本，但是開源版本有很多bug未知，安全性也是未知，并沒有一個比較友好的Web操作界面，還需要大量運維人員解決運行時出現突然的各種問題。從成本和效率等維度來看，并不是一條便捷的路，思慮再三，完美日記最終選擇阿里云容器服務ACK。“我們的技術人員跟阿里云的技術人員其實非常熟悉，在雙11期間他們也給予了很多技術層面的支持，我們遇到的問題他們基本都遇到過，我們沒遇到的問題，他們也都遇到過，站在巨人的肩膀上進行容器化改造，對于當下的完美日記而言，是最合適的。”

完美日記的容器化實踐是按照項目區分兩條線并行，第一條線是一次性前后端全部遷移，第二條線是分應用分批次前后端分別遷移。

（1）一次性前后端全部遷移

2019年11月初-2019年11月中旬，完美日記開始計劃容器化改造的準備事宜以及改造方案，包括容器化改造方案初步實施，阿里云K8s選型，阿里云K8s選型后進行初步測試，結合公司情況和人員相配比情況，最終選擇了阿里云托管K8s Master版本進行大規模測試工作，并開始準備UAT環境切換前期工作等事宜。

2019年11月中旬，第一次切換UAT環境到K8s中失敗，因為還有部分在開發中的模塊，而K8s中沒有對應的模塊，因此切換回非K8s環境。

2019年11月底-2019年12月初，將UAT環境切換到K8s中，這次切換吸取了第一次切換失敗的經驗，UAT環境正式切換到K8s中。

2019年12月初-2019年12月中，觀察整個UAT環境是否存在有重大問題，然后進行調整。將整個K8s UAT環境按照雙11量級進行四輪壓力測試，將結果反饋，然后不斷進行調整。2019年12月中，嘗試將后臺正式環境切換到K8s正式環境中，但由于UAT環境中代碼版本和正式環境中代碼版本不一致，導致第一次嘗試切換失敗。

2019年12月中，在第一次切換后臺失敗中吸取了版本不一致的教訓后，經過一天的努力終于將后臺正式環境切換到K8s正式環境中，正式環境走出艱難的容器化改造第一步。2020年1月初，經過一天努力，將正式環境順利切換到K8s正式環境中。

（2）分應用分批次遷移

2019年11月底開始準備遷移測試環境方案，2019年12月初，后端和中間件開始新增UAT環境。

2020年1月2日，后端準備完成。1月3日準備開始前端，1月17日前端完成、UAT環境正式使用。1月17日開始準備正式環境遷移方案，2月遷移方案完成，2月中上旬開始遷移后端，3月中旬后端遷移完成，ZooKeeper、Eureka遷移完成。3月下旬，前端開始遷移，4月初前端基本遷移完成。最終在4月中旬，完美日記IT系統全部遷移完成。

至此，完美日記全面容器化改造完成。
在容器化部署過程中，利用ACK的快速彈性應對大促時的資源快速擴容。將完美日記IT系統提前接入阿里云鏈路追蹤產品ARMS，用于對分布式環境下復雜的服務調用進行跟蹤，對異常服務進行定位，完美日記可以在測試和生產中快速發現問題，快速修復。使用性能測試服務PTS進行壓測，利用PTS的秒級流量拉起、真實地理位置流量等特性，以最真實的互聯網流量進行壓測。收集壓測數據，分析系統強弱依賴和關鍵瓶頸點，對關鍵業務接口、關鍵第三方調用、數據庫慢調用、系統整體負載等進行限流保護。在大促前進行ECS/RDS/安全等產品擴容、鏈路梳理、緩存/連接池預熱、監控大屏制作、后端資源保障等，幫助完美日記在大促平穩進行，保持絲般順滑。

除了采用容器服務ACK之外，完美日記在一開始進行容器化改造時就使用了阿里云鏡像企業版ACR EE，它的優勢是比自建harbor要穩定與低成本，因為自建harbor需要考慮計算、數據庫以及磁盤成本，如果項目很多或者鏡像比較多，那么磁盤成本將比較高。鏡像企業版不用考慮維護成本。另外，鏡像企業版并發比自建harbor要高，如果大批量進行擴容，自建harbor往往容易出鏡像PULL問題，但是鏡像企業版就沒有這種擔憂。

另外，完美日記也通過ARMS Prometheus來監控系統可能出現的問題，并能針對性地解決問題。ARMS還可以解決整個K8s底層監控（Prometheus）的維護和成本高的難題，它能監控應用每個pod資源使用情況，對pod資源進行調整。K8s底層監控（Prometheus）可以做一個自定義大盤，將Prometheus全部監控信息完整顯示出來。

容器化改造之后，整個系統“輕松了很多”。1月初，在切換到K8s正式環境后，擴容時間只需要90秒左右，節約了6~8倍時間，減少了一名服務器運維人員。根據運營節奏進行擴容，服務器擴容成本節約70%~90%。同時，部署效率大幅提升，可根據文件模板秒級創建一個服務，部署時間減少90%以上。

另外，服務器資源自動計算部署到服務器，利用隔離技術可部署多個項目服務器，利用率提高50%以上。服務模塊的自動負載均衡無需人工干預，工作量減少90%以上。服務模塊伸縮容無需編寫腳本，只需點擊伸縮按鈕即可，減少人工錯誤率，工作量減少70%以上。服務模塊不可用會自動剔除，自動重啟服務模塊。服務器宕機時，服務器上運行的服務模塊會自動轉移到可用服務器上，無需人工干預，工作量減少100%。

2、容器化改造更大的挑戰是在技術和人員上做好準備

當企業完成了容器化改造之后，在生產環境中應用容器技術，并計劃擴大應用規模，這時企業就必須在技術和人員上做好準備：運維人員是否有足夠的能力來應對大規模應用帶來的挑戰，研發人員是否有足夠的技術準備能隨時解決大規模應用帶來的問題，產品的架構設計是否可以滿足未來的企業需求，同時組織架構和文化是否已經適應企業新的戰略發展等。

換句話說，如何讓項目組和開發人員之間達成技術同頻、戰略同頻更具挑戰性，這其實也是很多在做容器化改造的企業面臨的共同難題。

出現這個問題的核心是項目組的開發人員、架構師、運維人員關注點不一致。開發人員關注系統平穩運行和業務開發，而不關心生產環境底層，只要不影響到生產環境和測試環境就可以。架構師關注底層是否穩定運行，技術架構是否符合未來3~5年技術發展，技術是否簡單高效等。運維人員關注發布版本是否簡單高效，環境是否能統一，擴縮容時間成本，底層運維過程是否能有解決方案等。

正是由于三方的關注點不同，因此在遷移過程中就不可避免會花費大量的溝通成本。因為K8s這套系統有別于傳統的部署過程，開發人員對 centOS系統、Nginx、MQ、MySQL、查詢日志等比較熟悉，但對于K8s不甚了解，Ingress、Docker配置化、Deployment配置、Service等往往已經到了開發人員對技術認知的邊界了，這就需要花費較長的時間去解答大家的疑問，才能往下一步進行。

對于這類問題，每個企業的解決方案都不同，最核心的就是把相關人員的知識邊界盡量拉到同一級別，最大程度地減少溝通成本和沖突。完美日記是采用“及時同步、責任到人、內部培訓”的方法，比如每次在任何環境做的調整都需要在容器化改造群內通知相關人員，保證大家的認知一致；在內部推進“誰負責誰完善”的文檔制度；同時組織一些內部技術培訓，讓關鍵開發人員在公司內部對K8s進行培訓講解。還有就是推進企業內部新的、統一的技術文化等。

3、未來規劃

目前各大公有云廠商都推出了容器服務，還有不少獨立的容器云公司。如果企業一開始就是建立在公有云之上，推薦直接使用相應的容器服務，不僅可以快速搭建系統，還能大幅降低運維成本，提高效率，輕松實踐DevOps。在容器環境下，很多日常操作都自動化或半自動化了，比如應用的部署和發布、擴容等，容器編排具有自愈能力，即使出現問題，也能減少人工的干預，大大減輕運維人員的工作壓力。

完美日記下一步會重點關注三方面，一是進行Ingress+Gateway單獨部署；二是使用ECI+HAP+EW+AHAS（自動擴容數據來源）進一步優化成本，應對突發流量；三是考慮采用服務化網格技術。

如今，云原生已經成為企業數字化轉型的關鍵策略，由于應用需要快速開發和交付，這就促使企業采用云原生的方法來開發應用，以提高效率，并增加靈活性。對于身處云原生時代的企業和開發者而言，不僅需要了解如何通過容器實現構建應用的新方式，更是要以開闊的視野和開放的心態去擁抱云原生生態。

對于企業而言，需要具備一定的前瞻性，對于容器生態圈的主流技術和發展要有足夠的把握，才能更好地將現有業務與容器技術相結合。隨著企業對技術的不斷探索，業務系統的逐步演進，應用規模的日漸增大，如何更好地與開源生態系統相結合，擴大企業的技術影響力，同時引入更合適的人才，是云原生時代下企業要考慮的問題。

點擊閱讀原文，了解更多阿里云容器服務ACK技術詳解與客戶案例。
閱讀原文鏈接：https://www.aliyun.com/product/kubernetes?spm=5176.12825654.1kquk9v2l.1.e2cd2c4aqP4QCp

作者：阿里云云棲號
鏈接：https://segmentfault.com/a/1190000023262992
來源：SegmentFault 思否
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的阿里发布2020农产品电商报告数字农业将成风口的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。