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

成都創(chuàng)新互聯(lián)專注于企業(yè)營銷型網(wǎng)站建設、網(wǎng)站重做改版、阿圖什網(wǎng)站定制設計、自適應品牌網(wǎng)站建設、H5頁面制作、商城網(wǎng)站制作、集團公司官網(wǎng)建設、外貿(mào)網(wǎng)站制作、高端網(wǎng)站制作、響應式網(wǎng)頁設計等建站業(yè)務，價格優(yōu)惠性價比高，為阿圖什等各大城市提供網(wǎng)站開發(fā)制作服務。

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

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

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

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

2. 系統(tǒng)幾乎每個小時都會發(fā)生一次變化，常見的增減應用程序、增減服務、增減WebAPI，這些信息的變化都會影響系統(tǒng)環(huán)境。只要一個程序、接口、服務管理不到位，系統(tǒng)就可能會給你顏色看。所有的機器信息、服務信息、配置信息必須集中管理維護，并在各類環(huán)境中實現(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í)行更新，甚至一個更新會反復多次，極易導致測試環(huán)境與生產(chǎn)環(huán)境不匹配。從而引起，程序熱更新后存在bug，需要緊急回退。

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

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

7. 。。。

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

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

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

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

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

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

看完上述內(nèi)容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝您對創(chuàng)新互聯(lián)的支持。

本文題目：如何進行基于.net的微服務架構(gòu)下的開發(fā)測試環(huán)境運維的實踐
文章分享：http://chinadenli.net/article22/pgjijc.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站設計、軟件開發(fā)、網(wǎng)站排名、服務器托管、營銷型網(wǎng)站建設、關鍵詞優(yōu)化

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)