一篇帶個你Spring Cloud微服務架構(gòu)學習
一、分布式服務框架的發(fā)展
1.1 第一代服務框架
代表：Dubbo(Java)、Orleans(.Net)等
特點：和語言綁定緊密
1.2 第二代服務框架
代表：Spring Cloud等
現(xiàn)狀：適合混合式開發(fā)(例如借助Steeltoe OSS可以讓ASP.Net Core與Spring Cloud集成)，正值當年
1.3 第三代服務框架
代表：Service Mesh(服務網(wǎng)格) => 例如Service Fabric、lstio、Linkerd、Conduit等
現(xiàn)狀：在快速發(fā)展中，更新迭代比較快
1.4 未來(目測不久)主流的服務架構(gòu)和技術(shù)棧
基礎的云平臺為微服務提供了資源能力(計算、存儲和網(wǎng)絡等)，容器作為最小工作單元被Kubernetes調(diào)度和編排，Service Mesh(服務網(wǎng)格)管理微服務的服務通信，最后通過API Gateway向外暴露微服務的業(yè)務接口。
目前，我所在的項目組已經(jīng)在采用這種技術(shù)架構(gòu)了，服務網(wǎng)格采用的是Linkerd，容器編排采用的是K8S，Spring Cloud已經(jīng)沒用了。But，不代表Spring Cloud沒有學習的意義，對于中小型項目團隊，Spring Cloud仍然是快速首選。
二、Spring Cloud 簡介
2.1 Spring Cloud極簡介紹
首先，盡管Spring Cloud帶有“Cloud”這個單詞，但它并不是云計算解決方案，而是在Spring Boot基礎之上構(gòu)建的，用于快速構(gòu)建分布式系統(tǒng)的通用模式的工具集。
其次，使用Spring Cloud開發(fā)的應用程序非常適合在Docker和PaaS(比如Pivotal Cloud Foundry)上部署，所以又叫做云原生應用(Cloud Native Application)。云原生可以簡單地理解為面向云環(huán)境的軟件架構(gòu)。
總結(jié) ：Spring Cloud是一個基于Spring Boot實現(xiàn)的云原生應用開發(fā)工具，它為基于JVM的云原生應用開發(fā)中涉及的配置管理、服務發(fā)現(xiàn)、熔斷器、智能路由、微代理、控制總線、分布式會話和集群狀態(tài)管理等操作提供了一種簡單的開發(fā)方式。
Spring Cloud具有如下特點：
約定大于配置
適用于各種環(huán)境
隱藏了組件的復雜性，并提供聲明式、無XML式的配置方式
開箱即用，快速啟動
組件豐富，功能齊全
......
Spring Cloud作為第二代微服務的代表性框架，已經(jīng)在國內(nèi)眾多大中小型的公司有實際應用案例。許多公司的業(yè)務線全部擁抱Spring Cloud，部分公司選擇部分擁抱Spring Cloud。例如，拍拍貸資深架構(gòu)師楊波老師就根據(jù)自己的實際經(jīng)驗以及對Spring Cloud的深入調(diào)研，并結(jié)合國內(nèi)一線互聯(lián)網(wǎng)大廠的開源項目應用實踐結(jié)果，認為Spring Cloud技術(shù)棧中的有些組件離生產(chǎn)級開發(fā)尚有一定距離，最后提出了一個可供中小團隊參考的微服務架構(gòu)技術(shù)棧，又被稱為“中國特色的微服務架構(gòu)技術(shù)棧1.0”：
上圖中涉及到的組件，這里不做具體介紹
2.2 Spring Cloud核心子項目
Spring Cloud Netflix：核心組件，可以對多個Netflix OSS開源套件進行整合，包括以下幾個組件：
- Eureka：服務治理組件，包含服務注冊與發(fā)現(xiàn)
- Hystrix：容錯管理組件，實現(xiàn)了熔斷器
- Ribbon：客戶端負載均衡的服務調(diào)用組件
- Feign：基于Ribbon和Hystrix的聲明式服務調(diào)用組件
- Zuul：網(wǎng)關(guān)組件，提供智能路由、訪問過濾等功能
- Archaius：外部化配置組件
- Spring Cloud Config：配置管理工具，實現(xiàn)應用配置的外部化存儲，支持客戶端配置信息刷新、加密/解密配置內(nèi)容等。
- Spring Cloud Bus：事件、消息總線，用于傳播集群中的狀態(tài)變化或事件，以及觸發(fā)后續(xù)的處理
- Spring Cloud Security：基于spring security的安全工具包，為我們的應用程序添加安全控制
- Spring Cloud Consul : 封裝了Consul操作，Consul是一個服務發(fā)現(xiàn)與配置工具(與Eureka作用類似)，與Docker容器可以無縫集成
- ......
三、示例結(jié)構(gòu)說明
3.1 示例環(huán)境版本
- Java : JDK & JRE 1.8 8u151
- Spring Boot : 1.5.15.RELEASE
Spring Cloud : Edgware.SR3 (小貼士：Spring Cloud的版本命名是以倫敦地鐵站的名字來命名的)
3.2 示例地址與結(jié)構(gòu)說明
示例
3.2.1 服務注冊與發(fā)現(xiàn) - 基于Eureka
此部分示例位于：part1_service-register-discovery
此部分示例主要演示了如何基于Eureka實現(xiàn)服務的注冊與發(fā)現(xiàn)，其中包括兩個版本：
① 單節(jié)點版本 (開發(fā)環(huán)境調(diào)試用) => 位于eureka-service-sn (sn代表single node)項目內(nèi)
這里需要注意的地方是：在開發(fā)環(huán)境需要關(guān)閉Eureka的自我保護機制，不然你無法輕易看到服務移除的效果，需要在application.yml中如下設置：
- eureka:
- server:
- enableSelfPreservation: false # 本地調(diào)試環(huán)境下關(guān)閉自我保護機制
這是因為Eureka考慮到生產(chǎn)環(huán)境中可能存在的網(wǎng)絡分區(qū)故障，會導致微服務與Eureka Server之間無法正常通信。它的架構(gòu)哲學是寧可同時保留所有微服務(健康的微服務和不健康的微服務都會保留)，也不盲目注銷任何健康的微服務。
② HA多節(jié)點版本 (部署/生產(chǎn)環(huán)境用) => 位于eureka-service-ha-1 & eureka-service-ha-2這兩個項目內(nèi)
此版本需要注意的是兩個節(jié)點的application.yml保持一致，但由于其中使用了peer1和peer2的hostname，在本地開發(fā)環(huán)境需要給Windows(我假設你使用的是Windows系統(tǒng))設置hosts文件如下：
- 127.0.0.1 peer1 peer2
擴展：除了Eureka之外，還可以選擇通用型較強的Consul，關(guān)于Consul的基本概念與服務端的安裝配置可以看看我的這一篇《.Net Core微服務之基于Consul實現(xiàn)服務注冊于發(fā)現(xiàn)》了解一下。最后，不得不說，Spring Boot 和 Spring Cloud中核心組件封裝的注解真的是太強大了，很多操作一個注解直接搞定，無須過多的coding。
3.2.2 客戶端負載均衡 - 基于Ribbon
此部分示例位于：part2_ client-load-balance
此部分示例主要演示了如何基于Ribbon實現(xiàn)客戶端的負載均衡，建議啟動方式：先啟動Eureka，再啟動UserService和MovieService。通過訪問MovieService的API接口 /log-instance 進行日志查看，測試結(jié)果如下圖所示：
從上圖可以看出，通過客戶端的負載均衡算法，依次訪問了不同的服務節(jié)點。
3.2.3 聲明式REST調(diào)用 - 基于Feign
此部分示例位于：part3_feign
此部分示例主要演示了基于Feign如何實現(xiàn)聲明式調(diào)用，包括以下內(nèi)容：
(1)基本整合Feign進行單參數(shù)與多參數(shù)的請求：位于movie-service這個項目內(nèi)
需要注意的就是別忘了在啟動類加上@EnableFeignClients注解
- @SpringBootApplication
- @EnableDiscoveryClient
- @EnableFeignClients // 要使用Feign，需要加上此注解
- public static void main(String[] args) {
- SpringApplication.run (MovieServiceApplication.class, args);
- }
- }
(2)自定義Feign配置的使用：位于movie-service -feign-customizing這個項目內(nèi)
下面的Feign接口就使用了自定義的配置類FeignConfiguration。
- @FeignClient(name = "user-service", configuration = FeignConfiguration.class)
- public interface UserFeignClient {
- /**
- * 使用feign自帶的注解@RequestLine
- * @see https://github.com/OpenFeign/feign
- * @param id 用戶id
- * @return 用戶信息
- */
- @RequestLine("GET /{id}")
- User findById(@Param("id") Long id);
- }
(3)Feign的日志的使用：位于movie-service-feign-logging這個項目內(nèi)
需要注意的是：Feign雖然提供了logger，但是其日志打印只會對DEBUG級別做出響應。日志級別一共有4種類型，如下所示：
Logger.Level 可選值：
* NONE: 不記錄任何日志(默認值)
* BASIC: 僅記錄請求方法、URL、響應狀態(tài)碼以及執(zhí)行時間
* HEADERS: 記錄BASIC級別的基礎之上，記錄請求和響應的header
* FULL: 記錄請求和響應的header，body和元數(shù)據(jù)
要輸出日志打印，application.yml內(nèi)要設置DEBUG級別：
- logging:
- level:
- # 將Feign接口的日志級別設置為DEBUG，因為Feign的Logger.Level只針對DEBUG做出響應
- com.mbps.cd.movieservice .feign.UserFeignClient: DEBUG
最后，針對FULL級別的日志打印效果如下圖所示：
3.2.4 容錯處理 - 基于Hystrix
此部分示例位于：part4_hystrix
此部分示例主要演示如何基于Hystrix實現(xiàn)容錯處理，主要包括以下內(nèi)容：
(1)通用方式整合Hystrix：此示例位于movie-service項目中
針對普通的方法，只需加上HystrixCommand注解及定義回退方法即可，例如：
- @HystrixCommand (fallbackMethod = "findByIdFallback")
- @GetMapping(value = "/user/{id}")
- public User findById (@PathVariable Long id) {
- return restTemplate.getForObject ("http://user-service/" + id, User.class);
- public User findByIdFallback(Long id){
- User user = new User();
- user.setId(-1L);
- user.setUsername("Default User");
- return user;
- }
(2)Feign使用Hystrix：此示例位于movie-service-feign-hystrix項目中
針對Feign，它是以接口形式工作的，好在Spring Cloud已默認為Feign整合了Hystrix，不過默認是關(guān)閉的，需要手動在配置文件中開啟：
- feign:
- hystrix:
- enabled: true
在之前的版本(Dalston之前的版本)中是默認開啟的，至于為何要改為默認禁用，可以看看 這里 ：
然后直接在FeignClient注解中加入fallback屬性即可，例如下面所示：
- @FeignClient (name = "user-service", fallback = FeignClientFallback.class)
- public interface UserFeignClient {
- @GetMapping(value = "/{id}")
- User findById(@PathVariable("id") Long id);
- @Component
- class FeignClientFallback implements UserFeignClient{
- @Override
- public User findById(Long id) {
- User user = new User();
- user.setId(-1L);
- user.setUsername("Default User");
- return user;
- }
- }
如果想要在Feign發(fā)生回退時能夠留下日志供查看回退原因，那么可以使用FallbackFactory，示例項目：movie-service -feign-fallback-factory.
- @FeignClient(name = "user-service", fallbackFactory = FeignClientFallbackFactory.class)
- public interface UserFeignClient {
- @GetMapping(value = "/{id}")
- User findById (@PathVariable("id") Long id);
- @Component
- class FeignClientFallbackFactory implements FallbackFactory {
- private static final Logger LOGGER =
- LoggerFactory.getLogger (FeignClientFallbackFactory.class);
- @Override
- public UserFeignClient create(Throwable cause) {
- return new UserFeignClient() {
- @Override
- public User findById(Long id) {
- /*
- * 日志最好放在各個fallback中，而不要直接放在create方法中
- * 否則在引用啟動時，就會打印該日志
- */
- FeignClientFallbackFactory.LOGGER.info ("sorry, fallback. reason was: ", cause);
- User user = new User();
- user.setId(-1L);
- user.setUsername("Default Username");
- return user;
- }
- };
- }
- }
當發(fā)生回退時，日志輸出信息如下：
除此之外，關(guān)于Hystrix部分，還有監(jiān)控的主題，這里由于我所在的項目組的技術(shù)架構(gòu)中不會涉及到，也就沒有弄，有興趣的童鞋可以關(guān)注一下Hystrix自帶的監(jiān)控以及基于Turbine的聚合監(jiān)控。參考文章：《Hystrix監(jiān)控面板(Dalston版)》與《Hystrix監(jiān)控數(shù)據(jù)聚合》。
3.2.5 API網(wǎng)關(guān) - 基于Zuul
此部分示例位于：part5_zuul
此部分示例主要演示如何基于Zuul實現(xiàn)API網(wǎng)關(guān)，主要包括以下內(nèi)容：
(1)整合Zuul編寫API網(wǎng)關(guān)：位于zuul-service項目中
可以測試驗證的內(nèi)容：
路由規(guī)則：依次啟動eureka，user-service，movie-service，zuul-service，然后通過zuul訪問user-service接口
負載均衡：依次啟動eureka，多個user-service，zuul-service，然后多次訪問user-service，最后查看日志信息(兩個user-service都會打印hibernate日志信息)，驗證是否達到負載均衡的效果。PS：Zuul內(nèi)置了Ribbon來實現(xiàn)負載均衡。
路由端點：依次啟動eureka，user-service，movie-service，zuul-service，然后瀏覽器訪問zuul-service(http://localhost:5000/routes)可以得到路由端點信息
對于路由端點，需要改一下以下配置，才能正常顯示路由端點信息，否則會報401的錯誤：
- management:
- security:
- enabled: false # 默認為true，改為false以便可以看到routes
- 路由配置：示例主要演示了路由前綴、全局敏感設置以及路由規(guī)則設置
- 大文件上傳設置：針對超大文件上傳(比如500M)，需要在Zuul中提升超時設置
- # 下面的設置針對超大文件上傳(比如500M)，提升了超時設置
- hystrix:
- command:
- default:
- execution:
- isolation:
- thread:
- ribbon:
- ConnectionTimeout: 3000
- ReadTimeout: 60000
(2)Zuul的過濾器：主要位于zuul-service-filter這個項目中
對于Zuul的請求聲明周期來說，一共有4種標準過濾器類型：
PRE：在請求被路由之前調(diào)用，可利用這種過濾器實現(xiàn)身份驗證、記錄調(diào)試信息等操作;
ROUTING：將請求路由到微服務，可利用這種過濾器用于構(gòu)建發(fā)送給微服務的請求;
POST：在路由到微服務以后執(zhí)行，可用來為響應添加標準的HTTP Header、收集統(tǒng)計信息和指標、將響應從微服務發(fā)送給客戶端等;
ERROR：在其他階段發(fā)生錯誤時執(zhí)行該過濾器;
此示例中演示了PRE類型的過濾器，部分場景下，想要禁用部分過濾器，只需要在配置文件中設置即可，例如這里禁用PreRequestLogFilter過濾器：
- zuul:
- # 禁用指定過濾器設置
- PreRequestLogFilter:
- pre:
- disable: true # 禁用我們創(chuàng)建的PreRequestLogFilter過濾器
(3)Zuul的容錯與回退：主要位于zuul-service-fallback這個項目中
Zuul自身就帶有Hystrix，但是它監(jiān)控的粒度是微服務級別，而不是某個API，當某個API不可用時，會統(tǒng)一拋500錯誤碼的異常頁。我們可以為Zuul添加回退，以實現(xiàn)更友好的返回信息。實現(xiàn)也很簡單，只需要實現(xiàn)FallbackProvider接口即可。這里要注意的是，對于Edgware之前的版本(即Dalston及更低版本)需要實現(xiàn)的是ZuulFallbackProvider接口，而Edgware及之后的版本要實現(xiàn)的是FallbackProvider接口。因為FallbackProvider是ZuulFallbackProvider的子接口，而它的好處就是多了一個接口可以獲取可能造成回退的原因，具體可以參考這一篇文章：《Spring Cloud Edgware新特性之八：Zuul回退的改進》。下面是本示例中訪問user-service接口(user-service被我手動關(guān)閉)后的返回結(jié)果：
(4)Zuul的高可用架構(gòu)
生產(chǎn)環(huán)境中一般都需要部署高可用的Zuul以避免單點故障，實際開發(fā)中有兩種情況：
① Zuul的客戶端也注冊到了Eureka Server上(比如：MVC App, SPA 等)
此時Zuul的高可用和其他微服務沒區(qū)別，都是借助Eureka和Ribbon來實現(xiàn)負載均衡。
② Zuul的客戶端未注冊到Eureka Server上(比如手機App端等)
現(xiàn)實中這種場景或許更常見，此時需要借助一個額外的負載均衡器來實現(xiàn)Zuul的高可用，比如：Nginx、HAProxy以及F5等。
(5)使用Zuul聚合微服務：此示例位于zuul-service-aggregation項目中
許多場景下可能一個外部請求要查詢Zuul后端的多個服務，這時可以使用Zuul來聚合服務請求，即只需請求一次，由Zuul來請求各個服務，然后組織好數(shù)據(jù)發(fā)送給客戶端(比如App客戶端)。示例中主要基于RxJava與Zuul來結(jié)合實現(xiàn)的微服務請求的聚合。
3.2.6 統(tǒng)一配置管理 - 基于Spring Cloud Config
Spring Cloud Config為分布式系統(tǒng)外部化配置提供了服務端和客戶端的支持，包括Config Server和Config Client兩部分，其架構(gòu)圖如下圖所示：
其中，各個微服務在啟動時會請求Config Server以獲取所需要的配置屬性，然后緩存這些屬性以提高性能，如下圖所示：
此部分示例位于：part6_config
此部分示例主要演示如何基于Spring Cloud Config實現(xiàn)統(tǒng)一配置中心，主要包括以下內(nèi)容：
(1)基本的Config Server與Config Client編寫：此示例位于config-service與config-client中
此示例需要用到一些已放到git的配置文件，這里我已將其放到了github方便大家可以直接拿來測試用，倉庫 地址
端點與配置文件的映射規(guī)則如下：
- /{application}/{profile}[/{label}]
- /{application}-{profile}.yml
- /{label}/{application}-{profile}.yml
- /{application}-{profile}.properties
- /{label}/{application} -{profile}.properties
- 其中，application: 表示微服務的虛擬主機名，即配置的spring.application.name
- profile: 表示當前的環(huán)境，dev, test or production?
- label: 表示git倉庫分支，master or relase or others repository name? 默認是master
- 項目中，config-service的配置文件如下：
- server:
- spring:
- application:
- name: sampleservice-config-server
- cloud:
- config:
- server:
- git:
- # 配置Git倉庫地址
- uri: https://github.com/EdisonChou/ EDC.SpringCloud.Samples.Config
- # Git倉庫賬號(如果需要認證)
- username:
- # Git倉庫密碼(如果需要認證)
- password:
啟動順序：先啟動config-server，再啟動config-client，因為config-client在啟動時就回去config-server獲取配置，如果這時config-server未啟動則會報錯。
這里需要注意的就是在config-client中，對于spring cloud config的配置應該放在bootstrap.yml中而不是application.yml中，否則會不起作用。這里涉及到一個spring cloud的“引導上下文”的概念。
(2)使用/refresh端點手動刷新配置：仍然位于config-client項目中
要想在運行期間刷新配置，需要兩點改造：加上@RefreshScope注解
- @RestController
- @RefreshScope // @RefreshScope注解不能少，否則即使調(diào)用/refresh，配置也不會刷新
- public class ConfigClientController {
- @Value("${profile}")
- @GetMapping("/profile")
- public String hello(){
- return this.profile;
- }
- }
此外，針對Spring Boot 1.5.x，還需要給config-client端關(guān)閉安全認證，否則無法正常refresh：
- management:
- security:
- enabled: false
之后，就可以通過對config-client發(fā)起POST請求刷新配置了：
不過，如果所有微服務都需要手動刷新配置，工作量會很大。所以，在實際環(huán)境中，一般會實現(xiàn)配置的自動刷新。
(3)使用Spring Cloud Bus自動刷新配置：此示例位于config-server-cloud-bus與config-client-cloud-bus項目中
此示例使用到的架構(gòu)如下圖所示，它將Config Server加入消息總線之中，并使用Config Server的/bus/refersh端點來實現(xiàn)配置的刷新。這樣，各個微服務只需要關(guān)注自身的業(yè)務邏輯，而無需再自己手動刷新配置。
Tip：Spring Cloud Bus基于輕量級地消息代理(例如RabbitMQ、Kafka等)連接分布式系統(tǒng)的節(jié)點，就可以通過廣播的方式來傳播狀態(tài)的更改(例如配置的更新)或者其他的管理指令。我們可以將Spring Cloud Bus想象成一個分布式的Spring Boot Actuator。
運行順序：先啟動config-service-cloud-bus，再啟動兩個config-client-cloud-bus(第一個默認端口8081，第二個端口改為8082)，修改github中sampleservice-foo-dev.properties中的profile值后commit & push，然后POST請求config-service-cloud-bus的/bus/refersh端點，最后再次訪問兩個client的/profile端點進行驗證。
如果部分場景想要知道Spring Cloud Bus事件傳播的細節(jié)，可以通過以下設置來跟蹤事件總線：
- spring:
- cloud:
- bus:
- trace:
- enabled: true # 開啟cloud bus跟蹤
(4)與Eureka的配合使用：此示例位于config-service-eureka與config-client-eureka兩個項目中
(5)Config Server的高可用：涉及到Git倉庫的高可用、RabbitMQ的高可用以及Config Server自身的高可用。
對于Git倉庫的高可用，第三方Git倉庫類似于GitHub等本身已經(jīng)實現(xiàn)了高可用，而針對自建Git倉庫如GitLab，可以參考GitLab官方 文檔搭建高可用
對于Config Server自身的高可用，也可以分為未注冊到Eureka和注冊到Eureka兩種情形
此外，對于配置內(nèi)容的加密，此示例沒有涉及，它依賴于JCE(Java Cryptography Extension)
擴展：關(guān)于統(tǒng)一配置中心，還可以選擇更好用的Apollo(攜程的開源項目)，
3.2.7 微服務跟蹤 - 基于Spring Cloud Sleuth
首先，值得一提的是Spring Cloud Sleuth大量借用了Google Dapper，Twitter Zipkin和Apache HTrace的設計，我們得了解一些術(shù)語，例如：span、trace、annotation等.
此示例位于： part7_sleuth
此部分示例主要演示如何基于Spring Cloud Sleuth實現(xiàn)分布式鏈路監(jiān)控，主要包括以下內(nèi)容：
(1)基礎整合Spring Cloud Sleuth：位于user-service-trace與m ovie-service-trace項目中，主要查看控制臺輸出日志
(2)Spring Cloud Sleuth與Zipkin的配合使用：位于zipkin-service-server、 user-service-trace-zipkin與movie-service-trace-zipkin三個項目中
Zipkin是Twitter開源的分布式跟蹤系統(tǒng)，基于Dapper論文設計而來，主要功能是收集系統(tǒng)的時序數(shù)據(jù)，從而追蹤微服務架構(gòu)的系統(tǒng)延時問題，此外還提供了一個非常友好的界面來幫助追蹤分析數(shù)據(jù)。
下圖是一個接入Zipkin之后的服務調(diào)用簡易流程圖：
運行順序：首先運行zipkin-service-server，其次運行user-service-zipkin與movie-service-zipkin，然后訪問http://localhost:8010/user/1得到數(shù)據(jù)結(jié)果，最后訪問zipkin server首頁，填入起始時間、結(jié)束時間等篩選條件后，點擊Find a trace按鈕，可以看到trace列表，如下圖所示：
點擊“依賴分析”，可以得到下圖，有助于我們分析依賴關(guān)系：
需要注意的是，在開發(fā)調(diào)試時，因為默認的采樣百分比是10%，Sleuth會忽略大量span，因此我們可以在開發(fā)環(huán)境將其設置為100%：
- spring:
- sleuth:
- sampler:
- # 指定需采樣的請求的百分比，默認是0.1(即10%)，這里方便查看設為100%(實際環(huán)境不要這樣設置)
- percentage: 1.0
(3)使用RabbitMQ收集數(shù)據(jù)：此示例位于zipkin-service-server-stream 與 user-service-trace-zipkin-stream兩個項目中
此外，Spring Cloud Sleuth還可以與ELK配合使用，不過此示例沒有涉及.當然，示例中的跟蹤數(shù)據(jù)都是存放到內(nèi)存中，但是跟蹤數(shù)據(jù)還是建議存放到ElasticSearch中，生產(chǎn)環(huán)境切莫只存儲到內(nèi)存中。
