1樓：
這個問題提得好，一開始我學習微服務架構時，就提出了這個問題。當時還真沒很多人回答得好。
微服務架構提倡：每乙個微服務的模組都單獨部署乙個專門屬於他的資料庫。比如支付模組有單獨的資料庫，訂單模組也有單獨的資料庫。
由於資料庫表都不在同乙個庫中，當然可以自由地部署到不同的機器上了。這樣一來，資料庫又何來的效能瓶頸呢？
可是，這樣又帶來乙個問題。我們以前用單一的資料庫時，經常會做表復合查詢。也就是join。
很多業務沒有join怎麼搞？IT行業是沒有銀彈的，我們用分庫分表解決了資料庫的效能問題，必然會給我們帶來了這個難題。這個問題是可以解決的。
我們不是一定要join的，很多時候我們分兩次、三次查也不見得效能會慢很多。慢是慢一點，但是由於我們機器多，每乙個機器併發都不是太多，再加上快取的應用，不會非常慢的。上面第1點可以解決大部分的業務問題。
還有很多業務操作單錶就可以了。不同模組之間需要join的時候並不一定會很多。
可以通過多執行緒的join來併發查詢來解決必須查詢多個庫才可以查到所需要的資料的問題。多個執行緒同時進行，不需要序列，也可以借助mycat,sharding sphere等中介軟體完成；
有一些統計的業務，需要非常多的模組復合查詢才能辦到，這時候應該怎麼辦呢？其實，我們可以有乙個機器建立全量的表。這些資料可以通過非同步機制同步所有模組的資料過來。
由於這個機器只做統計，就不存在併發量大的問題了。
微服務架構不是銀彈。它的確幫助我們解決了網際網路企業中高併發高度擴充套件的問題。但也增加了許多以前沒有出現的工作量。如果你的專案沒有那麼大的併發，還是回歸傳統，不要湊熱鬧。
2樓：Captain
目前各大雲廠商在應對這種場景一般有兩種方案：
1.給資料庫例項新增唯讀節點，比如RDS、PolarDB（計算儲存分離，云原生化），新增多個唯讀例項來提高負載能力。
2.資料庫Serverless化，計算單元更加容易彈性伸縮，不過這類產品相對成熟度較低，一般不建議生產環境使用，但是未來的趨勢。
3樓：Tony
這是個很難的題目。
微服務容易彈性伸縮（scale-out），是因為它是stateless。而資料庫很難，是因為它是stateful。
一般最終解決方案，都是shard，以及如何管理shard（rebalance）。比如：你的資料庫有6個shard，裡面有總共599G資料，你這時想加入乙個node，變成7個shard，同時平衡負載。
這非常複雜。你想象一下就知道這裡面牽涉了很多細節：資料如何在增加的shard裡遷移，外面的服務如何發現shard的變動，以及遷移過程中資料的一致性（比如：
distributed transaction 和 join）
我的另外乙個想法是：能不能在shard前，針對乙個shard，做到彈性伸縮。因為很多時候，我們乙個shard的效能都沒有用盡。這樣就簡化了問題。
可以參考：Tony：BunnyRedis要解決Redis的高可用HA問題
如果乙個shard能支援無限的讀Read，和乙個很高瓶頸的寫Wrie（比如：1G Byte/second），那麼大多數時候，乙個shard就能解決問題。
當然最終，還是多shard的解決方案，不過對這問題，我研究還不夠。
微服務的資料庫怎樣劃分？總不能很多微服務使用同乙個資料庫吧，那不是和單體服務一樣了？
liujunsong 這個問題的沒有標準答案，各家怎麼做的都有，都有道理，都對。要回答這個問題，先要回答另乙個問題，就是，資料庫設計的原則是什麼？或者說資料儲存設計的原則是什麼？而不是把這個問題偷梁換柱成，微服務的資料庫如何劃分，微服務是對外的展現形式，而資料儲存是資料層的儲存設計。這是兩個完全層面...
微服務架構中可以直接使用資料庫作為註冊中心嗎？
小小笑兒 可以的，註冊中心只是為了統一管理服務的註冊資訊，是很多的對。所以說只要是能夠提供儲存和查詢資料的工具都可以用來作為註冊中心。比如你完全可以自己寫乙個 http server 來作為自己的註冊中心 類似 eureka 三觀成型沒法改 可以其實大多數公司連日均8000pv的訪問坎都過不去，my...
微服務的架構模式中，資料庫如何規劃？如果採用獨享資料庫，如何解決事務處理和聯合查詢？
唐陽 首先微服務不是碎服務 別什麼都拆開 真的有需要分布式事務的一般是2 3pc 這裡假設你是mysql 聯合查詢在互分布式資料庫裡面本來就很難做 網際網路服務幾乎不會使用聯合查詢 起名難 以微服務為代表的分布式系統上，不適合事務性操作，因為分布式事務的效率非常的差。所以現在最終一致性的概念越來越受...