微服務(wù)系統(tǒng)和數(shù)據(jù)庫設(shè)計方案-wenkub
2023-05-25 05:07:03 本頁面
【正文】 的監(jiān)控和斷路器功能。使用斷路器hystrix，及時處理服務(wù)調(diào)用時的超時和錯誤，防止由于其中一個服務(wù)的問題而導(dǎo)致整體系統(tǒng)的癱瘓。Eureka可部署多個，進(jìn)行高可用保證。216。 部署依賴性強(qiáng)： 服務(wù)依賴、多版本問題216。也就是沒有充分的保障機(jī)制，則單點(diǎn)故障會大量增加。 本文將從微服務(wù)系統(tǒng)的設(shè)計階段、開發(fā)階段、測試階段、部署階段進(jìn)行綜合闡述。多數(shù)情況下是一個HTTP的資源API。.微服務(wù)系統(tǒng)和數(shù)據(jù)庫設(shè)計方案1. 微服務(wù)本質(zhì) 微服務(wù)架構(gòu)從本質(zhì)上說其實(shí)就是分布式架構(gòu)，與其說是一種新架構(gòu)，不如說是一種微服務(wù)架構(gòu)風(fēng)格。這些服務(wù)具備獨(dú)立業(yè)務(wù)能力并可以通過自動化部署方式獨(dú)立部署。 理解微服務(wù)架構(gòu)和理念是核心。216。 性能（服務(wù)間通訊成本高）： 無狀態(tài)性、進(jìn)程間調(diào)用、跨網(wǎng)絡(luò)調(diào)用216。 重復(fù)開發(fā)： 微服務(wù)理念崇尚每個微服務(wù)作為一個產(chǎn)品看待，有自己的團(tuán)隊開發(fā)，甚至可以有自己完全不同的技術(shù)、框架，那么與其他微服務(wù)團(tuán)隊的技術(shù)共享就產(chǎn)生了矛盾，重復(fù)開發(fā)的工作即產(chǎn)生了。我們把整個系統(tǒng)根據(jù)業(yè)務(wù)拆分成若干個子系統(tǒng)或微服務(wù)。所有的客戶端都通過同一個網(wǎng)關(guān)地址訪問后臺的服務(wù)，通過路由配置ZUUL網(wǎng)關(guān)來判斷一個URL請求由哪個服務(wù)處理。還需要一個監(jiān)控功能，監(jiān)控每個服務(wù)調(diào)用花費(fèi)的時間等。1Turbine，監(jiān)控聚合，使用Hystrix監(jiān)控，我們需要打開每一個服務(wù)實(shí)例的監(jiān)控信息來查看。待后續(xù)確認(rèn)問題： 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é)點(diǎn)上，以便進(jìn)行負(fù)載均衡。 責(zé)任單一： 每個服務(wù)只做一件事，即單一職責(zé)原則。. 服務(wù)規(guī)劃 為實(shí)現(xiàn)負(fù)載均衡，允許相同的服務(wù)在多個節(jié)點(diǎn)注冊相同的服務(wù)名，不同的端口。如用戶管理模塊提供了獲取用戶信息的服務(wù)，則命名為：user_get_info。 問題：開發(fā)分支與集成分支，都將增加很多，維護(hù)工作量增加。在服務(wù)之間依賴較多時，每個服務(wù)的升級或降級都將影響其他服務(wù)的正常運(yùn)行。 對項目經(jīng)理的要求提升，需對整體的版本計劃有嚴(yán)格的制定，尤其是版本之間的依賴關(guān)系要非常明確，版本升級、降級的風(fēng)險評估需完全充分。 2) 將業(yè)務(wù)高度相關(guān)的表放到一個庫中，將業(yè)務(wù)關(guān)系不是很緊密的表嚴(yán)格按照微服務(wù)模式來拆分，這樣既可以使用微服務(wù)，也避免了數(shù)據(jù)庫分散導(dǎo)致后臺系統(tǒng)統(tǒng)計功能難以實(shí)現(xiàn)，是一個折中的方案。 建議，我們當(dāng)前采用第二種方案。2. 定期從Eureka Server更新并過濾服務(wù)實(shí)例列表。 RoundRobinRule: RandomRule:最大可用策略，即先過濾出故障服務(wù)器后，選擇一個當(dāng)前并發(fā)請求數(shù)最小的。 ZoneAvoidanceRule: 但這也同時帶來了諸多問題，如下： 各服務(wù)是否可以任意使用自己的技術(shù)、自己的組件、框架呢？如果這樣，勢必帶來更大的管理困難、維護(hù)困難、技術(shù)共享困難。Zuul可能會成為系統(tǒng)瓶頸，在項目復(fù)雜時可考慮為Zuul進(jìn)行主備或負(fù)載均衡處理。. 異步調(diào)用 rabbitMq、kafka、Spring Cloud Stream均是可以選擇的方案。使用Spring Cloud Netfix框架的話，登錄的時候，把登錄請求轉(zhuǎn)發(fā)到相應(yīng)的用戶服務(wù)上，登陸成功后，會設(shè)置cookie或header token等。但是，如果你想禁止某些header透傳到服務(wù)端，：zuul:routes:users: path: /users/** sensitiveHeaders: Cookie,SetCookie,Authorization serviceId: user剛才說了我們的某個服務(wù)有時候需要調(diào)用另一個服務(wù)，這時候，這個請求不是客戶端發(fā)起，他的請求的header里面也不會有任何驗證信息。也可以通過如下的攔截器的方式設(shè)置，它對RestTemplate方式和FeignClient的方式都可以起作用：Beanpublic RequestInterceptor requestInterceptor() {return new RequestInterceptor() { Override public void apply(RequestTemplate template) { String authToken = getToken()。比如現(xiàn)在有項目a調(diào)用項目b，項目b調(diào)用項目c...一直到h，是一個調(diào)用鏈，那么項目上線的時候需要先更新最底層的h再更新g...更新c更新b最后是更新項目a。 其實(shí)可以理解為面向?qū)ο蟮脑O(shè)計，減少方法之間的一層層嵌套調(diào)用，而采取一個方法進(jìn)行業(yè)務(wù)流程的串聯(lián)，如方法W實(shí)現(xiàn)一個完整的業(yè)務(wù)處理，則采取下面方式： function w（） { 調(diào)用方法a； 調(diào)用方法b； 調(diào)用方法c； }. 服務(wù)的熔斷處理 在服務(wù)之間進(jìn)行調(diào)用
公司管理相關(guān)推薦
鄂ICP備17016276號-1