一、服務拆分的三個維度
三個維度拆分后，微服務的架構圖就如下圖所示：
API GATEWAY服務網關：
身份認證、權限管理、服務動態路由、數據的聚合（比如房產詳情頁就有詳情、評論、推薦，這些都屬於不同的服務，這些我們就需要在服務網關中去做）
Service Register：注冊中心 服務的注冊與發現
注冊與發現：如果是在單體架構中，添加一個實例，一般是在前端反向代理中如Nginx中添加一個實例服務器ip端口。
而在微服務中這種方式就很難滿足多服務的架構，一方面頻繁的修改Nginx配置文件極易出錯，引起整個系統的故障。
另一方面，服務消費者要記錄大量url和ip的配置，管理這些配置非常繁瑣，很難理清他們之間的依賴關系。而且要增加軟硬件的投入。
如果在客戶端配置，就減少了這種投入。服務的注冊與發現在客戶端負載均衡提供了可能。
-
微服務的數據庫可以根據每個服務的特點選擇合適的數據庫，比如Order數據量大，可以選擇Hbase數據庫。也可以根據自己擅長的技術棧來選擇。
二、拆分的原則和步驟
1.拆分的原則
評價架構好壞的原則：可以用變化的成本來衡量。架構的目的就是管理復雜性、易變性和不確定性。
這樣就能在系統演化進程中一部分系統的改變不會影響另一部分的系統。
- 高內聚低耦合，服務粒度適中
- 以業務模型切入
- 演進式拆分
2.拆分的步驟
- 分析業務模型——弱耦合在一起，高內聚
- 確定服務邊界
1）分析業務模型
推薦是對房產進行推薦，所以推薦依賴房產；房產的產權屬於某個用戶，所以房產依賴用戶
經濟人屬於某個經濟機構；經濟人也是一個用戶
評論可以針對博客，也可以針對房產
評論和博客都依賴於用戶
用戶、經濟人、經濟機構是練習比較緊密的，所以可以放到一個服務當中，叫用戶服務。
推薦目前只是針對房產進行推薦，我們可以將推薦和房產放到一起，叫房產服務。
評論和博客放到一起，我們叫評論服務。
最后產生的依賴關系就是：
評論服務依賴於用戶服務
房產服務依賴於用戶服務和評論服務
用戶服務作為底層服務不依賴於其他服務
2）確定服務邊界
評論服務和用戶服務的共享模型是用戶
評論服務需要獲取用戶的頭像、名稱等信息，用戶服務提供接口給評論服務訪問。
用戶服務和房產服務的共享模型是經濟人
房產服務需要從用戶服務那獲取經濟人的一些信息，包含頭像 email 聯系方式等，並不需要密碼等信息，用戶服務提供接口給房產服務訪問。
和單體相比，各個數據庫的表是沒有變化的，但是將數據庫分成了三個
