1樓：liujunsong
這個問題的沒有標準答案，各家怎麼做的都有，都有道理，都對。
要回答這個問題，先要回答另乙個問題，就是，資料庫設計的原則是什麼？或者說資料儲存設計的原則是什麼？而不是把這個問題偷梁換柱成，微服務的資料庫如何劃分，微服務是對外的展現形式，而資料儲存是資料層的儲存設計。
這是兩個完全層面的問題，把這兩個問題混在一起，就混淆了基本概念。
回到資料庫設計或者資料儲存設計的問題。第乙個問題就是，準備選用分布式的資料儲存設計，還是選用集中式的資料儲存設計，還是選用主體集中式儲存，加上資料分發的分布式儲存設計。
第二個問題是，資料儲存設計的時候，是採用第三正規化為原則設計，還是選用資料倉儲模式進行設計。也就是選用關係網狀模型，還是採用事實維度模型。
第三個問題是，這個系統設計主要是事務性的系統，還是查詢型的系統，或者說，是olap的還是oltp的。
在把上面三個問題都解答以後，下一步才能走向儲存產品的選型，資料同步方案的制定，分布式事務方案的設計，然後才到程式設計這一步，才能到微服務如何和他們結合一起工作的問題。
現在的大部分公司受網際網路行業的影響，已經沒有專門的dba這個崗位了，所以以前屬於資料架構師需要分析解決的問題，現在一股腦推給應用架構師來嘗試解決。卻缺乏最基本的理論知識儲備。瞎搞。
微服務彈性伸縮時，資料庫怎麼彈性呢？
這個問題提得好，一開始我學習微服務架構時，就提出了這個問題。當時還真沒很多人回答得好。微服務架構提倡 每乙個微服務的模組都單獨部署乙個專門屬於他的資料庫。比如支付模組有單獨的資料庫，訂單模組也有單獨的資料庫。由於資料庫表都不在同乙個庫中，當然可以自由地部署到不同的機器上了。這樣一來，資料庫又何來的效...
微服務架構中可以直接使用資料庫作為註冊中心嗎？
小小笑兒 可以的，註冊中心只是為了統一管理服務的註冊資訊，是很多的對。所以說只要是能夠提供儲存和查詢資料的工具都可以用來作為註冊中心。比如你完全可以自己寫乙個 http server 來作為自己的註冊中心 類似 eureka 三觀成型沒法改 可以其實大多數公司連日均8000pv的訪問坎都過不去，my...
微服務的架構模式中，資料庫如何規劃？如果採用獨享資料庫，如何解決事務處理和聯合查詢？
唐陽 首先微服務不是碎服務 別什麼都拆開 真的有需要分布式事務的一般是2 3pc 這裡假設你是mysql 聯合查詢在互分布式資料庫裡面本來就很難做 網際網路服務幾乎不會使用聯合查詢 起名難 以微服務為代表的分布式系統上，不適合事務性操作，因為分布式事務的效率非常的差。所以現在最終一致性的概念越來越受...