文章目錄
- 1.認識微服務
-
- 1.1.單體架構
- 1.2.分布式架構
- 1.3.微服務
- 1.4.SpringCloud
- 1.5.總結
- 2.服務拆分和遠端調用
-
- 2.1.服務拆分原則
- 2.2.服務拆分示例
-
- 2.2.1.導入Sql語句
- 2.2.2.導入demo工程
- 2.3.實作遠端調用案例
-
- 2.3.1.案例需求：
- 2.3.2.注冊RestTemplate
- 2.3.3.實作遠端調用
- 2.4.提供者與消費者
1.認識微服務
随着網際網路行業的發展，對服務的要求也越來越高，服務架構也從單體架構逐漸演變為現在流行的微服務架構。這些架構之間有怎樣的差别呢？
1.1.單體架構
單體架構：将業務的所有功能集中在一個項目中開發，打成一個包部署。
單體架構的優缺點如下：
優點：
- 架構簡單
- 部署成本低
缺點：
- 耦合度高（維護困難、更新困難）
1.2.分布式架構
分布式架構：根據業務功能對系統做拆分，每個業務功能子產品作為獨立項目開發，稱為一個服務。
分布式架構的優缺點：
優點：
- 降低服務耦合
- 有利于服務更新和拓展
缺點：
- 服務調用關系錯綜複雜
分布式架構雖然降低了服務耦合，但是服務拆分時也有很多問題需要思考：
- 服務拆分的粒度如何界定？
- 服務之間如何調用？
- 服務的調用關系如何管理？
人們需要制定一套行之有效的标準來限制分布式架構。
1.3.微服務
微服務的架構特征：
- 單一職責：微服務拆分粒度更小，每一個服務都對應唯一的業務能力，做到單一職責
- 自治：團隊獨立、技術獨立、資料獨立，獨立部署和傳遞
- 面向服務：服務提供統一标準的接口，與語言和技術無關
- 隔離性強：服務調用做好隔離、容錯、降級，避免出現級聯問題
微服務的上述特性其實是在給分布式架構制定一個标準，進一步降低服務之間的耦合度，提供服務的獨立性和靈活性。做到高内聚，低耦合。
是以，可以認為微服務是一種經過良好架構設計的分布式架構方案 。
但方案該怎麼落地？選用什麼樣的技術棧？全球的網際網路公司都在積極嘗試自己的微服務落地方案。
其中在Java領域最引人注目的就是SpringCloud提供的方案了。
1.4.SpringCloud
SpringCloud是目前國内使用最廣泛的微服務架構。
官網位址：https://spring.io/projects/spring-cloud。
SpringCloud內建了各種微服務功能元件，并基于SpringBoot實作了這些元件的自動裝配，進而提供了良好的開箱即用體驗。
其中常見的元件包括：
另外，SpringCloud底層是依賴于SpringBoot的，并且有版本的相容關系，如下：
我們這裡使用的版本是 Hoxton.SR10，是以對應的SpringBoot版本是2.3.x版本。
1.5.總結
- 單體架構：簡單友善，高度耦合，擴充性差，适合小型項目。例如：學生管理系統
- 分布式架構：松耦合，擴充性好，但架構複雜，難度大。适合大型網際網路項目，例如：京東、淘寶
-
微服務：一種良好的分布式架構方案
①優點：拆分粒度更小、服務更獨立、耦合度更低
②缺點：架構非常複雜，運維、監控、部署難度提高
- SpringCloud是微服務架構的一站式解決方案，內建了各種優秀微服務功能元件
2.服務拆分和遠端調用
任何分布式架構都離不開服務的拆分，微服務也是一樣。
2.1.服務拆分原則
這裡我總結了微服務拆分時的幾個原則：
- 不同微服務，不要重複開發相同業務
- 微服務資料獨立，不要通路其它微服務的資料庫
- 微服務可以将自己的業務暴露為接口，供其它微服務調用
2.2.服務拆分示例
接下去我們以微服務cloud-demo為例，其結構如下：
cloud-demo：父工程，管理依賴
- order-service：訂單微服務，負責訂單相關業務
- user-service：使用者微服務，負責使用者相關業務
要求：
- 訂單微服務和使用者微服務都必須有各自的資料庫，互相獨立
- 訂單服務和使用者服務都對外暴露Restful的接口
- 訂單服務如果需要查詢使用者資訊，隻能調用使用者服務的Restful接口，不能查詢使用者資料庫
2.2.1.導入Sql語句
cloud-user表中初始資料如下：
cloud-order表中初始資料如下：
cloud-order表中持有cloud-user表中的id字段。
2.2.2.導入demo工程
用IDEA導入Demo，項目結構如下：
導入後，會在IDEA右下角出現彈窗：
點選彈窗，然後按下圖選擇：
會出現這樣的菜單：
配置下項目使用的JDK：
2.3.實作遠端調用案例
在order-service服務中，有一個根據id查詢訂單的接口：
根據id查詢訂單，傳回值是Order對象，如圖：
其中的user為null
在user-service中有一個根據id查詢使用者的接口：
查詢的結果如圖：
2.3.1.案例需求：
修改order-service中的根據id查詢訂單業務，要求在查詢訂單的同時，根據訂單中包含的userId查詢出使用者資訊，一起傳回。
是以，我們需要在order-service中 向user-service發起一個http的請求，調用http://localhost:8081/user/{userId}這個接口。
大概的步驟是這樣的：
- 注冊一個RestTemplate的執行個體到Spring容器
- 修改order-service服務中的OrderService類中的queryOrderById方法，根據Order對象中的userId查詢User
- 将查詢的User填充到Order對象，一起傳回
2.3.2.注冊RestTemplate
首先，我們在order-service服務中的OrderApplication啟動類中，注冊RestTemplate執行個體：
package cn.itcast.order;
import org.mybatis.spring.annotation.MapperScan;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.annotation.Bean;
import org.springframework.web.client.RestTemplate;
@MapperScan("cn.itcast.order.mapper")
@SpringBootApplication
public class OrderApplication {
public static void main(String[] args) {
SpringApplication.run(OrderApplication.class, args);
}
@Bean
public RestTemplate restTemplate() {
return new RestTemplate();
}
}
2.3.3.實作遠端調用
修改order-service服務中的cn.itcast.order.service包下的OrderService類中的queryOrderById方法：
這裡使用了restTemplate的getForObject方法
OK，這裡我們運作程式，查詢order訂單中是否可以遠端調用userService中的服務資訊。
可以看到，這裡已經實作了遠端調功能。
2.4.提供者與消費者
在服務調用關系中，會有兩個不同的角色：
服務提供者：一次業務中，被其它微服務調用的服務。（提供接口給其它微服務）
服務消費者：一次業務中，調用其它微服務的服務。（調用其它微服務提供的接口）
但是，服務提供者與服務消費者的角色并不是絕對的，而是相對于業務而言。
如果服務A調用了服務B，而服務B又調用了服務C，服務B的角色是什麼？
- 對于A調用B的業務而言：A是服務消費者，B是服務提供者
- 對于B調用C的業務而言：B是服務消費者，C是服務提供者
是以，服務B既可以是服務提供者，也可以是服務消費者。
OK，微服務入門我們就先介紹到這裡，接下去我們會介紹SpringCloud的Eureka注冊中心，Ribbon負載均衡以及Nacos注冊中心以及它們之間的差別。