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

????? 架構(gòu)的復(fù)雜度直接決定了運維的工作量，架構(gòu)不是越復(fù)雜越好，而是適合最好。下面簡單說說幾種架構(gòu)的優(yōu)缺點。基于.net在搭建應(yīng)用時，最常用的方法就是采用Asp.net MVC，前端、后端 All in到一個站點中，省時省力，完全不用關(guān)心部署運維的復(fù)雜度。但是弊端也非常明顯，所有內(nèi)容部署在一個站點下，如果業(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é)起來就是水平、垂直兩個維度的變化，水平維度從一類站點變?yōu)榱硕囝愓军c，以解決變化的影響訪問、代碼服用的問題。垂直維度從所有應(yīng)用部署在一個站點中，變化到一個服務(wù)一個集群，隔離變化帶來的影響。架構(gòu)從一個點演變到兩個維度的變化，最終帶來的運維成本指數(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)實非常殘酷。有太多的因素導(dǎo)致測試環(huán)境與生產(chǎn)不一致。下面就簡單說說：

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

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

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

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

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

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

。。。

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

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

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

• 搭建模板機環(huán)境，當(dāng)生產(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)也是一個非常復(fù)雜的系統(tǒng)，后續(xù)有機會再詳細(xì)介紹。下面是全鏈路的基本原理圖和運行效果圖。

????? 做互聯(lián)網(wǎng)應(yīng)用需要有基因，更需要有填坑的勇氣和毅力，填坑的過程就是攀登技術(shù)高峰的過程，永無止境！本文也僅僅是從架構(gòu)的方面給大家分享，不過內(nèi)容全部已經(jīng)落地，沒有吹NB的意思。希望這個技術(shù)分享能對大家有用！

相關(guān)文章

• 谷歌發(fā)布的首款基于HTTP/2和protobuf的RPC框架：GRPC
  

• 擁抱.NET Core，跨平臺的輕量級RPC：Rabbit.Rpc

• 基于DotNet Core的RPC框架(一) DotBPE.RPC快速開始

• 基于.NET CORE微服務(wù)框架 -surging的介紹和簡單示例 （開源）

• 剝析surging的架構(gòu)思想

• 基于.NET CORE微服務(wù)框架 -談?wù)剆urging的服務(wù)容錯降級

• 我眼中的ASP.NET Core之微服務(wù)

• .NET Core 事件總線,分布式事務(wù)解決方案：CAP

• CAP 介紹及使用【視頻】
  

原文地址：http://www.cnblogs.com/vveiliang/p/7264397.html

---

.NET社區(qū)新聞，深度好文，微信中搜索dotNET跨平臺或掃描二維碼關(guān)注

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

以上是生活随笔為你收集整理的基于.net的微服务架构下的开发测试环境运维实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。