服務拆分
對單體架構項目來說：簡單友善，高度耦合，擴充性差，适合小型項目。
而對于分布式架構來說：低耦合，擴充性好，但架構複雜，難度大。
微服務就是一種良好的分布式架構方案：
①優點：拆分粒度更小、服務更獨立、耦合度更低
②缺點：架構非常複雜，運維、監控、部署難度提高
SpringCloud是微服務架構的一站式解決方案，內建了各種優秀微服務功能元件。
微服務拆分時的幾個原則：
不同微服務，不要重複開發相同業務
微服務資料獨立，不要通路其它微服務的資料庫
微服務可以将自己的業務暴露為接口，供其它微服務調用
拆分案列：
cloud-demo是父工程，是用來管理依賴的。
order-service：訂單微服務，負責訂單相關業務
user-service：使用者微服務，負責使用者相關業務
要求：
- 訂單微服務和使用者微服務都必須有各自的資料庫，互相獨立
- 訂單服務和使用者服務都對外暴露Restful的接口
- 訂單服務如果需要查詢使用者資訊，隻能調用使用者服務的Restful接口，不能查詢使用者資料庫
實作遠端調用
在order-service服務中，有一個根據id查詢訂單的接口，根據id查詢訂單，傳回值是Order對象，如圖，其中的user為null。
在user-service中有一個根據id查詢使用者的接口：
查詢結果：
現在通過實作遠端調用，在查詢訂單的同時，根據訂單中包含的userId查詢出使用者資訊，一起傳回。
是以，我們需要在order-service中 向user-service發起一個http的請求，調用http://localhost:8081/user/{userId}這個接口。
大概的步驟是這樣的：
- 注冊一個RestTemplate的執行個體到Spring容器
- 修改order-service服務中的OrderService類中的queryOrderById方法，根據Order對象中的userId查詢User
- 将查詢的User填充到Order對象，一起傳回
注冊RestTemplate
在order-service服務中的OrderApplication啟動類中，注冊RestTemplate執行個體：
修改order-service服務中的cn.itcast.order.service包下的OrderService類中的queryOrderById方法：
查詢結果：
假如我們的服務提供者user-service部署了多個執行個體，那麼
order-service在發起遠端調用的時候，該如何得知user-service執行個體的ip位址和端口？
有多個user-service執行個體位址，order-service調用時該如何選擇？
order-service如何得知某個user-service執行個體是否依然健康，是不是已經當機？
上述問題将在注冊中心中可以得到解決，接下來還會繼續介紹關于Eureka注冊中心和Nacos注冊中心。