如何進(jìn)行基于.net的微服務(wù)架構(gòu)下的開發(fā)測試環(huán)境運(yùn)維的實(shí)踐

如何進(jìn)行基于.net的微服務(wù)架構(gòu)下的開發(fā)測試環(huán)境運(yùn)維的實(shí)踐，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細(xì)講解，有這方面需求的人可以來學(xué)習(xí)下，希望你能有所收獲。

 眼下，做互聯(lián)網(wǎng)應(yīng)用，最火的架構(gòu)是微服務(wù)，最熱的研發(fā)管理就是DevOps， 沒有之一。微服務(wù)、DevOps已經(jīng)被大量應(yīng)用，它們已經(jīng)像傳說中的那樣，可以無所不能。特來電云平臺，通過近兩年多的實(shí)踐，發(fā)現(xiàn)完全不像大家說的那樣簡單，大家是報(bào)喜不報(bào)憂，實(shí)在是水太深，誰做誰知道。今天就與大家分享一下在微服務(wù)架構(gòu)+DevOps下，開發(fā)測試環(huán)境的一些運(yùn)維痛點(diǎn)問題和解決方法。

      架構(gòu)的復(fù)雜度直接決定了運(yùn)維的工作量，架構(gòu)不是越復(fù)雜越好，而是適合最好。下面簡單說說幾種架構(gòu)的優(yōu)缺點(diǎn)。基于.net在搭建應(yīng)用時，最常用的方法就是采用Asp.net MVC，前端、后端 All in到一個站點(diǎn)中，省時省力，完全不用關(guān)心部署運(yùn)維的復(fù)雜度。但是弊端也非常明顯，所有內(nèi)容部署在一個站點(diǎn)下，如果業(yè)務(wù)復(fù)雜，系統(tǒng)的變化頻率非常高，穩(wěn)定性堪憂，基本無解。再復(fù)雜一些的就是前后端分離：H5（或Winform） + WebAPI，此種架構(gòu)雖然把前后端的變化分開了，但是后端邏輯缺少服用，存在大量公共方法或者重復(fù)代碼。更復(fù)雜的就是：前端+WebAPI+Service，這種模式下雖然抽取了公共服務(wù)，但是部署粒度還是很粗，基本上會按照業(yè)務(wù)范圍分多集群部署。同一個集群下，部署的服務(wù)如果太多，程序集沖突、服務(wù)變更重啟集群影響范圍大等問題依舊是難解的問題。所以為了隔離變化、降低對其他服務(wù)的影響，集群的劃分粒度會越來越小，甚至演變到一個服務(wù)一個集群，這就是微服務(wù)的形態(tài)了。這幾種架構(gòu)模式總結(jié)起來就是水平、垂直兩個維度的變化，水平維度從一類站點(diǎn)變?yōu)榱硕囝愓军c(diǎn)，以解決變化的影響訪問、代碼服用的問題。垂直維度從所有應(yīng)用部署在一個站點(diǎn)中，變化到一個服務(wù)一個集群，隔離變化帶來的影響。架構(gòu)從一個點(diǎn)演變到兩個維度的變化，最終帶來的運(yùn)維成本指數(shù)級的增長。下面是特來電云平臺微服務(wù)架構(gòu)圖，從圖中可以看出，整體架構(gòu)比較復(fù)雜。

      為了支持全國的充電業(yè)務(wù)，特來電云平目前已經(jīng)有近千臺服務(wù)器，應(yīng)用程序100類+，WebAPI接口2000+，服務(wù)接口500+，開發(fā)測試環(huán)境幾十個，僅僅生成環(huán)境每天熱更新就會高達(dá)20次+。20多次的熱更新，都必須經(jīng)過單元測試后，部署到與生產(chǎn)環(huán)境近乎一致的測試環(huán)境中進(jìn)行接口測試、UI測試，然后再在準(zhǔn)生產(chǎn)環(huán)境中進(jìn)行回歸測試，最終才能灰度發(fā)布到兩個數(shù)據(jù)中心。說到這里，大家很可能會想到通過DevOps來規(guī)范環(huán)境的同步：CI完成后，通過CD把產(chǎn)品更新部署到多個環(huán)境進(jìn)行測試，然后發(fā)布到生產(chǎn)環(huán)境。是的，正常情況下，這個流程沒問題，但是現(xiàn)實(shí)非常殘酷。有太多的因素導(dǎo)致測試環(huán)境與生產(chǎn)不一致。下面就簡單說說：

1. .net Framework 無法采用Docker，更新包中不僅僅有程序文件的更新、還有配置的更新、SQL的更新。在如此大的規(guī)模下，人工更新成本高的離譜，基本上需要專崗來做。而人工做，很容易出錯。必須工具化、自動化，補(bǔ)丁更新必須100%通過工具做，不能有人工干預(yù)，否則就會在各個環(huán)境中出現(xiàn)不一致的情況。

2. 系統(tǒng)幾乎每個小時都會發(fā)生一次變化，常見的增減應(yīng)用程序、增減服務(wù)、增減WebAPI，這些信息的變化都會影響系統(tǒng)環(huán)境。只要一個程序、接口、服務(wù)管理不到位，系統(tǒng)就可能會給你顏色看。所有的機(jī)器信息、服務(wù)信息、配置信息必須集中管理維護(hù)，并在各類環(huán)境中實(shí)現(xiàn)自動同步。CMDB是必備的管理系統(tǒng)。

3. 在日常的研發(fā)中，很多需求會涉及到多個產(chǎn)品研發(fā)部門聯(lián)合開發(fā)，集成測試的周期很長，而測試環(huán)境的數(shù)量有限，經(jīng)常出現(xiàn)一些緊急需求沒有測試環(huán)境的尷尬問題。

4. 測試環(huán)境會頻繁的執(zhí)行更新，甚至一個更新會反復(fù)多次，極易導(dǎo)致測試環(huán)境與生產(chǎn)環(huán)境不匹配。從而引起，程序熱更新后存在bug，需要緊急回退。

5. 開發(fā)測試環(huán)境是對每個開發(fā)人員開放的，每個人都會登錄系統(tǒng)Debug。你懂的，只要Debug一次，程序很大幾率就會發(fā)生變化。

6. 一個業(yè)務(wù)可能需要幾個、甚至十幾個程序提供服務(wù)才能正常運(yùn)行，一個環(huán)節(jié)出現(xiàn)問題，整個系統(tǒng)就會出錯。如何快速的分析、排查問題，是個痛苦的問題。這是讓很多人抓狂的問題。

7. 。。。

      在面對如此多的變化時，DevOps變的很理想、很無力。DevOps的落地，需要在不斷的改良中找到平衡點(diǎn)。我們的解決方法是：

• 搭建CMDB系統(tǒng)，管理各類環(huán)境的部署信息。比如：集群信息、進(jìn)程信息、服務(wù)信息、WebAPI信息、配置信息等。并且這些信息的變更要通過系統(tǒng)集中管理，決不允許出現(xiàn)CMDB信息與部署信息不一致的情況。

• 搭建補(bǔ)丁系統(tǒng)。開發(fā)交付包標(biāo)準(zhǔn)化管理。通過補(bǔ)丁制作工具，制作格式化的補(bǔ)丁，通過補(bǔ)丁安裝平臺，實(shí)現(xiàn)補(bǔ)丁包的安裝。系統(tǒng)程序、SQL的變更全部通過補(bǔ)丁平臺進(jìn)行。補(bǔ)丁系統(tǒng)是一個非常復(fù)雜的系統(tǒng)，后續(xù)有機(jī)會再詳細(xì)介紹。

• 搭建模板機(jī)環(huán)境，當(dāng)生產(chǎn)系統(tǒng)更新了補(bǔ)丁或者CMDB信息發(fā)生變化后，通過自動化的工具，主動推送到模板機(jī)中。保證生產(chǎn)環(huán)境與測試環(huán)境的實(shí)時同步。各類測試環(huán)境從模板機(jī)克隆，并通過工具與模板機(jī)定時同步變化。同步完成后，通過自動化測試工具和環(huán)境檢查工具，確定環(huán)境是可用的。

• 開發(fā)全鏈路監(jiān)控系統(tǒng)，并在系統(tǒng)的各個入口處埋點(diǎn)，幫助開發(fā)人員分析系統(tǒng)問題。全鏈路監(jiān)控系統(tǒng)也是一個非常復(fù)雜的系統(tǒng)，后續(xù)有機(jī)會再詳細(xì)介紹。下面是全鏈路的基本原理圖和運(yùn)行效果圖。

      做互聯(lián)網(wǎng)應(yīng)用需要有基因，更需要有填坑的勇氣和毅力，填坑的過程就是攀登技術(shù)高峰的過程，永無止境！

看完上述內(nèi)容是否對您有幫助呢？如果還想對相關(guān)知識有進(jìn)一步的了解或閱讀更多相關(guān)文章，請關(guān)注億速云行業(yè)資訊頻道，感謝您對億速云的支持。