基于sringcloud微服務系統(tǒng)設計方案-免費閱讀
【正文】 10. 運維階段. 遠程升級 微服務不斷增加后，意味著部署容器也在同步增加，對于后續(xù)升級維護的工作量將會逐漸增加，開發(fā)統(tǒng)一管理中心，支持遠程維護與升級將可減少運維的復雜度。服務器：受到遠程服務所在服務器性能的影響。 一、開發(fā)自動化的接口測試工具， 檢測接口是否滿足約定 檢測接口是否發(fā)生變化 檢測接口是否可以正常被調(diào)用。 解決方案待研究。. 分布式session 采用Redis作為緩存組件以及session的共享組件。Spring Cloud Config把應用原本放在本地文件的配置抽取出來放在中心服務器，本質(zhì)是配置信息從本地遷移到云端。Spring cloud Hystrix 熔斷器. 統(tǒng)一日志管理 不同微服務部署在不同節(jié)點上，登錄每個節(jié)點查看日志是比較麻煩的，同時對于需要關聯(lián)多個微服務日志聯(lián)合查看分析的情況將更加麻煩。}. 服務編排 主要的作用是減少項目中的相互依賴。這樣，客戶端請求的相關headers就可以傳遞到服務端，服務端設置的cookie也可以傳到客戶端。因為Spring MVC的RestController定義的接口，返回的數(shù)據(jù)都是通過Jackson序列化成JSON數(shù)據(jù)。. 技術管理策略 微服務的架構理念中指出各微服務可以獨立建設，可以使用不同的技術、語言、框架等，以便能更快速的使用新技術、新框架等響應特定客戶需求，解決單體應用架構更新技術、更新框架時面臨的困難或阻礙。帶有加權的輪詢策略，對各個服務器響應時間進行加權處理，然后在采用輪詢的方式來獲取相應的服務器。 使用Ribbon進行負載均衡，其工作原理可以概括為下面四個步驟：1. Ribbon首先根據(jù)其所在Zone優(yōu)先選擇一個負載較少的Eureka Server。. 數(shù)據(jù)庫挑戰(zhàn)與策略 每個微服務都有自己獨立的數(shù)據(jù)庫，那么后臺管理的聯(lián)合查詢怎么處理？這應該是大家會普遍遇到的一個問題，有三種處理方案。 版本集成：由統(tǒng)一的集成工具，實現(xiàn)自動化的版本集成，將所有微服務集成到統(tǒng)一的版本發(fā)布包中。 因此，需進行服務名的統(tǒng)一規(guī)劃： 規(guī)劃期統(tǒng)一制定每個服務提供者的服務名或者模塊標示。 為每個服務設計API接口（REST方式） 為不同的服務進行分類，不同類型的服務需要的資源不同，可以配置不同的資源，包括CPU、內(nèi)存、存儲等。 Hystrix，監(jiān)控和斷路器。需要一個服務注冊中心Eureka，所有的服務都在注冊中心注冊，負載均衡也是通過在注冊中心注冊的服務來使用一定策略來實現(xiàn)。216。也就是沒有充分的保障機制，則單點故障會大量增加。多數(shù)情況下是一個HTTP的資源API。這些服務具備獨立業(yè)務能力并可以通過自動化部署方式獨立部署。216。 重復開發(fā)： 微服務理念崇尚每個微服務作為一個產(chǎn)品看待，有自己的團隊開發(fā)，甚至可以有自己完全不同的技術、框架，那么與其他微服務團隊的技術共享就產(chǎn)生了矛盾，重復開發(fā)的工作即產(chǎn)生了。 Eureka可部署多個，進行高可用保證。使用斷路器hystrix，及時處理服務調(diào)用時的超時和錯誤，防止由于其中一個服務的問題而導致整體系統(tǒng)的癱瘓。我們只需要在服務接口上添加Hystrix標簽，就可以實現(xiàn)對這個接口的監(jiān)控和斷路器功能。. 服務拆分原則 粒度微小： 根據(jù)業(yè)務功能劃分服務粒度，總的原則是服務內(nèi)部高內(nèi)聚，服務之間低耦合。 服務名的命名規(guī)則:ModuleName_ServiceName，且所有字符小寫，不同單詞之間以下劃線分隔。. 版本策略 每個微服務可以獨立制作版本，伴隨著服務的增多，SVN分支增多，版本也將增多，版本管理的復雜度將成指數(shù)級增加。 1）嚴格按照微服務的劃分來做，微服務相互獨立，各微服務數(shù)據(jù)庫也獨立，后臺需要展示數(shù)據(jù)時，調(diào)用各微服務的接口來獲取對應的數(shù)據(jù)，再進行數(shù)據(jù)處理后展示出來，這是標準的用法，也是最麻煩的用法。2. 定期從Eureka Server更新并過濾服務實例列表。 RandomRule: 但這也同時帶來了諸多問題，如下： 各服務是否可以任意使用自己的技術、自己的組件、框架呢？如果這樣，勢必帶來更大的管理困難、維護困難、技術共享困難。. 異步調(diào)用 rabbitMq、kafka、Spring Cloud Stream均是可以選擇的方案。但是，如果你想禁止某些header透傳到服務端，：zuul:routes:users: path: /users/** sensitiveHeaders: Cookie,SetCookie,Authorization serviceId: user剛才說了我們的某個服務有時候需要調(diào)用另一個服務，這時候，這個請求不是客戶端發(fā)起，他的請求的header里面也不會有任何驗證信息。比如現(xiàn)在有項目a調(diào)用項目b，項目b調(diào)用項目c...一直到h，是一個調(diào)用鏈，那么項目上線的時候需要先更新最底層的h再更新g...更新c更新b最后是更新項目a。伴隨節(jié)點數(shù)量的增加，如果沒有合適的管理機制與工具，定位問題、發(fā)現(xiàn)問題的
公司管理相關推薦
鄂ICP備17016276號-1