云縱持續交付環境管理進化歷程

破天（李進莊）、冬草（宋玥輝） 創作于2018-9-10

一個公司的運維能力強弱和你線上環境敲命令是有關的，
你越是喜歡上線敲命令，你的運維能力就越弱，
越是通過自動化來處理問題，你的運維能力就越強。
——陳皓，2017

持續集成（Continuous Integration, CI）是一種軟件開發實踐，即團隊開發成員經常集成他們的工作，通過每個成員每天至少集成一次，也就意味著每天可能會發生多次集成。每次集成都通過自動化的構建（包括編譯、發布、自動化測試）來驗證，從而盡早地發現集成錯誤。

持續部署（Continuous Deployment, CD）是通過自動化的構建、測試和部署，循環快速交付高質量的產品。某種程度上代表了一個開發團隊工程化的程度，畢竟快速運轉的互聯網公司人力成本會高于機器，投資于機器優化開發流程也提高了人效。

這都說明了環境管理自動化對于互聯網公司的重要性。

Docker自2014年以來非常火熱，隨著容器化的如日中天，另一個理念DevOps也在不斷傳播。大部分IT從業者對于DevOps本身也都有一定的了解和認識，然而企業內部要想根據DevOps思想實踐一條自己的路，絕對不是一件簡單的事。而我司自2014年11月份開始引入容器到現在為止，一直在DevOps的路上不斷地探索中，在這期間業界也沒有出現一套標準的開源工具集可以借鑒，因此我們只能摸著石頭過河。以下為我司的一些經驗分享。

我司的環境演化史

演進歷史-云縱

2014年11月份在容器化啟動之前，我司的開發、測試及線上環境都是部署在基于OpenStack的虛擬化服務器上，技術團隊需要維護的環境劃分得很細：開發環境、測試環境、特殊測試環境、緊急測試環境、鏡像環境、線上環境。

2015年9月隨著容器化技術的使用以及云縱業務調整，環境管理縮減到了四個。

到了2016年3月，我司啟動了CloudEngine的開發，一個基于私有云的研發協作系統。基于CloudEngine，我司初步實現了DevOps的雛形。在之后，根據業務需求，我們先后實現私有云灰度發布功能、多機房混合云多活管理功能。

基于CloudEngine的基礎環境管理架構如下圖所示，CloudEngine架設在TouchStone（容器化管理平臺）、SimpleWay（運維自動化平臺）、iDB（數據庫自動化運維平臺）、Jenkins（注：開源產品）等基礎設施系統之上，可以看作是一個元數據管理者和流程調度的發起者，同時支持虛擬機和容器資源申請等，等同于我們的私有云管理系統+項目需求開發測試跟蹤系統的結合體。

基礎管理體系-云縱

環境演化推動過程

CloudEngine引入背景

在CloudEngine引入之前，開發使用開發聯調環境，測試使用測試環境，此時我們最大的痛點是多需求并發開發，或多需求并發測試，這個時候我們只有兩個解決方案：

1. 多準備幾個開發聯調環境和測試環境(這也是容器化之前維護很多環境的原因之一)，每個需求版本使用自己單獨的環境，但是環境維護困難，開發人員排查起來問題也困難。
2. 代碼變更要求向上兼容，但是向上兼容有時候是比較困難的，甚至有時候只能串行。

為了解決快速部署一套開發聯調環境或者測試環境，我們很早就引入了容器化技術，但是即使通過容器化技術，環境維護也是比較困難的。

CloudEngine1.0實現CI/CD流水線管理

機緣巧合之下我們接觸并深入了解了螞蟻金服的研發協作平臺，我們把龐大的螞蟻金服研發支撐體系濃縮為四個平臺：ACP（阿里協作平臺）、九州資源管控平臺、AQC（螞蟻質量基礎設施平臺）、Zpass（螞蟻集團發布部署平臺）。ACP是總驅動，九州、AQC、Zpass作為基礎設施，整個形成一套CI/CD流水線。

阿里研發協作-云縱

而此時，我司的持續集成體系如下：

項目管理、測試用例、缺陷管理我們有一套管理體系；

自動化編譯、自動化部署、自動化測試我們有一套管理體系；

鏡像管理、應用發布、應用監測我們有一套管理體系；

容器管理、集群管理我們也有一套管理體系。

我們發現私有云體系的基礎系統我們已經基本具備，現在需要一個PAAS平臺來把研發從環境申請到測試發布上線整個研發測試鏈路管理起來，因此我們（注：牽頭人是田志全）提出了CloudEngine（下面簡稱CE）的建設解決方案，功能點如下：

CE架構-云縱

CE機器申請：當一個需求從提出進入研發階段后，研發經理在CE中選擇應用、環境、虛擬化方案、Git地址等信息就可以做到一鍵完成機器申請、編譯構建、環境部署和環境監控。研發在Git開發分支上進行編碼開發，當開發到一定階段隨時可以在服務申請列表中找到申請的機器進行重新部署，以達到CI（持續集成）的目的。

CE提測申請：當研發開發聯調完成后，研發經理在CE中可以直接創建提測單，CE把多個應用打包到一起進行提測。測試人員直接使用研發申請的環境進行測試（不會創建新的測試環境）。

CE上線發布：當測試人員測試通過之后，測試經理在CE中可以直接創建上線工單，CE調用SimpleWay直接會把之前環境的的Docker鏡像推送到線上環境（一包通用），如阿里云，如自建IDC機房，以達到CD（持續部署）的目的。

在整個CI/CD流水線管理中涉及兩個核心技術點要解決：

• 引入Stable環境概念

日常開發申請機器時，通常只需申請有代碼變更的應用機器，所依賴的其他應用均來自于Stable環境。如下圖所示，當我們訂單服務有代碼變更的時候，只需要申請一個Dev環境訂單服務機器即可，購物車和支付服務還使用Stable環境的機器，即系統調用鏈路要能判斷出是否有非Stable環境的應用，沒有的話才會調用Stable環境應用。

穩定環境原理-云縱

我司應用之間的調用基本上使用Dubbo的RPC調用（而不是微服務的RestFull API，改造成本低一些），我們的解決方案是在容器申請時的ENV中打入環境標示，比如開發Stable環境標示為：SYS_ENV=ds，開發dev環境標示為：SYS_ENV=d，Dubbo在做服務調用時，優先選擇非Stable環境的機器。

另外一個考慮點是MQ，我司使用的是自建Notify MQ，我們的Notify是按QueueName進行消息分組的，解決方案是不同的環境創建不同的QueueName即可，無需代碼改造。

• 一包通用解決方案

一包通用指測試和線上使用相同的鏡像包，技術難點在于配置信息可根據不同環境自動拉取配置。這樣做的好處是測試人員測試的結果能真實反映到線上環境，避免上線重新編譯打包引起的各種不一致問題（之前我們經常遇到上線分支合并出現問題影響到了線上環境）。

我們的解決方案是使用Diamond分布式配置管理統一管理各個應用各個環境的配置信息，各個應用的鏡像在啟動的時候根據dockerfile和tpl.properties(應用配置模版)從Diamond中拉取自己的配置信息，寫入app.properties（應用真實配置文件），之后再進行容器啟動以適配具體環境。具體流程如下。

一鏡到底一包通用-云縱

CloudEngine2.0實現灰度發布管理

2017年開始隨著我司業務擴張，每周都有三到四次大的上線操作，為了不影響線上用戶體驗，每次上線都要求在0點之后進行，上線完成之后，測試人員要通跑一遍業務流程，隨著業務不斷的復雜化，每次上線都要求相關測試和研發進行一次通宵，有些時候遇到上線失敗回滾，還有可能通宵兩次。為了解決這個痛點，我司根據自己的私有云管理情況提出了一套灰度發布解決方案。

灰度發布原理-云縱

灰度解決方案主要支持流量比例規則和指定IP規則。外網第一層Nginx的Lua腳本根據灰度規則組配置進行請求流量篩選，符合灰度條件的請求會在header中打入灰度標示并轉發到灰度Nginx，從這里開始環境進行了隔離，但是到了后臺服務端因為有環境重合的可能，所以我們利用ThreadLocal實現了一套灰度上下文，Dubbo做服務分發調用的時候，根據灰度上下文中的標示做判斷進行灰度環境調用，整個請求處理流程如上圖所示。

這里我們也想過完全的環境隔離方案，即灰度單獨使用一整套自己的環境，但是我們分析灰度的業務也是線上業務，我們的訴求是請求隨時可以進入灰度，隨時也可以退出灰度，所以灰度庫和線上庫應該是一套數據庫，另外上線灰度環境的應用可能是任何一個或多個應用，所以最終我們選擇了侵入性比較高的強控制方案。

CE3.0+SimpleWay2.0實現跨機房多活

2018年年初開始，隨著我司業務繼續擴張，尤其支付業務的重要性越來越高，本年3月份我司正式提出啟動異地多活項目，著重解決雙機房切換問題。

異地多活的實現目標：

1. 雙機房同時提供服務，流量按照指定規則打到不同機房；
2. 當機房A發生災難時，能將流量全部切換到機房B且不會壓垮機房B的既有服務；
3. 機房之間數據雙向同步，數據同步在2秒內完成。不同機房短時間內不對同一行數據進行寫操作；

異地多活的技術難點主要在數據跨機房同步和流量請求控制兩方面，經過多次討論分析我們最終確定的解決方案如下：

異地雙活原理-云縱

• 每個機房配備有一個管控系統、兩套業務分片、一份全量MySQL節點，分片之間的應用是完全的網絡隔離。
• 流量按商戶ID進行規則分流，不同商戶分流到不同機房。
• 每個機房有一個主分片和一個輔分片，主分片主要承接分到這個機房的流量，輔分片是另一個機房主分片的備用分片，當另一個機房掛掉，流程切到這個機房的輔分片上，主分片的業務不受影響。
• 數據庫獨立于分片之外，每個機房一套完整的數據庫，采用Otter服務實現雙向數據同步。

跨機房數據同步需要注意的點：

跨機房同步類型主要有三種：不同步、單向同步、雙向同步。其中不同步不必考慮，需要考慮的只有單向和雙向兩種：

跨機房同步注意事項-云縱

業務系統改造點（注意點）

業務改造點-云縱

其他補充點

多活解決方案的目標主要是做機房容災，即當A機房發生不可抗拒災難后，我們可以快速把流量切到B機房以減少災難造成的影響，以目前我們的解決方案，在災難發生的一瞬間，數據雙機房備份如果沒有同步完成也會有一些細微的影響，目前只能人工干預，在災難結束后人工對受影響的數據進行訂正。

未來的進化方向

息壤（質量管理）

2018年已進入下半場，為了繼續提升我司的生產效率，保證我司工程發布質量和合規性，同時考慮我司私有云等各種云的操作復雜性，降低學習成本和犯錯幾率，需要繼續完善我司的大研發協作平臺，對標螞蟻的AQC（質量基礎設施平臺），我司在質量自動化管控方面還存在一定短板，因此后續我們考慮構建我們自己的質量協作平臺“息壤”，將CloudEngine、RAP、JMeter等流程串接起來實現質量管控的自動化管理。

取名息壤的意思是：這是一塊能自己生長的土壤，元數據（如接口定義）錄入后，隨著產品迭代，它能自己慢慢生長，自動化單元測試，測試用例自動化執行，場景自動回歸，日檢等等。

總結

云縱是一個篤信工程師文化的公司，我們崇尚依靠技術（及自動化）而不是依靠線下流程（注：為了避免網友誤會，此流程特指線下人工流程）和管理解決問題。

我們的體系架構宏大，我們持續投入資源（注：日常20%～30%的研發資源），雖然此體系絕非一朝一夕所能完成，但是我們秉承平凡人可做非凡事和日拱一卒功不唐捐的理念，一群信仰技術的工程師邊開飛機邊換引擎，我們終會有實現宏偉藍圖的那一天。

參考資源：

1，2018，#研發解決方案#異地多活讓商戶無感知；

2，2017，輕舟已過萬重山——真正的技術派公司是怎么聯調、測試和發布的？；

3，2016，私有云的難處—為什么需要CloudEngine？；

4，2016，#研發解決方案#研發協作平臺CloudEngine；

-EOF-

/*敬請關注我的公眾號：老兵筆記*/