環境對於一個迭代迅速的電商公司來說，它的重要性無須贅述了；如何讓環境高效，滿足多專案併發對環境的需求，節約環境機器成本，建立環境標準體系，這不是幾個人的事情，而是框架組、運維組、開發、測試、pm 大家共同努力的結果，其中的過程也不是一帆風順的，有贊在這條路上走過了很多坑，今天就給大家分享下我們的經驗。
一、有贊測試環境背景歷程
有贊從最早到現在一共有過 dev（已廢棄），daily，qa，perf，pre5 套環境，其中 perf 環境，是專門用來做效能測試的。
二、有贊測試環境多環境實現原理
剛才我們講了有贊環境的歷程，提到了 sc 多環境方案，想必大家關注到了，現在就開始講下 sc 多環境的解決方案。 有贊 sc 應用隔離解決方案是由框架組提出的解決方案，產生的背景是為了解決專案並行，大家搶佔資源，開發5分鐘，聯調測試1小時的問題。
1）全鏈路標識透傳弱隔離方案
全鏈路標識透傳 service chain，簡稱 sc 方案，是一種弱隔離的環境方案，簡單分析下兩種主要的隔離方案：
兩種隔離方案優缺點分明：
強隔離：優點，隔離性強，不用修改應用，對應用侵入性低；缺點，運維成本高。
弱隔離：優點，全鏈路標識透傳，降低不必要的運維機器成本；缺點，隔離性弱，對應用侵入性高。
最終我們選擇了弱隔離，原因是有贊業務發展形態決定的。有贊零售等垂直業務的崛起，而垂直業務依賴了絕大多數的底層應用服務，為了降低運維伺服器成本，所以我們選擇了弱隔離。
框架設計這個方案最初設定了 4 個目標：
a.按需隔離應用，只需要隔離需求中有變更的應用；
b.全鏈路標識透傳，為以後的全鏈路壓測打下基礎；
c.應用侵入低，更多的由應用框架和中介軟體來感知和擔保，應用自身做到低侵入；
d.使用方便快捷，通過平臺（基礎保障平臺）建立隔離的 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 環境隔離技術層面的方案差不多這樣了。
三、有贊環境推動
上一個環節已經大致的介紹了有贊 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個應用，這是很大的工作量。所以環境問題顯得非常必要了，有了環境問題記錄，當我們再遇到類似的問題的時候，我們可以有經驗知道怎麼快速定位問題以及解決。
環境推動方面大致這些，每個公司都會有自己的制度，主要是希望可以給大家借鑑。
四、有贊環境與持續交付
有贊2018年提升研發效率，很重要的一個動作就是 devops，為此我們做了 CICD 平臺幫助我們更高效的進行日常專案管理。環境的穩定，與持續交付的推動是緊密聯絡的，標準規範方便使用的穩定環境是持續交付的基礎。
專案的發起從 daily（開發）環境發起，開發完成 daily 環境的冒煙自測之後交付到 qa 環境，測試童鞋 qa 環境完成測試之後交付到 pre 預發環境，預發驗收之後就可以釋出上線，這是一個完整的專案生命週期，開發和測試環境的隔離，可以使得專案進行的更加順利。
舉例說明，xx專案是一個非常大的專案，涉及到的業務方 7，8個，涉及的應用 60 多個，如果測試和開發童鞋都在 qa 的 sc 環境測試，那麼會出現測試在測試的同時開發修復 bug 重發服務，從而打斷測試的情況，這樣的大專案就沒有辦法進行下去了。如果按照交付的思路，開發在 daily 環境完成自測，交付 qa 測試，大家互不影響，可以很好的提升專案效率。
通過 web 平臺，目前準備一個隔離的複雜的專案環境基本上可以控制在半個小時內。我們還有很大的提升空間，比如在 docker 容器服務化上還可以做很多改進，和CICD 結合之後，整個專案的生命週期過程實現自動化。
五、箇中得失感悟
到了這裡有贊環境方便的分享差不多就結束了，因為有讚的歷史包袱複雜性，導致我們的環境相對複雜，從接手環境治理到取得階段性結果，差不多半年時間。期間處理遇到很多的環境問題，也走了不少彎路，一點一滴的經驗都是寶貴的。環境問題在大多數公司都是一個頭痛的問題，所以很多時候心態上需要心平氣和，遇到問題大家一起解決也是獲得成長和友誼的過程。特別感謝運維和框架的兄弟們特別多的幫助和付出，有你有贊！
ps： 有贊技術團隊持續招人，大量崗位空缺，有意向換工作的同學可以發簡歷到我的個人郵箱：gongyuan@youzan.com，也可以微信交流：JasonV9。
