1樓：小小笑兒
可以的，註冊中心只是為了統一管理服務的註冊資訊，是很多的對。所以說只要是能夠提供儲存和查詢資料的工具都可以用來作為註冊中心。比如你完全可以自己寫乙個 http server 來作為自己的註冊中心（類似 eureka）。
2樓：三觀成型沒法改
可以其實大多數公司連日均8000pv的訪問坎都過不去，mysql綽綽有餘，上微服務是為了未來打基礎，但是在實施難度和維護成本略高的情況下，降低部分架構的設計完全沒問題。
做架構不需要非得所有技術選型都那麼高大上，確保設計可擴充套件就可以了。
你這一句話裡，最大的坑是那個redis，soa下用redis一定要妥善小心.......
3樓：商傑
資料庫這個詞太寬泛，其實你要說的應該是，是否可以拿關係型資料庫來完成服務的註冊機制。答案是可以。。但是不好。
首先要弄清楚關係型資料庫是幹什麼的，當然是存關係型資料的了，資料之間關聯性很大的業務資料。但是註冊中心存放的大多數是路由資料，其實也就是物件資料，不需要複雜的關係模型，但是需要極高的訪問效率。這是好弄個mysql行不行，當然行。
但是用其他的這些物件型資料庫更好。僅此而已。
微服務的架構模式中，資料庫如何規劃？如果採用獨享資料庫，如何解決事務處理和聯合查詢？
唐陽 首先微服務不是碎服務 別什麼都拆開 真的有需要分布式事務的一般是2 3pc 這裡假設你是mysql 聯合查詢在互分布式資料庫裡面本來就很難做 網際網路服務幾乎不會使用聯合查詢 起名難 以微服務為代表的分布式系統上，不適合事務性操作，因為分布式事務的效率非常的差。所以現在最終一致性的概念越來越受...
微服務的資料庫怎樣劃分？總不能很多微服務使用同乙個資料庫吧，那不是和單體服務一樣了？
liujunsong 這個問題的沒有標準答案，各家怎麼做的都有，都有道理，都對。要回答這個問題，先要回答另乙個問題，就是，資料庫設計的原則是什麼？或者說資料儲存設計的原則是什麼？而不是把這個問題偷梁換柱成，微服務的資料庫如何劃分，微服務是對外的展現形式，而資料儲存是資料層的儲存設計。這是兩個完全層面...
微服務彈性伸縮時，資料庫怎麼彈性呢？
這個問題提得好，一開始我學習微服務架構時，就提出了這個問題。當時還真沒很多人回答得好。微服務架構提倡 每乙個微服務的模組都單獨部署乙個專門屬於他的資料庫。比如支付模組有單獨的資料庫，訂單模組也有單獨的資料庫。由於資料庫表都不在同乙個庫中，當然可以自由地部署到不同的機器上了。這樣一來，資料庫又何來的效...