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

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

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

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

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

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

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

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

　　三、分布式事務(wù)如何處理

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

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