SpringCloud 微服務 (五) 隨筆

微服務最近比較流行,而後你們都去用他了,新項目也好,老項目也好,程序員嘛,對新的技術,新的風格有追求是很好的表現,但也不能盲目直衝,話又說回來了,學了不用搞毛線html

本篇總結一下新應用場景與老項目轉微服務應用狀況node

 

案件發生地 : 新系統 、老項目程序員

動機 : 往前看,跟着新潮流 . 外帶點嚐鮮,裝逼行爲數據庫

調查 : 若是是老項目的話,現有的架構是個什麼存在,是否適合微服務架構,轉向是否合理,就像皮卡丘不進化會更好看,小火龍進化了能飛,固然進化了能力都會有提高,也會有缺點.服務器

發展 : 從架構發展 ORM 到 MVC 到 RPC 再到 SOA數據結構

ORM 單一應用架構 : 當應用流量很小或只給內部人員小應用,將全部功能都部署在一塊兒,減小部署節點和成本,方便; ORM框架就能夠站擼架構

MVC 垂直應用架構 : 當應用流量會變更的擴大,將應用垂直拆分紅幾個不相干的依賴層,提高效率負載均衡

RPC 分佈式服務架構 : 當垂直應用愈來愈多,交互變得複雜,將各個核心業務水平拆分爲獨立的服務,組建服務中心,能更快速的響應多變的需求(不少時候須要垂直水平一塊兒完成構建)框架

SOA 面向服務架構 : 這個不說了,mark(ESB),自我擴展.分佈式

 

另外須要瞭解的是分佈式事務CAP,是企業集成中的一個技術難點,也是每個分佈式系統架構中都會涉及到的東西,特別是在微服務架構中不可避免,若是老項目轉微服務,這點是否符合?

關於CAP能夠參考下面一片文章, banner是伊利丹,做爲一個wower,都懂得

https://www.cnblogs.com/savorboard/p/distributed-system-transaction-consistency.html

 

若是項目已經很穩定的運行了,建議就不要去改他了,要麼公司太有錢了,要麼人太閒了

什麼老的OA系統啊,就給固定的某個部門使用的,也不必動用微服務了

一些流量小的應用也同樣,不必了,固然每一個boss都會認爲個人東西是最好的,怎麼可能沒人用

寫到這裏,感慨: boss永遠是最後一個知道公司要倒閉的人,心痛個人錢...

 

服務拆分

第一點 多節點擴展: 利用負載均衡將多個同樣的應用, 來控制應用的擴展收縮能力,調控容器與可用性

第二點 數據分區: 這個比較直白,每一個服務器負責一個數據的子集,每一個服務器運行的應用是同樣的

第三點 功能解耦: 將不一樣的模塊分紅不一樣的服務

 

不得不提到 單一職責,一個服務只作一件事情

服務與服務之間,修改一個不用致使須要修改一連串的其餘服務,而且A服務中的功能,都應該在A服務中,這兩點實現 低耦合,高內聚

若是拆分微服務的時候,改動一個,引發一連串的事件須要改動的話,說明是項目拆分不合理

 

按業務劃分職責,通常會比較明顯體現,是一種方式,好比訂單,商品,發票;

還能夠劃分一些與業務不相關的第三方服務組件,好比發送消息,郵件;

怎麼拆分,拆分到多細,我以爲凡事無絕對,並非拆的越細越好,看場景需求

 

拆分先考慮功能,後考慮數據

從單一項目拆分的時候,都會遇到一種狀況, 若是一個A數據,同時被B,C服務共用,才能完成一次接口任務,那麼A數據稱爲狀態,依賴A數據的服務稱爲狀態服務,拆分的時候須要將狀態服務轉化爲無狀態服務,關注點分離(mark: 領域驅動設計)

 

拆數據

每一個微服務都有各自的數據存儲,若是微服務共享一個數據存儲,會提升耦合,改動一個服務的數據結構,可能會致使牽動另外一個微服務的數據存儲,應當避免直接訪問其餘微服務的數據存儲,從另外一個服務提供的API來獲取接口結果,服務之間存在隔離,即下降耦合.

能夠依據不一樣的微服務特色來選擇不一樣結構功能的數據存儲,好比前置開發展現類型的服務,使用node開發,數據的類型不少,對事務要求不高,能夠選擇NoSQL的MongoDB存儲; 搜索類型的服務,能夠選擇ElasticSearch存儲; 對事務要求高的服務,能夠考慮即時關係型數據庫,最多見的MySql; 

數據劃分考慮,設計API

不少時候,由於項目比較複雜,接口API提供的或多或少的數據都存在冗餘或者缺省,好比都會有的user用戶表,幾乎全部服務都存在這麼一個表,user表中有用戶的基礎信息,名字,手機,密碼等等,如今user對外暴露接口,來了一個支付服務,支付服務訪問user提供的API的時候,更關注user的開啓關閉,是否被禁用,用戶使用支付的方式等等,其餘信息則不須要;來了一個快遞服務,則更關注user的手機號,地址等等,其餘也不須要;

有的時候,咱們須要獲得user的數據,能夠在其餘服務數據存儲中也存一份,好比冗餘數據,那麼須要保證另個服務冗餘數據和原服務數據的一致性,否則一個user手機號換了,快遞服務上一直沒變,就找不到人了

 

--------------------------------------------------------------

相關文章
相關標籤/搜索