最近這幾年，微服務已經(jīng)成為了主流，微服務這個東西，固然是有它的優(yōu)點，但是如果你用不好，就會成為災難。什么樣的系統(tǒng)適合做微服務?分布式事務如何處理?想要用好微服務，就一定要注意一下三點。

　　一、什么樣的系統(tǒng)適合做微服務

　　微服務這個東西固然好，但是并不是所有的系統(tǒng)都適合做微服務，現(xiàn)在很多人有這樣一個心理，看到一款技術(shù)框架很流行，大家都在用，那我為了追求時髦，我一定也要在項目里用一下。這種心理要不得，一定要去評估這款新的框架但適不適合你的系統(tǒng)的，如果不適合，你就會得到適得其反的效果。作為微服務來講，一般來說如果項目不是特別大，訪問量也沒有那么大，就千萬不要去做微服務。只有說你的系統(tǒng)大到一定程度了，在一個項目里很難維護了，這時候你再去考慮去做微服務。

　　二、微服務要依據(jù)什么樣的選擇對系統(tǒng)做拆分

　　系統(tǒng)拆分原則，這個并沒有在業(yè)界形成統(tǒng)一的標準，每個人都有自己的想法，在這里我只是說一下自己總結(jié)的一些看法

　　1.如果兩個子系統(tǒng)之間，需要保證事務的強一致性，那你就不要去拆了，因為現(xiàn)在沒有任何一種方案，能保證事務的強一致性的，即便是阿里的seta，也不能保證強一致性，我們只能保證它的最終一致性，盡最大努力去減小數(shù)據(jù)不一致的時間，如果允許數(shù)據(jù)可以短時間的不一致，沒太大影響，就可以做拆分，如果說數(shù)據(jù)段時間的不一致，也會帶來很大損失，那就不要去拆了。

　　2.避免任意兩個系統(tǒng)之間，特別頻繁的調(diào)用。我第一次在做微服務的時候，拆分出了一個權(quán)限系統(tǒng)，這個系統(tǒng)負責用戶的登錄，權(quán)限分配，權(quán)限驗證和session等等，但是考慮到，一個用戶登錄成功的，塔操作的所有功能，都要去調(diào)用這個系統(tǒng)去做session驗證和權(quán)限驗證，這樣不僅僅會影響效率，也會給這個系統(tǒng)帶來很大壓力。后來的解決方案是，我們還是拆分出了這個權(quán)限系統(tǒng)，只不過我們在做session驗證和權(quán)限驗證時，不會直接去調(diào)用這個系統(tǒng)，而是用maven把對應的jar包依賴過，做本地調(diào)用。

　　3.在保證上面兩點的基礎(chǔ)上，盡量按照單一職責的原則去拆分，做到低耦合，高內(nèi)聚。

　　三、分布式事務如何處理

　　這個現(xiàn)在沒有一種方案，能做到事務的強一致性，我們只能盡最大努力減少數(shù)據(jù)不一致的時間，來保證它的最終一致性，這個上網(wǎng)去查，能查到很多方案，什么兩階段提交，三階段提交，寫回滾代碼，等等，但是在真實寫代碼的過程中，沒人會這么做的，因為它不僅性能差，而且會增加很多工作量?，F(xiàn)在比較成熟的做法是用阿里的seta框架，它的原理就是記錄了一張日志表，當需要做數(shù)據(jù)回滾的時候，就根據(jù)這張日志表的數(shù)據(jù)去做回滾，但是如果回滾的時候出現(xiàn)了網(wǎng)絡(luò)問題，或者出現(xiàn)了臟寫，依然會回滾失敗，這種情況就需要人工處理。這也就是我說的阿里么seata并不能百分之百的保證事務強一致性的原因。

　　總結(jié)：以上就是小編對什么樣的系統(tǒng)適合做微服務的一些不同見解,如您對什么樣的系統(tǒng)適合做微服務有任何疑問，請給我們留言或者聯(lián)系我們的在線客服人員， 巨海為您提供搜索營銷一站式企業(yè)服務!可以讓潛在有需求的客戶及時找到你，讓你的網(wǎng)站擁有很多精準流量訪問!