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