有贊是如何高效管理本身的開發測試環境的？

環境對於一個迭代迅速的電商公司來講，它的重要性無須贅述了；如何讓環境高效，知足多項目併發對環境的需求，節約環境機器成本，創建環境標準體系，這不是幾我的的事情，而是框架組、運維組、開發、測試、PM 你們共同努力的結果，其中的過程也不是一路順風的，有贊在這條路上走過了不少坑，今天就給你們分享下咱們的經驗。 1、有贊測試環境背景歷程

有贊從最先到如今一共有過 Dev（已廢棄），Daily，QA，Perf，Pre 等 5 套環境，其中 Perf 環境，是專門用來作性能測試的：

2、有贊測試環境多環境實現原理

剛纔咱們講了有贊環境的歷程，提到了 SC 多環境方案，想必你們關注到了，如今就開始講下 SC 多環境的解決方案。 有贊 SC 應用隔離解決方案是由框架組提出的解決方案，產生的背景是爲了解決項目並行，你們搶佔資源，開發 5 分鐘，聯調測試 1 小時的問題。 1）全鏈路標識透傳弱隔離方案 全鏈路標識透傳 Service Chain，簡稱 SC 方案，是一種弱隔離的環境方案，簡單分析下兩種主要的隔離方案：

兩種隔離方案優缺點分明： 強隔離：優勢，隔離性強，不用修改應用，對應用侵入性低；缺點，運維成本高 弱隔離：優勢，全鏈路標識透傳，下降沒必要要的運維機器成本；缺點，隔離性弱，對應用侵入性高 最終咱們選擇了弱隔離，緣由是有贊業務發展形態決定的。有贊零售等垂直業務的崛起，而垂直業務依賴了絕大多數的底層應用服務，爲了下降運維服務器成本，因此咱們選擇了弱隔離。 框架設計這個方案最初設定了 4 個目標：

1. 按需隔離應用，只須要隔離需求中有變動的應用

2. 全鏈路標識透傳，爲之後的全鏈路壓測打下基礎

3. 應用侵入低，更多的由應用框架和中間件來感知和擔保，應用自身作到低侵入

4. 使用方便快捷，經過平臺（基礎保障平臺）建立隔離的 SC（Service Chain）環境

最初的全鏈路設計方案：

面那條線咱們稱爲「基礎環境」鏈路，下面那條線咱們稱爲「SC 環境」鏈路，當標識透傳到下一個服務的時候，若是沒有找到對應 sc 應用節點，會默認走標準環境，若是有對應的節點，走 sc 環境的應用節點，整個過程 SC 標識從一開始的 Web 端 http 請求傳入，就一直透傳下去。 此外還會遇到一些重要的細節點，好比消息 NSQ 中間件，咱們也作了隔離標識透傳設計方案：

好比業務代碼異步調用標識透傳問題，能夠自行定製 Runnable 或者定製線程池再或者業務方自行定製實現。 2）Service Chain 路由 全鏈路標識透傳，那就要求入口發起的請求，不管是哪一種業務應用或者何種協議，何種框架，都必須將源端的 SC 標識透傳下去，若是其中任何一個環節標識透傳失敗，就沒有意義了；這裏主要講下兩種主要協議的標識透傳： 第一種，RPC 調用。 首先應用框架層面改造，實現 RPC SC 路由，再經過 Web 發佈平臺將應用帶有 SC 標識服務信息寫入 etcd，這樣 RPC 調用的時候直接經過 RPC 路由將 SC 標識進行透傳，若是沒有匹配到 SC 標識，默認走到基礎鏈路服務，RPC 路由實現原理以下：

第二種，REST調用。 規定 rest 調用必須經過域名調用，規範統一的域名命名方式，好比應用 A 提供 rest 調用，這樣命名：http://A.qa.xxx.com:port/。 儘可能作到命名簡單統一規範，再經過 Web 發佈平臺將應用帶有 SC 標識的 rest 服務信息寫入到 etcd；接下來很重要的一步，實現 rest sc 路由，作法是部署一臺專門幹這個活的機器, 這裏稱爲 sc-nginx0 機器；rest 經過域名調用都會走到 sc-nginx0，sc-nignx0 再經過 Nginx 配置作全應用名稱模糊匹配，從而轉發到對應的應用 rest sc 服務節點，這樣就實現了 rest 調用標識透傳。須要注意的是若是路由不上，會走到兜底的 sc-nginx1 機器，sc-nginx1 會路由基礎鏈路服務。鏈路圖以下：

這裏再給你們展現下，有讚的標識透傳表現形式，僅供參考：

3）Service Chain 入口 前面講了 SC 的總體和路由，sc 標識到底是怎麼傳遞進來的呢，那就天然要講 SC 入口了。 有贊業務業務入口，絕大多數是在 Iron 工程，由於歷史包袱這是一個至關複雜冗餘的 PHP 工程。後來隨着業務發展，咱們將部分業務入口從 Iron 代碼剝離出來，造成一個個獨立的前端是 Node 的微服務，簡單分別講下兩種不一樣的入口實現 SC 方式。 第一種，Iron 入口。 首先針對不一樣的環境，本地須要綁定 host，域名須要接入統一網關，接着經過 Web 代理頁面，給瀏覽器 http 訪問 header 頭帶上 Iron 訪問多人路徑名 who 信息、SC 標識信息必要信息，最後在代理頁面選擇入口機器（ps：多人 Iron 機器），就能夠開始 SC 調用之旅了；Iron 服務咱們不一樣環境只有一臺服務，在機器上創建多人路徑名，經過 who 信息由 Tengine 走到各自的路徑 Iron 代碼，這樣咱們就解決了 Iron 入口的問題；接下來 Iron 調其餘服務，會經過 rest 請求，前面咱們有講過 rest 調用的路由，咱們在代理頁面已經將 SC 標識帶入了，因此 SC 標識會接着日後面透傳了。絕大多數 Iron 調用服務化服務都是經過 rest 調用的，可是 Iron 複雜在歷史有些業務還經過了 rpc（nova） 調用，咱們經過改造 tether 中間件給與了 SC 標識透傳支持，這裏有贊特點特別鮮明就不過多介紹了；這裏還有一些 PHP 比較複雜的 Nginx，Tengine 代理也不講了，有一樣背景且感興趣的夥伴能夠私下交流。 第二種，Node 入口。 Node 入口，相似於前面介紹過的 rest 調用路由，須要申請瀏覽器訪問的外部域名，同時外部域名要確保接入統一網關；再經過 Web 發佈平臺將帶有 SC 的外部域名 rest 信息寫入到 etcd，咱們經過瀏覽器域名訪問的時候，入口經過 Web 代理頁面選擇 sc-nginx 路由機器，SC 路由機器會轉到對應的 sc node 服務，這樣就解決了 Node 入口的問題。 最後爲了下降環境使用成本，咱們入口作了統一，將測試環境老的多人 Iron 入口使用姿式也改爲了 sc-nginx 入口，同時兼容了多人 Iron 的訪問實現；由於有贊鮮明特點很少說了，僅供參考，鏈路方案以下：

4）Service Chain 出口 對於內部業務來講，沒有 SC 出口一說，這裏說的出口是指外部三方的調用。三方調用支持 SC 分爲兩種，一種是同步查詢只要對接的第三方應用支持 SC 標識就能夠了；還有一種是異步回調，能夠經過給三方傳回調地址加入 SC 標識實現，內部應用獲取回到 url 的 SC 信息，這樣能夠實現 SC 標識涉及第三方透傳，這種方法大多數狀況下三方都是能夠支持的。 至此 Service Chain 環境隔離技術層面的方案差很少這樣了。

3、有贊環境推進

上一個環節已經大體的介紹了有贊 Service Chain 全鏈路標識透傳隔離方案的技術實現，這個環節開始介紹咱們在肯定技術實現方案以後，作的一些列推進的措施。 1）推進應用框架升級接入SC 前面咱們說了 RPC 調用是經過框架實現 sc 路由的，因此推進應用框架、NSQ 客戶端升級，這一步很是重要；由於不少業務鏈路很長，若是某些業務線沒有升級，整個 SC 鏈路就會卡在某個應用無法透傳標識；這點在一開始的時候，咱們沒有作好，由於前期的宣傳力度不夠，推進不足，致使有些業務線接入 SC 升級比較快，有些業務線至關滯後，項目試點以後才發現還不支持 SC，給後面的試點帶來了很大的阻力和困難；因此建議，若是一旦肯定好適合本身的隔離方案以後，開始推進的時候，作好充分的準備，定好時間，並指定各業務線的跟進 owner。 2）推進應用接入配置平臺 由於常常會發現某個應用由於環境依賴的基礎服務配置不對，致使應用的測試環境服務各類問題，排查的時候要去 code 裏看配置，很是的耗時與不便；因此爲了方便管理應用環境配置，咱們作了應用配置平臺，推進應用平臺配置化，把一些基礎的配置模板固化，這樣咱們環境配置的問題基本就能解決了。

3）推進基礎環境整治 這一步很是核心，由於只有基礎環境穩定，大的測試環境纔會穩定。核心是維護基礎環境服務，下掉多餘的基礎環境機器（ps：服務不帶標識信息的機器）及服務，基礎環境的應用服務只保留一個，這樣保證了咱們基礎環境服務鏈路簡單清晰，方便了問題定位，也方便控制基礎環境發佈權限。還能夠從如下幾點考慮來治理基礎環境：1，測試環境基礎鏈路服務發佈權限管控，只容許發佈 master 代碼，不容許輕易發佈，保證基礎鏈路服務穩定；2，基礎鏈路服務當天生產環境有代碼變動，凌晨自動更新 master 代碼等。 4）Web 應用發佈管理平臺 前面有說過，SC 應用服務信息寫入 etcd，是經過 Web 發佈平臺，因此咱們須要一個方便便捷的 SC 環境應用發佈管理平臺。 建立 SC 環境：

SC 環境應用管理：

這裏值得一提的是，SC 服務的機器能夠申請虛擬機，也能夠用 Docker，從成本而言，咱們默認是使用更加節約成本的 Docker。 5）推進項目試點 在準備工做作好以後，能夠選試點項目試行了，由於環境方案問題的複雜性，建議不要一開始就推行全公司，能夠找一些項目先作試點；在試點的過程當中，咱們會發現各類明顯坑，等把這些明顯的坑解決一圈以後，再推全公司實行。 6）共性問題解決方案跟進 共性問題有哪些，好比有提到過的測試環境調用第三方支持 SC、卡門支持 SC 等等，在環境使用的過程當中，會遇到你們都會遇到的問題，這類問題影響是大範圍的，那就必須拉羣及時跟進響應解決，若是不能及時解決就會下降你們使用推進環境優化的積極性；處理完問題，須要及時總結記錄，大的問題還要及時通知，以及在培訓過程當中給你們舉例講解；有贊在環境推進的過程當中，咱們大大小小的建了 40 多個問題跟進的羣，制定了 10 多個共性問題解決方法，這些方案有着很鮮明的我廠特點，這裏就不給你們分享了。 7）環境基礎保障 測試環境使用的便捷穩定，必然會要求咱們作一些環境基礎保障的工做，好比開發測試環境數據 mock 平臺、服務監控平臺。 環境數據 mock 平臺---測試團隊目前開發覆蓋了包括大數據，交易，支付等 14 塊業務 mock 場景，大大提高了測試環境的高效便捷；好比測試環境有些特殊的場景是須要數據構造的，店鋪沒錢了，e卡支付帳號沒錢了，添加店鋪管理員等，均可以經過測試平臺本身實現。

基礎環境服務監控平臺---測試環境基礎環境鏈路的服務穩定直接影響了環境的穩定性，若是基礎環境服務異常，會影響到全部人測試環境使用，爲此開發了環境服務監控平臺，覆蓋了 Daily、QA、Pre 90% 以上的核心應用的服務；每隔 10 分鐘監測一次 etcd 應用的 Dubbo 服務，一但發現某環境服務異常，就會給應用的測試角色發送郵件告警、以及內部工具告警，測試童鞋收到服務異常告警，及時處理，避免測試環境服務長時間影響你們使用。

服務異常告警：

環境監控平臺很是重要，我作過統計，環境問題至少下降 70% 以上，提高環境排查解決效率至少 80%，不少時候服務異常了咱們第一時間就解決了，避免了你們感知，還有其餘的一些環境保障的工具這裏就很少說了。 8）環境方案規範制定 對於環境使用者來講，不少時候他可能不須要詳細瞭解環境隔離方案的實現，更多時候比較關心環境究竟怎麼使用。因此在方案以後，咱們須要制定環境使用規範，有贊針對入口變化，先後制定過兩個版本的使用規範 ppt，大體的內容以下：有贊環境介紹，應用接入 SC 規範，環境使用規範，測試環境交付規範，移動端使用規範，環境保障，環境發佈權限規則，不少內容在前面也都講過了。 9）環境培訓 有了環境方案規範以後，對於一個已超過 600 技術人員的公司來講，還須要經過一系列的環境培訓，這樣才能確保每一個人都知道如何作如何使用。在有贊是經過各業務線組一個個宣講進行的，還有新人入職技術大學培訓，先後組織了接近 20 場培訓，除此以外還反覆強調老人要幫扶指導新來的童鞋環境的使用，經過這些努力才能保證絕大多數人知道怎麼使用環境。 10）環境故障定級 在咱們作了大量的培訓、宣導以後，仍是會有童鞋將測試環境基礎環境服務弄出問題，這是很難避免的，畢竟使用的人多，你們對環境的學習理解程度又不同。對於這種狀況就須要制定懲罰措施了，給環境故障定級，分爲 p1（影響阻塞基礎環境主鏈路的故障），p2（影響非主鏈路或者非基礎環境的故障），對於故障多的業務組，予以通報tl。 11）環境問題記錄 環境的問題各式各樣，多而繁雜，須要組織專門的老司機，負責排查環境問題，尤爲在當下微服務愈來愈細化的背景下，一個環境問題出現了，須要查好幾個業務線N個應用，這是很大的工做量。因此環境問題顯得很是必要了，有了環境問題記錄，當咱們再遇到相似的問題的時候，咱們能夠有經驗知道怎麼快速定位問題以及解決。 環境推進方面大體這些，每一個公司都會有本身的制度，主要是但願能夠給你們借鑑。 4、有贊環境與持續交付

有贊 2018 年提高研發效率，很重要的一個動做就是 DevOps，爲此咱們作了 CI/CD 平臺幫助咱們更高效的進行平常項目管理。環境的穩定，與持續交付的推進是緊密聯繫的，標準規範方便使用的穩定環境是持續交付的基礎。

項目的發起從 Daily（開發）環境發起，開發完成 Daily 環境的冒煙自測以後交付到 QA 環境，測試童鞋 QA 環境完成測試以後交付到 Pre 預發環境，預發驗收以後就能夠發佈上線，這是一個完整的項目生命週期，開發和測試環境的隔離，可使得項目進行的更加順利。 舉例說明，xx 項目是一個很是大的項目，涉及到的業務方 7，8 個，涉及的應用 60 多個，若是測試和開發童鞋都在 QA 的 SC 環境測試，那麼會出現測試在測試的同時開發修復 bug 重發服務，從而打斷測試的狀況，這樣的大項目就沒有辦法進行下去了。若是按照交付的思路，開發在 Daily 環境完成自測，交付 QA 測試，你們互不影響，能夠很好的提高項目效率。 經過 Web 平臺，目前準備一個隔離的複雜的項目環境基本上能夠控制在半個小時內。咱們還有很大的提高空間，好比在 Docker 容器服務化上還能夠作不少改進，和 CI/CD 結合以後，整個項目的生命週期過程實現自動化。

5、箇中得失感悟

到了這裏有贊環境方面的分享差很少就結束了，由於有讚的歷史包袱複雜性，致使咱們的環境相對複雜，從接手環境治理到取得階段性結果，差很少半年時間。期間處理遇到不少的環境問題，也走了很多彎路，一點一滴的經驗都是寶貴的。環境問題在大多數公司都是一個頭痛的問題，因此不少時候心態上須要心平氣和，遇到問題你們一塊兒解決也是得到成長和友誼的過程。特別感謝運維和框架的兄弟們特別多的幫助和付出，有你有贊！ 本文轉載自公衆號： 有贊coder， 點擊查看原文。