基于springcloud微服務(wù)系統(tǒng)設(shè)計(jì)方案-展示頁(yè)
2025-05-12 22:34本頁(yè)面
【正文】 出來(lái)做微服務(wù)，也是我們第一優(yōu)先級(jí)分離出來(lái)的服務(wù)。 隔離性原則： 每個(gè)服務(wù)相互隔離，且不互相影響 業(yè)務(wù)無(wú)關(guān)優(yōu)先原則： 基礎(chǔ)服務(wù)，是一些基礎(chǔ)組件，與具體的業(yè)務(wù)無(wú)關(guān)。. 服務(wù)拆分原則 粒度微?。? 根據(jù)業(yè)務(wù)功能劃分服務(wù)粒度，總的原則是服務(wù)內(nèi)部高內(nèi)聚，服務(wù)之間低耦合。 設(shè)計(jì)原子服務(wù)層，梳理和抽取核心應(yīng)用、公共應(yīng)用，作為獨(dú)立的服務(wù)下沉到核心和公共能力層，逐漸形成穩(wěn)定的服務(wù)中心，使應(yīng)用能更快速的響應(yīng)多變的客戶需求。架構(gòu)的可靠性保證： 在關(guān)鍵節(jié)點(diǎn)做主備、集群部署，防止單點(diǎn)故障。而Turbine可以幫助我們把所有的服務(wù)實(shí)例的監(jiān)控信息聚合到一個(gè)地方統(tǒng)一查看。Hystrix Dashboard，監(jiān)控面板，他提供了一個(gè)界面，可以監(jiān)控各個(gè)服務(wù)上的服務(wù)調(diào)用所消耗的時(shí)間等。我們只需要在服務(wù)接口上添加Hystrix標(biāo)簽，就可以實(shí)現(xiàn)對(duì)這個(gè)接口的監(jiān)控和斷路器功能。 使用SpringCloud Config進(jìn)行統(tǒng)一的配置管理，需要考慮與公司的配置管理平臺(tái)如何配合使用。使用斷路器hystrix，及時(shí)處理服務(wù)調(diào)用時(shí)的超時(shí)和錯(cuò)誤，防止由于其中一個(gè)服務(wù)的問題而導(dǎo)致整體系統(tǒng)的癱瘓。請(qǐng)求轉(zhuǎn)發(fā)到服務(wù)上的時(shí)候使用負(fù)載均衡Ribbon。 Eureka可部署多個(gè)，進(jìn)行高可用保證。每個(gè)子系統(tǒng)可以部署多個(gè)應(yīng)用，多個(gè)應(yīng)用之間使用負(fù)載均衡。4. 架構(gòu)設(shè)計(jì). 思維設(shè)計(jì) 微服務(wù)架構(gòu)設(shè)計(jì)的根本目的是實(shí)現(xiàn)價(jià)值交付，微服務(wù)架構(gòu)只有遵循DevOps理念方可進(jìn)行的更順暢，思維方式的轉(zhuǎn)變是最重要的。 重復(fù)開發(fā)： 微服務(wù)理念崇尚每個(gè)微服務(wù)作為一個(gè)產(chǎn)品看待，有自己的團(tuán)隊(duì)開發(fā)，甚至可以有自己完全不同的技術(shù)、框架，那么與其他微服務(wù)團(tuán)隊(duì)的技術(shù)共享就產(chǎn)生了矛盾，重復(fù)開發(fā)的工作即產(chǎn)生了。另外，在分布式系統(tǒng)中，通常會(huì)考慮通過數(shù)據(jù)的最終一致性來(lái)解決數(shù)據(jù)瞬時(shí)一致帶來(lái)的系統(tǒng)不可用。 性能（服務(wù)間通訊成本高）： 無(wú)狀態(tài)性、進(jìn)程間調(diào)用、跨網(wǎng)絡(luò)調(diào)用216。 分布式復(fù)雜性： 網(wǎng)絡(luò)延遲、系統(tǒng)容錯(cuò)、分布式事務(wù)216。216。 可靠性：由于采用遠(yuǎn)程調(diào)用的方式，任何一個(gè)節(jié)點(diǎn)、網(wǎng)絡(luò)出現(xiàn)問題，都將使得服務(wù)調(diào)用失敗，隨著微服務(wù)數(shù)量的增多，潛在故障點(diǎn)也將增多。 理解微服務(wù)架構(gòu)和理念是核心。 對(duì)于微服務(wù)架構(gòu)系統(tǒng)，由于其服務(wù)粒度小，模塊化清晰，因此首先要做的是對(duì)系統(tǒng)整體進(jìn)行功能、服務(wù)規(guī)劃，優(yōu)先考慮如何在交付過程中，從工程實(shí)踐出發(fā)，組織好代碼結(jié)構(gòu)、配置、測(cè)試、部署、運(yùn)維、監(jiān)控的整個(gè)過程，從而有效體現(xiàn)微服務(wù)的獨(dú)立性與可部署性。這些服務(wù)具備獨(dú)立業(yè)務(wù)能力并可以通過自動(dòng)化部署方式獨(dú)立部署。每個(gè)服務(wù)運(yùn)行于獨(dú)立的進(jìn)程，并且采用輕量級(jí)交互。微服務(wù)系統(tǒng)設(shè)計(jì)方案1. 微服務(wù)本質(zhì) 微服務(wù)架構(gòu)從本質(zhì)上說(shuō)其實(shí)就是分布式架構(gòu)，與其說(shuō)是一種新架構(gòu)，不如說(shuō)是一種微服務(wù)架構(gòu)風(fēng)格。 簡(jiǎn)單來(lái)說(shuō)，微服務(wù)架構(gòu)風(fēng)格是要開發(fā)一種由多個(gè)小服務(wù)組成的應(yīng)用。多數(shù)情況下是一個(gè)HTTP的資源API。這種風(fēng)格使最小化集中管理，從而可以使用多種不同的編程語(yǔ)言和數(shù)據(jù)存儲(chǔ)技術(shù)。 本文將從微服務(wù)系統(tǒng)的設(shè)計(jì)階段、開發(fā)階段、測(cè)試階段、部署階段進(jìn)行綜合闡述。2. 系統(tǒng)環(huán)境名稱版本說(shuō)明JDKSpring BootSpring FrameworkRibbonkafkaRabbitMQ3. 微服務(wù)架構(gòu)的挑戰(zhàn)216。也就是沒有充分的保障機(jī)制，則單點(diǎn)故障會(huì)大量增加。 運(yùn)維要求高： 系統(tǒng)監(jiān)控、高可用性、自動(dòng)化技術(shù)216。 部署依賴性強(qiáng)： 服務(wù)依賴、多版本問題216。 數(shù)據(jù)一致性： 分布式事務(wù)管理需要跨越多個(gè)節(jié)點(diǎn)來(lái)保證數(shù)據(jù)的瞬時(shí)一致性，因此比起傳統(tǒng)的單體架構(gòu)的事務(wù)，成本要高得多。216。 沒有最好的，只有最適合自己的。實(shí)現(xiàn)微服務(wù)技術(shù)架構(gòu)，現(xiàn)有產(chǎn)品需要進(jìn)行技術(shù)上的改進(jìn)以及相關(guān)配套服務(wù)的實(shí)現(xiàn)，采用分階段實(shí)施、以及試點(diǎn)產(chǎn)品優(yōu)先實(shí)施的策略，主要包括如下： 一、技術(shù)上的改進(jìn)： 前后端分離，web前端通過Http/Https協(xié)議調(diào)用微服務(wù)的API網(wǎng)關(guān)，由API網(wǎng)關(guān)再經(jīng)過路由服務(wù)調(diào)用相應(yīng)的微服務(wù) 不同微服務(wù)之間通過REST方式互相調(diào)用 微服務(wù)之間通過消息中間件實(shí)現(xiàn)消息交互機(jī)制 二、配套服務(wù)與功能實(shí)現(xiàn) ： 需要進(jìn)行相應(yīng)的自動(dòng)化服務(wù)實(shí)現(xiàn)，包括自動(dòng)化構(gòu)建、自動(dòng)化安裝部署、自動(dòng)化測(cè)試、自動(dòng)化平臺(tái)發(fā)布（Docker實(shí)現(xiàn)） 管理服務(wù)，對(duì)于微服務(wù)架構(gòu)，必須配套相應(yīng)的監(jiān)控與管理服務(wù)、日志管理服務(wù)等 協(xié)作服務(wù)，運(yùn)用DevOps思想提升開發(fā)、測(cè)試、運(yùn)維的高效溝通與協(xié)作，實(shí)現(xiàn)開發(fā)與運(yùn)維的一體化 . 微服務(wù)架構(gòu)設(shè)計(jì) 我們把整個(gè)系統(tǒng)根據(jù)業(yè)務(wù)拆分成若干個(gè)子系統(tǒng)或微服務(wù)。需要一個(gè)服務(wù)注冊(cè)中心Eureka，所有的服務(wù)都在注冊(cè)中心注冊(cè)，負(fù)載均衡也是通過在注冊(cè)中心注冊(cè)的服務(wù)來(lái)使用一定策略來(lái)實(shí)現(xiàn)。所有的客戶端都通過同一個(gè)網(wǎng)關(guān)地址訪問后臺(tái)的服務(wù)，通過路由配置ZUUL網(wǎng)關(guān)來(lái)判斷一個(gè)URL請(qǐng)求由哪個(gè)服務(wù)處理。服務(wù)之間
公司管理相關(guān)推薦
鄂ICP備17016276號(hào)-1