微服務(wù)系統(tǒng)和數(shù)據(jù)庫(kù)設(shè)計(jì)方案-資料下載頁(yè)
2025-05-10 05:01本頁(yè)面
【正文】 過(guò)Web Hook來(lái)逐個(gè)進(jìn)行刷新的問(wèn)題。. 分布式session 采用Redis作為緩存組件以及session的共享組件。 . REST資源響應(yīng)結(jié)構(gòu) 制定規(guī)范和解析方法。. API調(diào)用鏈追蹤 微服務(wù)架構(gòu)上通過(guò)業(yè)務(wù)來(lái)劃分服務(wù)的，通過(guò)REST調(diào)用，對(duì)外暴露的一個(gè)接口，可能需要很多個(gè)服務(wù)協(xié)同才能完成這個(gè)接口功能，如果鏈路上任何一個(gè)服務(wù)出現(xiàn)問(wèn)題或者網(wǎng)絡(luò)超時(shí)，都會(huì)形成導(dǎo)致接口調(diào)用失敗。隨著業(yè)務(wù)的不斷擴(kuò)張，服務(wù)之間互相調(diào)用會(huì)越來(lái)越復(fù)雜。Spring Cloud Sleuth 主要功能就是在分布式系統(tǒng)中提供追蹤解決方案，并且兼容支持了 zipkin，你只需要在pom文件中引入相應(yīng)的依賴(lài)即可。. 單元測(cè)試 做微服務(wù)架構(gòu)，進(jìn)行系統(tǒng)測(cè)試的復(fù)雜度較大，為保證產(chǎn)品質(zhì)量與開(kāi)發(fā)、測(cè)試效率，單元測(cè)試是必不可少的。 可采用Mock方式進(jìn)行測(cè)試模擬，由持續(xù)集成進(jìn)行自動(dòng)化單元測(cè)試的執(zhí)行以及結(jié)果輸出。. 代碼調(diào)試 對(duì)于單體架構(gòu)系統(tǒng)，可直接本地化調(diào)試，但對(duì)于微服務(wù)架構(gòu)，接口間的調(diào)用需采用遠(yuǎn)程通訊的方式，也就是說(shuō)被調(diào)用的服務(wù)必須啟動(dòng)后方可被調(diào)用，因此當(dāng)微服務(wù)增多時(shí)，你可能需要啟動(dòng)大量的微服務(wù)或者web服務(wù)器，這給本地化調(diào)用與調(diào)試帶來(lái)了困難。 解決方案待研究。7. 測(cè)試. 自動(dòng)化測(cè)試216。 單元測(cè)試： 由開(kāi)發(fā)人員實(shí)現(xiàn)。 采用Mock方式進(jìn)行測(cè)試模擬，由持續(xù)集成進(jìn)行自動(dòng)化單元測(cè)試的執(zhí)行以及結(jié)果輸出。216。 業(yè)務(wù)測(cè)試： 開(kāi)發(fā)進(jìn)行實(shí)現(xiàn)，測(cè)試也需考慮如何實(shí)現(xiàn)。 將多個(gè)服務(wù)或業(yè)務(wù)單元進(jìn)行串聯(lián)，測(cè)試一個(gè)完整的業(yè)務(wù)，甚至是不同業(yè)務(wù)之間組成的系統(tǒng)測(cè)試，需要采用相關(guān)的自動(dòng)化測(cè)試框架執(zhí)行，如RobotFramework自動(dòng)化測(cè)試框架。. 依賴(lài)測(cè)試 也可以稱(chēng)為接口測(cè)試或者契約測(cè)試，在微服務(wù)逐漸增多的情況下，如何有效保證服務(wù)之間能夠按照接口的約定正常工作，即符合契約，成為微服務(wù)實(shí)施過(guò)程中，測(cè)試面臨的主要挑戰(zhàn)。 一、開(kāi)發(fā)自動(dòng)化的接口測(cè)試工具， 檢測(cè)接口是否滿(mǎn)足約定 檢測(cè)接口是否發(fā)生變化 檢測(cè)接口是否可以正常被調(diào)用。 二、測(cè)試方法： 采取基于消費(fèi)者驅(qū)動(dòng)的契約測(cè)試，測(cè)試架構(gòu)如下： 其優(yōu)勢(shì)如下：216。 從價(jià)值實(shí)現(xiàn)的角度定義契約從消費(fèi)者使用契約的角度出發(fā)，首先保證消費(fèi)者基于此契約是可以實(shí)現(xiàn)價(jià)值的，有了這個(gè)前提，再使用契約來(lái)驗(yàn)證提供者，如果提供者提供的契約同定義的契約一致，則證明提供者提供的契約是能夠?qū)崿F(xiàn)服務(wù)消費(fèi)者的。通過(guò)這種方式，使得更聚焦于如何從價(jià)值實(shí)現(xiàn)出發(fā)。216。 隔離消費(fèi)者和提供者的測(cè)試對(duì)于契約的消費(fèi)者和提供者可以分開(kāi)獨(dú)立測(cè)試，有效解決傳統(tǒng)集成測(cè)試服務(wù)架構(gòu)的弊端，將微服務(wù)的接口測(cè)試成本降到最低。 三、測(cè)試工具： Pact、Janus、Pacto等。. 系統(tǒng)測(cè)試. 熔斷測(cè)試 通過(guò)停止微服務(wù)的方式測(cè)試服務(wù)路由的正確性 通過(guò)壓力測(cè)試，將某個(gè)微服務(wù)產(chǎn)生過(guò)載等異常，測(cè)試服務(wù)熔斷或降級(jí) 通過(guò)壓力測(cè)試，測(cè)試負(fù)載均衡策略的正確性. 性能測(cè)試 原有本地化的api調(diào)用將會(huì)變成REST的遠(yuǎn)程調(diào)用，調(diào)用速度勢(shì)必受到影響，因此需要對(duì)系統(tǒng)性能進(jìn)行考慮以及性能測(cè)試，主要影響因素如下：網(wǎng)絡(luò)：遠(yuǎn)程調(diào)用時(shí)受到網(wǎng)絡(luò)通訊速度的影響，這涉及到網(wǎng)絡(luò)速度、網(wǎng)絡(luò)部署以及系統(tǒng)架構(gòu)，有相互依賴(lài)的服務(wù)應(yīng)采取就近部署原則。服務(wù)器：受到遠(yuǎn)程服務(wù)所在服務(wù)器性能的影響。數(shù)據(jù)量：數(shù)據(jù)量這里指的是數(shù)據(jù)大小以及數(shù)據(jù)傳輸?shù)拇螖?shù)以及頻率，此時(shí)REST調(diào)用方式會(huì)產(chǎn)生瓶頸，當(dāng)然，最好的方式是避免此種情況發(fā)生，此種場(chǎng)景采取消息中間件的方式異步通訊。8. 持續(xù)集成 持續(xù)集成：每個(gè)微服務(wù)獨(dú)立執(zhí)行持續(xù)集成。 版本集成：由統(tǒng)一的集成工具，實(shí)現(xiàn)自動(dòng)化的版本集成，將所有微服務(wù)集成到統(tǒng)一的版本發(fā)布包中。 持續(xù)集成可制作多種場(chǎng)景的版本，包括測(cè)試環(huán)境、開(kāi)發(fā)環(huán)境、生產(chǎn)環(huán)境。 統(tǒng)計(jì)測(cè)試覆蓋率等指標(biāo)數(shù)據(jù)。 工具：Jenkins、Sonar等。9. 持續(xù)部署 通過(guò)持續(xù)集成自動(dòng)制作發(fā)布版本的Docker鏡像； 將docker鏡像自動(dòng)上傳到docker容器中。 10. 運(yùn)維階段. 遠(yuǎn)程升級(jí) 微服務(wù)不斷增加后，意味著部署容器也在同步增加，對(duì)于后續(xù)升級(jí)維護(hù)的工作量將會(huì)逐漸增加，開(kāi)發(fā)統(tǒng)一管理中心，支持遠(yuǎn)程維護(hù)與升級(jí)將可減少運(yùn)維的復(fù)雜度。. 統(tǒng)一配置中心 使用Spring Cloud Config或者配置管理平臺(tái)進(jìn)行統(tǒng)一的配置管理。它包含了Client和Server兩個(gè)部分，Server提供配置文件的存儲(chǔ)、以接口的形式將配置文件的內(nèi)容提供出去，Client通過(guò)接口獲取數(shù)據(jù)、并依據(jù)此數(shù)據(jù)初始化自己的應(yīng)用。其實(shí)就是Server端將所有的配置文件服務(wù)化，需要配置文件的服務(wù)實(shí)例去Config Server獲取對(duì)應(yīng)的數(shù)據(jù)。將所有的配置文件統(tǒng)一整理，避免了配置文件碎片化。如果服務(wù)運(yùn)行期間改變配置文件，服務(wù)是不會(huì)得到最新的配置信息，需要解決這個(gè)問(wèn)題就需要引入Refresh?？梢栽诜?wù)的運(yùn)行期間重新加載配置文件。. 統(tǒng)一日志中心 使用日志管理平臺(tái)進(jìn)行統(tǒng)一的日志采集、日志分析。 THANKS !!!致力為企業(yè)和個(gè)人提供合同協(xié)議，策劃案計(jì)劃書(shū)，學(xué)習(xí)課件等等打造全網(wǎng)一站式需求歡迎您的下載，資料僅供參考可修改編
公司管理相關(guān)推薦
鄂ICP備17016276號(hào)-1