眼下，做網際網路應用，最火的架構是微服務，最熱的研發管理就是DevOps， 沒有之一。微服務、DevOps已經被大量應用，它們已經像傳說中的那樣，可以無所不能。特來電雲平台，通過近兩年多的實踐，發現完全不像大家說的那樣簡單，大家是報喜不報憂，實在是水太深，誰做誰知道。今天就與大家分享一下在微服務架構+DevOps下，開發測試環境的一些運維痛點問題和解決方法。
架構的複雜度直接決定了運維的工作量，架構不是越複雜越好，而是适合最好。下面簡單說說幾種架構的優缺點。基于.net在搭建應用時，最常用的方法就是采用Asp.net MVC，前端、後端 All in到一個站點中，省時省力，完全不用關心部署運維的複雜度。但是弊端也非常明顯，所有内容部署在一個站點下，如果業務複雜，系統的變化頻率非常高，穩定性堪憂，基本無解。再複雜一些的就是前後端分離：H5（或Winform） + WebAPI，此種架構雖然把前後端的變化分開了，但是後端邏輯缺少複用，存在大量公共方法或者重複代碼。更複雜的就是：前端+WebAPI+Service，這種模式下雖然抽取了公共服務，但是部署粒度還是很粗，基本上會按照業務範圍分多叢集部署。同一個叢集下，部署的服務如果太多，程式集沖突、服務變更重新開機叢集影響範圍大等問題依舊是難解的問題。是以為了隔離變化、降低對其他服務的影響，叢集的劃分粒度會越來越小，甚至演變到一個服務一個叢集，這就是微服務的形态了。這幾種架構模式總結起來就是水準、垂直兩個次元的變化，水準次元從一類站點變為了多類站點，以解決變化的影響通路、代碼複用的問題。垂直次元從所有應用部署在一個站點中，變化到一個服務一個叢集，隔離變化帶來的影響。架構從一個點演變到兩個次元的變化，最終帶來的運維成本指數級的增長。下面是特來電雲平台微服務架構圖，從圖中可以看出，整體架構比較複雜。
- .net Framework 無法采用Docker，更新包中不僅僅有程式檔案的更新、還有配置的更新、SQL的更新。在如此大的規模下，人工更新成本高的離譜，基本上需要專崗來做。而人工做，很容易出錯。必須工具化、自動化，更新檔更新必須100%通過工具做，不能有人工幹預，否則就會在各個環境中出現不一緻的情況。
- 系統幾乎每個小時都會發生一次變化，常見的增減應用程式、增減服務、增減WebAPI，這些資訊的變化都會影響系統環境。隻要一個程式、接口、服務管理不到位，系統就可能會給你顔色看。所有的機器資訊、服務資訊、配置資訊必須集中管理維護，并在各類環境中實作自動同步。CMDB是必備的管理系統。
- 在日常的研發中，很多需求會涉及到多個産品研發部門聯合開發，內建測試的周期很長，而測試環境的數量有限，經常出現一些緊急需求沒有測試環境的尴尬問題。
- 測試環境會頻繁的執行更新，甚至一個更新會反複多次，極易導緻測試環境與生産環境不比對。進而引起，程式熱更新後存在bug，需要緊急回退。
- 開發測試環境是對每個開發人員開放的，每個人都會登入系統Debug。你懂的，隻要Debug一次，程式很大幾率就會發生變化。
- 一個業務可能需要幾個、甚至十幾個程式提供服務才能正常運作，一個環節出現問題，整個系統就會出錯。如何快速的分析、排查問題，是個痛苦的問題。這是讓很多人抓狂的問題。
- 。。。
在面對如此多的變化時，DevOps變的很理想、很無力。DevOps的落地，需要在不斷的改良中找到平衡點。我們的解決方法是：
- 搭建CMDB系統，管理各類環境的部署資訊。比如：叢集資訊、程序資訊、服務資訊、WebAPI資訊、配置資訊等。并且這些資訊的變更要通過系統集中管理，決不允許出現CMDB資訊與部署資訊不一緻的情況。
- 搭建更新檔系統。開發傳遞包标準化管理。通過更新檔制作工具，制作格式化的更新檔，通過更新檔安裝平台，實作更新檔包的安裝。系統程式、SQL的變更全部通過更新檔平台進行。更新檔系統是一個非常複雜的系統，後續有機會再詳細介紹。
- 搭模組化闆機環境，當生産系統更新了更新檔或者CMDB資訊發生變化後，通過自動化的工具，主動推送到模闆機中。保證生産環境與測試環境的實時同步。各類測試環境從模闆機克隆，并通過工具與模闆機定時同步變化。同步完成後，通過自動化測試工具和環境檢查工具，确定環境是可用的。
- 開發全鍊路監控系統，并在系統的各個入口處埋點，幫助開發人員分析系統問題。全鍊路監控系統也是一個非常複雜的系統，後續有機會再詳細介紹。下面是全鍊路的基本原理圖和運作效果圖。
做網際網路應用需要有基因，更需要有填坑的勇氣和毅力，填坑的過程就是攀登技術高峰的過程，永無止境！本文也僅僅是從架構的方面給大家分享，不過内容全部已經落地，沒有吹NB的意思。希望這個技術分享能對大家有用！