基于sringcloud微服務(wù)系統(tǒng)設(shè)計(jì)方案-文庫(kù)吧
2025-04-18 22:33 本頁(yè)面
【正文】 問(wèn)題： Access Control：Zuul網(wǎng)關(guān)提供了相關(guān)控制功能，與我司CAS如何結(jié)合使用 Config Server：Spring Cloud提供了遠(yuǎn)程配置中心，與我司的配置管理平臺(tái)如何結(jié)合使用5. 設(shè)計(jì)階段. 總體設(shè)計(jì) 功能規(guī)劃：對(duì)產(chǎn)品功能進(jìn)行拆分，拆分為若干個(gè)微服務(wù)；一個(gè)功能可以創(chuàng)建多個(gè)微服務(wù)并部署在多個(gè)服務(wù)器節(jié)點(diǎn)上，以便進(jìn)行負(fù)載均衡。 設(shè)計(jì)原子服務(wù)層，梳理和抽取核心應(yīng)用、公共應(yīng)用，作為獨(dú)立的服務(wù)下沉到核心和公共能力層，逐漸形成穩(wěn)定的服務(wù)中心，使應(yīng)用能更快速的響應(yīng)多變的客戶需求。 為每個(gè)服務(wù)設(shè)計(jì)API接口（REST方式） 為不同的服務(wù)進(jìn)行分類，不同類型的服務(wù)需要的資源不同，可以配置不同的資源，包括CPU、內(nèi)存、存儲(chǔ)等。. 服務(wù)拆分原則 粒度微小： 根據(jù)業(yè)務(wù)功能劃分服務(wù)粒度，總的原則是服務(wù)內(nèi)部高內(nèi)聚，服務(wù)之間低耦合。 責(zé)任單一： 每個(gè)服務(wù)只做一件事，即單一職責(zé)原則。 隔離性原則： 每個(gè)服務(wù)相互隔離，且不互相影響 業(yè)務(wù)無(wú)關(guān)優(yōu)先原則： 基礎(chǔ)服務(wù)，是一些基礎(chǔ)組件，與具體的業(yè)務(wù)無(wú)關(guān)。比如：短信服務(wù)、郵件服務(wù)。這里的服務(wù)最容易劃分出來(lái)做微服務(wù)，也是我們第一優(yōu)先級(jí)分離出來(lái)的服務(wù)。. 服務(wù)規(guī)劃 為實(shí)現(xiàn)負(fù)載均衡，允許相同的服務(wù)在多個(gè)節(jié)點(diǎn)注冊(cè)相同的服務(wù)名，不同的端口。如果沒(méi)有前期的規(guī)劃，不同的服務(wù)提供者可能會(huì)注冊(cè)相同的服務(wù)名，導(dǎo)致消費(fèi)者調(diào)用服務(wù)時(shí)產(chǎn)生調(diào)用混亂。 因此，需進(jìn)行服務(wù)名的統(tǒng)一規(guī)劃： 規(guī)劃期統(tǒng)一制定每個(gè)服務(wù)提供者的服務(wù)名或者模塊標(biāo)示。 服務(wù)名的命名規(guī)則:ModuleName_ServiceName，且所有字符小寫，不同單詞之間以下劃線分隔。如用戶管理模塊提供了獲取用戶信息的服務(wù)，則命名為：user_get_info。 新增服務(wù)名時(shí)，需要提出申請(qǐng)，審批通過(guò)后方可使用，為減少審批復(fù)雜度，可只審批ModuleName，即在模塊內(nèi)部可以自由增加服務(wù)名，不需要進(jìn)行審批。. 開發(fā)策略 總體原則：不同的微服務(wù)需進(jìn)行物理隔離。 SVN策略：SVN上創(chuàng)建獨(dú)立的分支，不同微服務(wù)的代碼提交不受相互影響； 由配置管理員統(tǒng)一控制。 問(wèn)題：開發(fā)分支與集成分支，都將增加很多，維護(hù)工作量增加。 編譯策略：代碼編譯時(shí)，各個(gè)微服務(wù)獨(dú)立編譯、打包，杜絕直接的依賴； 工程構(gòu)建：代碼開發(fā)時(shí)，各微服務(wù)創(chuàng)建獨(dú)立的工程，工程之間不能產(chǎn)生直接依賴 持續(xù)集成：每個(gè)微服務(wù)獨(dú)立執(zhí)行持續(xù)集成。 版本集成：由統(tǒng)一的集成工具，實(shí)現(xiàn)自動(dòng)化的版本集成，將所有微服務(wù)集成到統(tǒng)一的版本發(fā)布包中。. 版本策略 每個(gè)微服務(wù)可以獨(dú)立制作版本，伴隨著服務(wù)的增多，SVN分支增多，版本也將增多，版本管理的復(fù)雜度將成指數(shù)級(jí)增加。在服務(wù)之間依賴較多時(shí)，每個(gè)服務(wù)的升級(jí)或降級(jí)都將影響其他服務(wù)的正常運(yùn)行。 因此需執(zhí)行如下策略： 所有服務(wù)的版本制作交由專業(yè)的版本管理員執(zhí)行。 采用自動(dòng)化的版本制作策略，最大程度的減少人工操作。 每個(gè)服務(wù)的版本必須有詳細(xì)的版本計(jì)劃、版本說(shuō)明，對(duì)于版本說(shuō)明要制定模板，明確需要提交的內(nèi)容、版本號(hào)、SVN標(biāo)簽等。 對(duì)項(xiàng)目經(jīng)理的要求提升，需對(duì)整體的版本計(jì)劃有嚴(yán)格的制定，尤其是版本之間的依賴關(guān)系要非常明確，版本升級(jí)、降級(jí)的風(fēng)險(xiǎn)評(píng)估需完全充分。 接口管理：嚴(yán)格執(zhí)行接口管理制度，任何接口的變更必須進(jìn)行審批、發(fā)公告等流程。. 數(shù)據(jù)庫(kù)挑戰(zhàn)與策略 每個(gè)微服務(wù)都有自己獨(dú)立的數(shù)據(jù)庫(kù)，那么后臺(tái)管理的聯(lián)合查詢?cè)趺刺幚恚窟@應(yīng)該是大家會(huì)普遍遇到的一個(gè)問(wèn)題，有三種處理方案。 1）嚴(yán)格按照微服務(wù)的劃分來(lái)做，微服務(wù)相互獨(dú)立，各微服務(wù)數(shù)據(jù)庫(kù)也獨(dú)立，后臺(tái)需要展示數(shù)據(jù)時(shí)，調(diào)用各微服務(wù)的接口來(lái)獲取對(duì)應(yīng)的數(shù)據(jù)，再進(jìn)行數(shù)據(jù)處理后展示出來(lái)，這是標(biāo)準(zhǔn)的用法，也是最麻煩的用法。 2) 將業(yè)務(wù)高度相關(guān)的表放到一個(gè)庫(kù)中，將業(yè)務(wù)關(guān)系不是很緊密的表嚴(yán)格按照微服務(wù)模式來(lái)拆分，這樣既可以使用微服務(wù)，也避免了數(shù)據(jù)庫(kù)分散導(dǎo)致后臺(tái)系統(tǒng)統(tǒng)計(jì)功能難以實(shí)現(xiàn)，是一個(gè)折中的方案。 3）數(shù)據(jù)庫(kù)嚴(yán)格按照微服務(wù)的要求來(lái)切分，以滿足業(yè)務(wù)高并發(fā)，實(shí)時(shí)或者準(zhǔn)實(shí)時(shí)將各微服務(wù)數(shù)據(jù)庫(kù)數(shù)據(jù)同步到NoSQL數(shù)據(jù)庫(kù)中，在同步的過(guò)程中進(jìn)行數(shù)據(jù)清洗，用來(lái)滿足后臺(tái)業(yè)務(wù)系統(tǒng)的使用，推薦使用MongoDB、HBase等。 第一種方案適合業(yè)務(wù)較為簡(jiǎn)單的小公司；第二種方案，適合在原有系統(tǒng)之上，慢慢演化為微服務(wù)架構(gòu)的公司；第三種適合大型高并發(fā)的互聯(lián)網(wǎng)公司。 建議，我們當(dāng)前采用第二種方案。. 負(fù)載均衡 不再采用一般的增加負(fù)載均衡服務(wù)器的方式進(jìn)行負(fù)載均衡，如FNginx、LVS等，而是把負(fù)載均衡的功能以庫(kù)的方式集成到服務(wù)消費(fèi)方的進(jìn)程內(nèi)，這種方案稱為軟負(fù)載均衡（Soft Load Balancing）或者客戶端負(fù)載均衡。在Spring Cloud中配合Eureka的服務(wù)注冊(cè)功能，Ribbon子項(xiàng)目則為REST客戶端實(shí)現(xiàn)了負(fù)載均衡。 使用Ribbon進(jìn)行負(fù)載均衡，其工作原理可以概括為下面四個(gè)步驟：1. Ribbon首先根據(jù)其所在Zone優(yōu)先選擇一個(gè)負(fù)載較少的Eureka Server。2. 定期從Eureka Server更新并過(guò)濾服務(wù)實(shí)例列表。3. 根據(jù)指定的負(fù)載均衡
公司管理相關(guān)推薦
鄂ICP備17016276號(hào)-1