微服務(wù)系統(tǒng)和數(shù)據(jù)庫(kù)設(shè)計(jì)方案-文庫(kù)吧資料
2025-05-16 05:07本頁(yè)面
【正文】 equestInterceptor() {return new RequestInterceptor() { Override public void apply(RequestTemplate template) { String authToken = getToken()。同時(shí)，如果你想在某個(gè)服務(wù)里面獲得這個(gè)請(qǐng)求的真是IP，（因?yàn)檎?qǐng)求的通過(guò)網(wǎng)關(guān)轉(zhuǎn)發(fā)而來(lái)，你直接通過(guò)request獲得ip得到的是網(wǎng)關(guān)的IP），就可以從headerXForwardedHost獲得。但是，如果你想禁止某些header透?jìng)鞯椒?wù)端，：zuul:routes:users: path: /users/** sensitiveHeaders: Cookie,SetCookie,Authorization serviceId: user剛才說(shuō)了我們的某個(gè)服務(wù)有時(shí)候需要調(diào)用另一個(gè)服務(wù)，這時(shí)候，這個(gè)請(qǐng)求不是客戶端發(fā)起，他的請(qǐng)求的header里面也不會(huì)有任何驗(yàn)證信息。Zuul網(wǎng)關(guān)在把請(qǐng)求轉(zhuǎn)發(fā)到后臺(tái)的服務(wù)的時(shí)候，會(huì)默認(rèn)把一些header傳到服務(wù)端，如：Cookie、SetCookie、Authorization。使用Spring Cloud Netfix框架的話，登錄的時(shí)候，把登錄請(qǐng)求轉(zhuǎn)發(fā)到相應(yīng)的用戶服務(wù)上，登陸成功后，會(huì)設(shè)置cookie或header token等。 Spring Cloud Stream，基于 Redis、Rabbit、Kafka 實(shí)現(xiàn)的消息微服務(wù)，簡(jiǎn)單聲明模型用以在 Spring Cloud 應(yīng)用中收發(fā)消息。. 異步調(diào)用 rabbitMq、kafka、Spring Cloud Stream均是可以選擇的方案。 不管是什么方式，他都是通過(guò)REST接口調(diào)用服務(wù)的接口，參數(shù)和結(jié)果默認(rèn)都是通過(guò)Jackson序列化和反序列化。Zuul可能會(huì)成為系統(tǒng)瓶頸，在項(xiàng)目復(fù)雜時(shí)可考慮為Zuul進(jìn)行主備或負(fù)載均衡處理。 特殊情況：特殊服務(wù)需要使用特殊的組件、框架，需提出申請(qǐng)，統(tǒng)籌規(guī)劃后進(jìn)行決策。 但這也同時(shí)帶來(lái)了諸多問(wèn)題，如下： 各服務(wù)是否可以任意使用自己的技術(shù)、自己的組件、框架呢？如果這樣，勢(shì)必帶來(lái)更大的管理困難、維護(hù)困難、技術(shù)共享困難。. 性能策略 網(wǎng)絡(luò)優(yōu)化：優(yōu)化組網(wǎng)結(jié)構(gòu)，提升網(wǎng)絡(luò)間通訊性能； 配置優(yōu)化：優(yōu)化Spring Cloud組件集以及其他組件的配置信息，使得性能最大化。 ZoneAvoidanceRule:可用過(guò)濾策略，先過(guò)濾出故障的或并發(fā)請(qǐng)求大于閾值一部分服務(wù)實(shí)例，然后再以線性輪詢的方式從過(guò)濾后的實(shí)例清單中選出一個(gè)。 WeightedResponseTimeRule:最大可用策略，即先過(guò)濾出故障服務(wù)器后，選擇一個(gè)當(dāng)前并發(fā)請(qǐng)求數(shù)最小的。 RandomRule:所以示例中所啟動(dòng)的兩個(gè)服務(wù)會(huì)被循環(huán)訪問(wèn)。 RoundRobinRule:4. 然后通過(guò)RestClient進(jìn)行服務(wù)調(diào)用。2. 定期從Eureka Server更新并過(guò)濾服務(wù)實(shí)例列表。在Spring Cloud中配合Eureka的服務(wù)注冊(cè)功能，Ribbon子項(xiàng)目則為REST客戶端實(shí)現(xiàn)了負(fù)載均衡。 建議，我們當(dāng)前采用第二種方案。4）數(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等。 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è)折中的方案。. 數(shù)據(jù)庫(kù)挑戰(zhàn)與策略 每個(gè)微服務(wù)都有自己獨(dú)立的數(shù)據(jù)庫(kù)，那么后臺(tái)管理的聯(lián)合查詢?cè)趺刺幚恚窟@應(yīng)該是大家會(huì)普遍遇到的一個(gè)問(wèn)題，有四種處理方案。 對(duì)項(xiàng)目經(jīng)理的要求提升，需對(duì)整體的版本計(jì)劃有嚴(yán)格的制定，尤其是版本之間的依賴關(guān)系要非常明確，版本升級(jí)、降級(jí)的風(fēng)險(xiǎn)評(píng)估需完全充分。 采用自動(dòng)化的版本制作策略，最大程度的減少人工操作。在服務(wù)之間依賴較多時(shí)，每個(gè)服務(wù)的升級(jí)或降級(jí)都將影響其他服務(wù)的正常運(yùn)行。 版本集成：由統(tǒng)一的集成工具，實(shí)現(xiàn)自動(dòng)化的版本集成，將所有微服務(wù)集成到統(tǒng)一的版本發(fā)布包中。 問(wèn)題：開發(fā)分支與集成分支，都將增加很多，維護(hù)工作量增加。. 開發(fā)策略 總體原則：不同的微服務(wù)需進(jìn)行物理隔離。如用戶管理模塊提供了獲取用戶信息的服務(wù)，則命名為：user_get_info。 因此，需進(jìn)行服務(wù)名的統(tǒng)一規(guī)劃： 規(guī)劃期統(tǒng)一制定每個(gè)服務(wù)提供者的服務(wù)名或者模塊標(biāo)示。. 服務(wù)規(guī)劃 為實(shí)現(xiàn)負(fù)載均衡，允許相同的服務(wù)在多個(gè)節(jié)點(diǎn)注冊(cè)相同的服務(wù)名，不同的端口。比如：短信服務(wù)、郵件服務(wù)。 責(zé)任單一： 每個(gè)服務(wù)只做一件事，即單一職責(zé)原則。 為每個(gè)服務(wù)設(shè)計(jì)API接口（REST方式） 為不同的服務(wù)進(jìn)行分類，不同類型的服務(wù)需要的資源不同，可以配置不同的資源，包括CPU、內(nèi)存、存儲(chǔ)等。待后續(xù)確認(rèn)問(wèn)題： Access Control：Zuul網(wǎng)關(guān)提供了相關(guān)控制功能，與我司CAS如何結(jié)合使用 Config Server：Spring Cloud提供了
公司管理相關(guān)推薦
鄂ICP備17016276號(hào)-1