1

微服務(wù)指的是技術(shù)層面的服務(wù)細(xì)化，并不是業(yè)務(wù)層面的變革。

我們提供的服務(wù)有：成都網(wǎng)站制作、網(wǎng)站設(shè)計(jì)、外貿(mào)網(wǎng)站建設(shè)、微信公眾號開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認(rèn)證、德江ssl等。為近千家企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務(wù)，是有科學(xué)管理、有技術(shù)的德江網(wǎng)站制作公司

所以，測試微服務(wù)應(yīng)用程序與測試使用任何其他體系結(jié)構(gòu)構(gòu)建的應(yīng)用程序沒有什么不同，原來的那套測試?yán)碚摚€是適用的。

我們暫時(shí)把微服務(wù)看成是一個(gè)較大體系的“黑盒”，因?yàn)闃I(yè)務(wù)上沒有變化，所以我們原來熟悉的等價(jià)類、場景法、探索性測試等測試策略還是可以照樣執(zhí)行，沒有太多需要做出改變的，因?yàn)闃I(yè)務(wù)沒有太大的變化。需要注意的是，基于風(fēng)險(xiǎn)的測試策略可能會發(fā)生一些變化，因?yàn)轱L(fēng)險(xiǎn)因素變多了，需要考慮的影響因子變多，風(fēng)險(xiǎn)分析、評估需要考量更多的內(nèi)容而已。

02

好了，我們現(xiàn)在再把“黑盒”打開，看看微服務(wù)的技術(shù)架構(gòu)給測試帶來了哪些新的風(fēng)險(xiǎn)。我們需要針對這些新的挑戰(zhàn)做出一些不一樣的策略。

微服務(wù)的穩(wěn)定性：在單體架構(gòu)中，業(yè)務(wù)的封裝調(diào)用是基于函數(shù)來進(jìn)行的，幾乎不存在調(diào)用失敗的情況。也不會存在版本不致的情況（都在一套代碼內(nèi)）。但是拆成微服務(wù)后，就會面臨兩個(gè)問題。

第一，服務(wù)依賴得不可控：因?yàn)槲⒎?wù)都是可以被獨(dú)立部署的，那么部署的版本就會變得不可控，那就意味著可能你調(diào)用的接口版本會發(fā)生變化，導(dǎo)致調(diào)用失敗（這類問題會在下次的文章中重點(diǎn)介紹，契約測試是個(gè)不錯(cuò)的解決方案）。

第二，連接調(diào)用存在失敗風(fēng)險(xiǎn)：微服務(wù)之間的通信要么基于Rest，要么基于RPC，都會有可能因?yàn)榫W(wǎng)絡(luò)波動導(dǎo)致調(diào)用失敗，從而引發(fā)業(yè)務(wù)問題。

針對這個(gè)問題，通常采用的策略做好微服務(wù)的版本管理，在調(diào)用鏈路上配置版本依賴關(guān)系，做到環(huán)境的復(fù)用。如果做不到，那就從物理上做隔離即可，盡可能縮小影響范圍。

微服務(wù)的可用性：在單體構(gòu)架中，代碼的可用性依賴于整體的性能表現(xiàn)，如果某個(gè)代碼段出現(xiàn)性能問題，會影響整體的業(yè)務(wù)表現(xiàn)，比較容易被發(fā)現(xiàn)。但是在微服務(wù)中，我們無法有效地獲取其他微服務(wù)的運(yùn)行狀態(tài)，這就需要有統(tǒng)一的組件來管理，通常情況下是Hystrix與Sentinel（當(dāng)然還有其他的選擇，看團(tuán)隊(duì)的技術(shù)選型）。處理的方式有兩種：熔斷、降級。

熔斷指的是當(dāng)下游的服務(wù)因?yàn)槟撤N原因突然變得不可用或響應(yīng)過慢，上游服務(wù)為了保證自己整體服務(wù)的可用性，不再繼續(xù)調(diào)用目標(biāo)服務(wù)，直接返回，快速釋放資源。如果目標(biāo)服務(wù)情況好轉(zhuǎn)則恢復(fù)調(diào)用。

降級指的是：服務(wù)主動停掉一些不太重要的業(yè)務(wù)，釋放出服務(wù)器資源，增加響應(yīng)速度。

針對這個(gè)問題，測試策略主要集中在機(jī)制的配置與生效驗(yàn)證上，如何保障配置的熔斷降級機(jī)制能夠有效，是測試的重點(diǎn)和難點(diǎn)。一般會通過性能壓測來模擬。

數(shù)據(jù)一致性問題：當(dāng)前面兩種情況發(fā)生后，就有可能導(dǎo)致各微服務(wù)之間的數(shù)據(jù)不一致，從而影響業(yè)務(wù)。比如在購物的流程中訂單支付成功，但調(diào)用庫存服務(wù)時(shí)失敗，就可能出現(xiàn)產(chǎn)品超賣的情況（訂單數(shù)大于庫存數(shù)）。這種場景下，一般在技術(shù)設(shè)計(jì)上會有相應(yīng)的事件補(bǔ)償和回調(diào)機(jī)制，來確保各方數(shù)據(jù)的一致性。

針對這個(gè)問題作為測試，需要了解這些機(jī)制的觸發(fā)條件，并驗(yàn)證是否合理。同時(shí)，在設(shè)計(jì)測試用例時(shí)，需要關(guān)注跨系統(tǒng)的數(shù)據(jù)一致性驗(yàn)證，不能只關(guān)注自己測試的服務(wù)。

錯(cuò)誤信息的排查：在單體架構(gòu)中，當(dāng)業(yè)務(wù)發(fā)生錯(cuò)誤時(shí)，我們直接查看業(yè)務(wù)日志文件即可發(fā)現(xiàn)問題。但是在微服務(wù)的場景下，測試人員往往無法判斷是哪個(gè)服務(wù)發(fā)生了錯(cuò)誤，不可能每個(gè)組件一個(gè)個(gè)找過去。這就需要有統(tǒng)一的日志存儲服務(wù)來處理。常見的技術(shù)實(shí)現(xiàn)是ELK平臺（Elasticsearch、Logstash 和 Kibana組合），更友好的，可能還會有鏈路跟蹤系統(tǒng)（OpenTracing或者SkyWalking）。在這方面，測試能做的不多，更多的是依賴基礎(chǔ)技術(shù)的沉淀（不要想著自己搞定，因?yàn)檫@些或多或少都會入侵業(yè)務(wù)代碼，還可能影響性能）。

異步服務(wù)的驗(yàn)證：在微服務(wù)的架構(gòu)體系中，為了更好地服務(wù)解耦，會引入MQ之類的異步服務(wù)組件，同時(shí)還能起到削峰填谷的作用。這類組件并不好測試。在制定測試策略時(shí)，需要了解MQ的選型，關(guān)注組件的消費(fèi)速度、消息不被錯(cuò)誤的消費(fèi)等問題。

03

以上，就是基于微服務(wù)架構(gòu)下的一些常見測試策略。技術(shù)架構(gòu)會隨著業(yè)務(wù)的復(fù)雜度不斷的演進(jìn)，微服務(wù)的拆分也不是一蹴而就。所以，在制定測試策略時(shí)，也需要做到可演進(jìn)。

當(dāng)架構(gòu)剛開始拆分時(shí)，我們可以直接按單體架構(gòu)的測試策略進(jìn)行測試；

當(dāng)微服務(wù)數(shù)量較多時(shí)，我們只需要關(guān)注重點(diǎn)微服務(wù)的連通性、可用性及數(shù)據(jù)一致性；

當(dāng)微服務(wù)數(shù)量達(dá)到非常多時(shí)，我們需要引入熔斷降級機(jī)制，并建設(shè)統(tǒng)一的日志管理平臺；

當(dāng)微服務(wù)數(shù)量多到我們反應(yīng)不過來時(shí)，會有更多的驗(yàn)證手段被構(gòu)建出來。

04

做個(gè)小的總結(jié)，對于微服務(wù)架構(gòu)的測試策略，在業(yè)務(wù)層，我們可以沿用原來的測試策略，不需要做太多的變化。而對于架構(gòu)本身帶來的新特性，我們需要有針對性的對應(yīng)措施，整體如下圖所示。

你是否還在尋找穩(wěn)定的海外服務(wù)器提供商？創(chuàng)新互聯(lián)www.cdcxhl.cn海外機(jī)房具備T級流量清洗系統(tǒng)配攻擊溯源，準(zhǔn)確流量調(diào)度確保服務(wù)器高可用性，企業(yè)級服務(wù)器適合批量采購，新人活動首月15元起，快前往官網(wǎng)查看詳情吧

當(dāng)前標(biāo)題：微服務(wù)的測試策略-創(chuàng)新互聯(lián)
鏈接分享：http://vcdvsql.cn/article12/didjdc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站設(shè)計(jì)公司、網(wǎng)站排名、建站公司、網(wǎng)站設(shè)計(jì)、企業(yè)網(wǎng)站制作、網(wǎng)站改版

廣告

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