歡迎光臨
每天分享高質量文章

有贊是如何高效管理自己的開發測試環境的?

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

有贊從最早到現在一共有過 Dev(已廢棄),Daily,QA,Perf,Pre 等 5 套環境,其中 Perf 環境,是專門用來做效能測試的:


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

剛才我們講了有贊環境的歷程,提到了 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 訪問 essay-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,為此我們做了 CI/CD 平臺幫助我們更高效的進行日常專案管理。環境的穩定,與持續交付的推動是緊密聯絡的,標準規範方便使用的穩定環境是持續交付的基礎。

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


五、個中得失感悟

到了這裡有贊環境方面的分享差不多就結束了,因為有贊的歷史包袱複雜性,導致我們的環境相對複雜,從接手環境治理到取得階段性結果,差不多半年時間。期間處理遇到很多的環境問題,也走了不少彎路,一點一滴的經驗都是寶貴的。環境問題在大多數公司都是一個頭痛的問題,所以很多時候心態上需要心平氣和,遇到問題大家一起解決也是獲得成長和友誼的過程。特別感謝運維和框架的兄弟們特別多的幫助和付出,有你有贊!
本文轉載自公眾號: 有贊coder,點選檢視原文

基於Kubernetes的DevOps實踐培訓

基於Kubernetes的DevOps實踐培訓將於2018年8月24日在北京開課,3天時間帶你係統掌握Kubernetes本次培訓包括:容器特性、映象、網路;Kubernetes架構、核心元件、基本功能;Kubernetes設計理念、架構設計、基本功能、常用物件、設計原則;Kubernetes的資料庫、執行時、網路、外掛已經落地經驗;微服務架構、元件、監控方案等,點選下方圖片檢視詳情。

贊(0)

分享創造快樂