基于sringcloud微服務(wù)系統(tǒng)設(shè)計(jì)方案-wenkub
2023-05-18 22:33:11 本頁面
【正文】 Server：Spring Cloud提供了遠(yuǎn)程配置中心，與我司的配置管理平臺如何結(jié)合使用5. 設(shè)計(jì)階段. 總體設(shè)計(jì) 功能規(guī)劃：對產(chǎn)品功能進(jìn)行拆分，拆分為若干個(gè)微服務(wù)；一個(gè)功能可以創(chuàng)建多個(gè)微服務(wù)并部署在多個(gè)服務(wù)器節(jié)點(diǎn)上，以便進(jìn)行負(fù)載均衡。1Turbine，監(jiān)控聚合，使用Hystrix監(jiān)控，我們需要打開每一個(gè)服務(wù)實(shí)例的監(jiān)控信息來查看。還需要一個(gè)監(jiān)控功能，監(jiān)控每個(gè)服務(wù)調(diào)用花費(fèi)的時(shí)間等。所有的客戶端都通過同一個(gè)網(wǎng)關(guān)地址訪問后臺的服務(wù)，通過路由配置ZUUL網(wǎng)關(guān)來判斷一個(gè)URL請求由哪個(gè)服務(wù)處理。我們把整個(gè)系統(tǒng)根據(jù)業(yè)務(wù)拆分成若干個(gè)子系統(tǒng)或微服務(wù)。 沒有最好的，只有最適合自己的。 數(shù)據(jù)一致性： 分布式事務(wù)管理需要跨越多個(gè)節(jié)點(diǎn)來保證數(shù)據(jù)的瞬時(shí)一致性，因此比起傳統(tǒng)的單體架構(gòu)的事務(wù)，成本要高得多。 運(yùn)維要求高： 系統(tǒng)監(jiān)控、高可用性、自動化技術(shù)216。2. 系統(tǒng)環(huán)境名稱版本說明JDKSpring BootSpring FrameworkRibbonkafkaRabbitMQ3. 微服務(wù)架構(gòu)的挑戰(zhàn)216。這種風(fēng)格使最小化集中管理，從而可以使用多種不同的編程語言和數(shù)據(jù)存儲技術(shù)。 簡單來說，微服務(wù)架構(gòu)風(fēng)格是要開發(fā)一種由多個(gè)小服務(wù)組成的應(yīng)用。每個(gè)服務(wù)運(yùn)行于獨(dú)立的進(jìn)程，并且采用輕量級交互。 對于微服務(wù)架構(gòu)系統(tǒng)，由于其服務(wù)粒度小，模塊化清晰，因此首先要做的是對系統(tǒng)整體進(jìn)行功能、服務(wù)規(guī)劃，優(yōu)先考慮如何在交付過程中，從工程實(shí)踐出發(fā)，組織好代碼結(jié)構(gòu)、配置、測試、部署、運(yùn)維、監(jiān)控的整個(gè)過程，從而有效體現(xiàn)微服務(wù)的獨(dú)立性與可部署性。 可靠性：由于采用遠(yuǎn)程調(diào)用的方式，任何一個(gè)節(jié)點(diǎn)、網(wǎng)絡(luò)出現(xiàn)問題，都將使得服務(wù)調(diào)用失敗，隨著微服務(wù)數(shù)量的增多，潛在故障點(diǎn)也將增多。 分布式復(fù)雜性： 網(wǎng)絡(luò)延遲、系統(tǒng)容錯(cuò)、分布式事務(wù)216。另外，在分布式系統(tǒng)中，通常會考慮通過數(shù)據(jù)的最終一致性來解決數(shù)據(jù)瞬時(shí)一致帶來的系統(tǒng)不可用。4. 架構(gòu)設(shè)計(jì). 思維設(shè)計(jì) 微服務(wù)架構(gòu)設(shè)計(jì)的根本目的是實(shí)現(xiàn)價(jià)值交付，微服務(wù)架構(gòu)只有遵循DevOps理念方可進(jìn)行的更順暢，思維方式的轉(zhuǎn)變是最重要的。每個(gè)子系統(tǒng)可以部署多個(gè)應(yīng)用，多個(gè)應(yīng)用之間使用負(fù)載均衡。請求轉(zhuǎn)發(fā)到服務(wù)上的時(shí)候使用負(fù)載均衡Ribbon。 使用SpringCloud Config進(jìn)行統(tǒng)一的配置管理，需要考慮與公司的配置管理平臺如何配合使用。而Turbine可以幫助我們把所有的服務(wù)實(shí)例的監(jiān)控信息聚合到一個(gè)地方統(tǒng)一查看。 設(shè)計(jì)原子服務(wù)層，梳理和抽取核心應(yīng)用、公共應(yīng)用，作為獨(dú)立的服務(wù)下沉到核心和公共能力層，逐漸形成穩(wěn)定的服務(wù)中心，使應(yīng)用能更快速的響應(yīng)多變的客戶需求。 隔離性原則： 每個(gè)服務(wù)相互隔離，且不互相影響 業(yè)務(wù)無關(guān)優(yōu)先原則： 基礎(chǔ)服務(wù)，是一些基礎(chǔ)組件，與具體的業(yè)務(wù)無關(guān)。如果沒有前期的規(guī)劃，不同的服務(wù)提供者可能會注冊相同的服務(wù)名，導(dǎo)致消費(fèi)者調(diào)用服務(wù)時(shí)產(chǎn)生調(diào)用混亂。 新增服務(wù)名時(shí)，需要提出申請，審批通過后方可使用，為減少審批復(fù)雜度，可只審批ModuleName，即在模塊內(nèi)部可以自由增加服務(wù)名，不需要進(jìn)行審批。 編譯策略：代碼編譯時(shí)，各個(gè)微服務(wù)獨(dú)立編譯、打包，杜絕直接的依賴； 工程構(gòu)建：代碼開發(fā)時(shí)，各微服務(wù)創(chuàng)建獨(dú)立的工程，工程之間不能產(chǎn)生直接依賴 持續(xù)集成：每個(gè)微服務(wù)獨(dú)立執(zhí)行持續(xù)集成。 因此需執(zhí)行如下策略： 所有服務(wù)的版本制作交由專業(yè)的版本管理員執(zhí)行。 接口管理：嚴(yán)格執(zhí)行接口管理制度，任何接口的變更必須進(jìn)行審批、發(fā)公告等流程。 3）數(shù)據(jù)庫嚴(yán)格按照微服務(wù)的要求來切分，以滿足業(yè)務(wù)高并發(fā)，實(shí)時(shí)或者準(zhǔn)實(shí)時(shí)將各微服務(wù)數(shù)據(jù)庫數(shù)據(jù)同步到NoSQL數(shù)據(jù)庫中，在同步的過程中進(jìn)行數(shù)據(jù)清洗，用來滿足后臺業(yè)務(wù)系統(tǒng)的使用，推薦使用MongoDB、HBase等。在Spring Cloud中配合Eureka的服務(wù)注冊功能，Ribbon子項(xiàng)目則為REST客戶端實(shí)現(xiàn)了負(fù)載均衡。4. 然后通過RestClient進(jìn)行服務(wù)調(diào)用。所以示例中所啟動的兩個(gè)服務(wù)會被循環(huán)訪問。 WeightedResponseTimeRule:可用過濾策略，先過濾出故障的或并發(fā)請求大于閾值一部分服務(wù)實(shí)例，然后再以線性輪詢的方式從過濾后的實(shí)例清單中選出一個(gè)。. 性能策略 網(wǎng)絡(luò)優(yōu)化：優(yōu)化組網(wǎng)結(jié)構(gòu)，提升網(wǎng)絡(luò)間通訊性能； 配置優(yōu)化：優(yōu)化Spring Cloud組件集以及其他組件的配置信息，使得性能最大化。 特殊情況：特殊服務(wù)需要使用特殊的組件、框架，需提出申請，統(tǒng)籌規(guī)劃后進(jìn)行決策。 不管是什么方式，他都是通過REST接口調(diào)用服務(wù)的接口，參數(shù)和結(jié)果默認(rèn)都是通過Jackson序列化和反序列化。 Spring Cloud Stream，基于 Redis、Rabbit、Kafka 實(shí)現(xiàn)的消息微服務(wù)，簡單聲明模型用以在 Spring Cloud 應(yīng)用中收發(fā)消息。Zuul網(wǎng)關(guān)在把請求轉(zhuǎn)發(fā)到后臺的服務(wù)的時(shí)候，會默認(rèn)把一些header傳到服務(wù)端，如：Cookie、SetCookie、Au
公司管理相關(guān)推薦
鄂ICP備17016276號-1