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

　　一、什么樣的系統適合做微服務

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

　　二、微服務要依據什么樣的選擇對系統做拆分

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

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

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

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

　　三、分布式事務如何處理

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

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