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