一、SpringCloud微服務技術簡介
Spring Cloud 作為Java 語言的微服務架構，它依賴于Spring Boot，有快速開發、持續傳遞和容易部署等特點。Spring Cloud 的元件非常多，涉及微服務的方方面面，井在開源社群Spring 和Netflix 、Pivotal 兩大公司的推動下越來越完善。
1.1 微服務的功能主要展現在以下兒個方面。
口服務的注冊和發現。
口服務的負載均衡。
口服務的容錯。
口服務網關。
口服務配置的統一管理。
口鍊路追蹤。
口實時日志。
1.2 微服務具有以下的特點。
口按照業務來劃分服務，單個服務代碼量小，業務單一，易于維護
口每個微服務都有自己獨立的基礎元件，例如資料庫、緩存等，且運作在獨立的程序中。
口微服務之間的通信是通過HTTP 協定或者消息元件，且具有容錯能力。
口微服務有一套服務治理的解決方案，服務之間不相合，可以随時加入和剔除服務。
口單個微服務能夠叢集化部署，并且有負載均衡的能力。
口整個微服務系統應該有一個完整的安全機制，包括使用者驗證、權限驗證、資源保護等。
口整個微服務系統有鍊路追蹤的能力。
口有一套完整的實時日志系統。
三、服務注冊和發現Ereka
3.2 Ereka優勢
Eureka 和其他元件，比如負載均衡元件Ribbon 、熔斷器元件Hystrix 、熔斷器監控元件Hystrix Dashboard 元件、熔斷器聚合監控Turbine 元件，以及網關Zuul 元件互相配合， 能夠很容易實作服務注冊、負載均衡、熔斷和智能路由等功能。這些元件都是由Netflix 公司開源的，一起被稱為Netflix OSS 元件。Netflix OSS 元件由Spring Cloud 整合為Spring Cloud Netflix 元件。
Eureka 的基本架構如圖2-3 所示，其中主要包括以下3 種角色。
口Register Service ：服務注冊中心，它是一個Eureka Server ，提供服務注冊和發現的功能。
口Provider Service ：服務提供者，它是一個Eureka Client ，提供服務。
口Consumer Service ：服務消費者，它是一個Eureka Cient ，消費服務。
服務消費的基本過程如下：首先前要一個服務注冊中心Eureka Server，服務提供者EurekaClient 向服務注冊中心Eureka Server 注冊，将自己的資訊（比如服務名和服務的IP 位址等）通過阻ST A 凹的形式送出給服務注冊中心Eureka Server 。同樣，服務消費者Eureka Client 也向服務注冊中心 Eureka Server 注冊，同時服務消費者擷取一份服務注冊清單的資訊， 該清單包含了所有向服務注冊中心Eureka Server 注冊的服務資訊。擷取服務注冊清單資訊之後，服務消費者就知道服務提供者的IP位址，可以通過Http 遠端排程來消費服務提供者的服務。Eureka Client 在預設的情況下會每隔30 秒發送一次心跳來進行服務續約。通過服務續約來告知Eureka Server 該Eureka Client 仍然可用，沒有出現故障。正常情況下，如果Eureka Server在90 秒内沒有收到Eureka Client 的心跳， Eureka Server 會将Eureka Client 執行個體從注冊清單中删除。注意：官網建議不要更改服務續約的間隔時間。
(3) Fetch Registries一一擷取服務注冊清單資訊
( 4) Cancel ——服務下線
Eureka Client 在程式關閉時可以向Eureka Server 發送下線請求。發送請求後，該用戶端的執行個體資訊将從Eureka Server 的服務注冊清單中删除。該下線請求不會自動完成，需要在程式關閉時調用以下代碼：
DiscoveryManager.getinstance().shutdownComponent(); 複制
( 5 ) Eviction一一服務剔除
四、負載均衡
5.1 申明式Feign的簡介
@Feign Client 注解用于建立聲明式API 接口，該接口是RESTful 風格的。Feign 被設計成插拔式的，可以注入其他元件和Feign 一起使用。最典型的是如果Ribbon 可用， Feign 會和Ribbon 相結合進行負載均衡。
在代碼中，value（）和name（）一樣，是被調用的服務的Serviceld 。url（）直接填寫寫死的Url位址。decode404（）即404 是被解碼，還是抛異常。configuration （）指明FeignClient 的配置類，預設的配置類為FeignClientsConfiguration 類， 在預設的情況下， 這個類注入了預設的Decoder 、Encoder 和Contract 等配置的Bean 。fallback（）為配置熔斷器的處理類。
在程式的啟動類EurekaFeignClientApplication加上注解＠EnableEurekaClient開啟EurekaClient的功能，通過注解＠EnableFeignClients 開啟Feign Client 的功能。代碼如下：
@SpringBootApplication
@EnableEurekaClient
@EnableFeignClients
public class EurekaFeignClientApplication {
public static void main (String [] args) {
SpririgApplication.run(EurekaFeignClientApplication.class , args);
}
} 複制
5.2 Feign簡單建構
通過以上3 個步驟，該程式就具備了Feign 的功能，現在來實作一個簡單的Feign Client；建立一個EurekaClientFeign 的接口，在接口上加＠FeignClient 注解來聲明一個Feign Client,其中value 為遠端調用其他服務的服務名， FeignConfig.class 為Feign Client 的配置類。在EurekaClientFeign 接口内部有一個sayHiFromClientEureka（）方法，該方法通過Feign 來調用
六、熔斷器
6.1 什麼是Hystrix
在分布式系統中，服務與服務之間的依賴錯綜複雜， 一種不可避免的情況就是某些服務會出現故障，導緻依賴于它們的其他服務出現遠端排程的線程阻塞。Hystrix 是Netflix 公司開源的一個項目，它提供了熔斷器功能，能夠阻止分布式系統中出現關聯故障。Hystrix 是通過隔離服務的通路點阻止關聯故障的，并提供了故障的解決方案，進而提高了整個分布式系統的彈性。
6.2 Hystrix的作用
在複雜的分布式系統中，可能有幾十個服務互相依賴，這些服務由于某些原因，例如機房的不可靠性、網絡服務商的不可靠性等，導緻某個服務不可用。如果系統不隔離該不可用的服務，可能會導緻整個系統不可用。例如，對于依賴30 個服務的應用程式，每個服務的正常運作時間為99.99% ，對于單個服務來說， 99.99% 的可用是非常完美的。有99.9930 = 99.7% 的可正常運作時間和0.3% 的不可用時間，那麼10 億次請求中有3000000次失敗，實際的情況可能比這更糟糕。如果不設計整個系統的韌性，即使所有依賴關系表現良好，單個服務隻有0.01% 的不可用，由于整個系統的服務互相依賴，最終對整個系統的影響是非常大的。在微服務系統中， 一個使用者請求可能需要調用幾個服務才能完成。如圖8-1 所示，在所有的服務都處于可用狀态時， 一個使用者請求需要調用A 、H 、I 和P 服務。
6.3 Hystrix的場景
當某一個服務，例如服務I，出現網絡延遲或者故障時，即使服務A 、H 和P 可用，由于服務I 的不可用，整個使用者請求會處于阻塞狀态，并等待服務I 的響應，如圖8-2 所示。在高并發的情況下，單個服務的延遲會導緻整個請求都處于延遲狀态，可能在幾秒鐘就使整個服務處于線程負載飽和的狀态。某個服務的單個點的請求故障會導緻使用者的請求處于阻塞狀态，最終的結果就是整個服務的線程資源消耗殆盡。由于服務的依賴性，會導緻依賴于該故障服務的其他服務也處于線程阻塞狀态，最終導緻這些服務的線程資源消耗殆盡， 直到不可用，進而導緻整個問服務系統都不可用，即雪崩效應。為了防止雪崩效應，因而産生了熔斷器模型。Hystrix 是在業界表現非常好的一個熔斷器模型實作的開源元件，它是Spring Cloud 元件不可缺少的一部分。
6.4 Hystrix設計原則
Hystrix 的設計原則如下。
口防止單個服務的故障耗盡整個服務的Servlet 容器（例如Tomcat ）的線程資源。
口快速失敗機制，如果某個服務出現了故障，則調用該服務的請求快速失敗，而不是線程等待。
口提供回退（ fallback ）方案，在請求發生故障時，提供設定好的回退方案。
口使用熔斷機制，防止故障擴散到其他服務。
口提供熔斷器的監控元件Hystrix Dashboard，可以實時監控熔斷器的狀态。
6.5 Hystrix 的工作機制
當服務的某個API接口的失敗次數在一定時間内小于設定的閥值時，熔斷器處于關閉狀态，該API接口正常提供服務。當該API 接口處理請求的失敗次數大于設定的閥值時，Hystrix 判定該API 接口出現了故障，打開熔斷器，這時請求該API接口會執行快速失敗的邏輯（即fallback回退的邏輯），不執行業務邏輯，請求的線程不會處于阻塞狀态。處于打開狀态的熔斷器，一段時間後會處于半打開狀态，并将一定數量的請求執行正常邏輯。剩餘的請求會執行快速失敗，若執行正常邏輯的請求失敗了，則熔斷器繼續打開：若成功了，則将熔斷器關閉。這樣熔斷器就具有了自我修複的能力。
6.6 Hystrix Dashboard 是監控Hystrix 的熔斷器狀态
在微服務架構中，為了保證服務執行個體的可用性，防止服務執行個體出現故障導緻線程阻塞，而出現了熔斷器模型。烙斷器的狀況反映了一個程式的可用性和健壯性，它是一個重要名額。Hystrix Dashboard 是監控Hystrix 的熔斷器狀況的一個元件，提供了資料監控和很友好的圖形化展示界面。本節在上一節的基礎上，以案例的形式講述如何使用Hystrix Dashboard 監控熔斷器的狀态。
七、路由網關
智能路由網關元件Zuul：Zuul 作為微服務系統的網關元件，用于建構邊界服務（ EdgeService ），緻力于動态路由、過濾、監控、彈性伸縮和安全。
7.1 Zuul的作用
Zuul作為路由網關元件，在微服務架構中有着非常重要的作用，主要展現在以下6 個方面。
口 Zuul 、Ribbon 以及Eureka 相結合，可以實作智能路由和負載均衡的功能，Zuul能夠将請求流量按某種政策分發到叢集狀态的多個服務執行個體。
口 網關将所有服務的API 接口統一聚合，并統一對外暴露。外界系統調用API接口時，都是由網關對外暴露的API 接口，外界系統不需要知道微服務系統中各服務互相調用的複雜性。微服務系統也保護了其内部微服務單元的API接口，防止其被外界直接調用，導緻服務的敏感資訊對外暴露。
口 網關服務可以做使用者身份認證和權限認證，防止非法請求操作API 接口，對伺服器起到保護作用。
口 網關可以實作監控功能，實時日志輸出，對請求進行記錄。
口 網關可以用來實作流量監控， 在高流量的情況下，對服務進行降級。
口 API 接口從内部服務分離出來， 友善做測試。
7.2 Zuul的工作原理
Zuul是通過Servlet來實作的，Zuul通過自定義的ZuulServlet（類似于SpringMVC的DispatchServlet來對請求進行控制。Zuul的核心是一系列過濾器，可以在Http請求的發起和響應傳回期間執行一系列的過濾器。Zuul包括以下4 種過濾器。
口PRE 過濾器： 它是在請求路由到具體的服務之前執行的，這種類型的過濾器可以做安全驗證，例如身份驗證、參數驗證等。
口ROUTING 過濾器： 它用于将請求路由到具體的微服務執行個體。在預設情況下，它使用Http Client 進行網絡請求。
口POST 過濾器：它是在請求己被路由到微服務後執行的。一般情況下，用作收集統計資訊、名額，以及将響應傳輸到用戶端。
口ERROR 過濾器：它是在其他過濾器發生錯誤時執行的。Zuul 采取了動态讀取、編譯和運作這些過濾器。過濾器之間不能直接互相通信，而是通過RequestContext 對象來共享資料， 每個請求都會建立一個RequestContext 對象。Zuul 過濾器具有以下關鍵特性。
口Type （類型） ： Zuul 過濾器的類型，這個類型決定了過濾器在請求的哪個階段起作用，例如Pre 、Post 階段等。
口Execution Order （執行順序） ：規定了過濾器的執行順序， Order 的值越小，越先執行。
口Criteria （标準） ： Filter 執行所需的條件。
口Action （行動）： 如果符合執行條件，則執行Action （即邏輯代碼）。
Zuul 請求的生命周期如圖9-1 所示，該圖來自Zuul 的官方文檔。當一個用戶端Request 請求進入Zuul 網關服務時，網關先進入“pre filter飛進行一系列的驗證、操作或者判斷。然後交給“routing filter ”進行路由轉發，轉發到具體的服務執行個體進行邏輯處理、傳回資料。當具體的服務處理完後，最後由“post filter 進行處理， 該類型的處理器處理完之後，将Response 資訊傳回給用戶端。
另外一種常見的叢集是通過Ngnix和Zuul互相結合來做負載均衡。暴露在最外面的是Ngnix 主從雙熱備進行Keepalive, Ngnix 經過某種路由政策，将請求路由轉發到Zuul叢集上，Zuul最終将請求分發到具體的服務上，架構圖如圖9-4 所示。
八、配置中心
8.1 分布式配置中心Spring Cloud Config
口Config Server 從本地讀取配置檔案。
Config-Sever工程目錄下。Config-Sever暴露HttpAPI接口，Config-Client通過調用Config-Sever 的H即API 接口來讀取配置檔案。
spring:
cloud:
config:
server:
native:
search-locations: classpath:/shared
profiles:
active: native
application:
name: config- server
server:
port: 8769 複制
在工程的Resources 目錄下建一個shared 檔案夾，用于存放本地配置檔案。在shared 目錄下，建立一個config-client-dev. yml 檔案，用作eureka-client 工程的dev （開發環境）的配置檔案。在config-client-dev.yml 配置檔案中，指定程式的端口号為8762 ， 并定義一個變量 foo ， 該變量的值為foo version l。
口Config Server 從遠端Git 倉庫讀取配置檔案。
Spring Cloud Config 支援從遠端Git 倉庫讀取配置檔案，即Config Server 可以不從本地的倉庫讀取，而是從遠端Git 倉庫讀取。這樣做的好處就是将配置統一管理，并且可以通過SpringCloud Bus 在不人工啟動程式的情況下對Config Client 的配置進行重新整理。
server:
port：8769
spring:
cloud:
config:
server:
git:
uri: https://github.com/forezp/SpringcloudConfig
searchPaths: respo
username: [email protected]
password:
label: master
application:
name: config-server 複制
其中，uri為遠端Git倉庫的位址，serachPaths為搜尋遠端倉庫的檔案夾位址，usemame和password為Git倉庫的登入名和密碼。如果是私人Git 倉庫，登入名和密碼是必須的；如果是公開的Git倉庫，可以不需要。label 為git 倉庫的分支名。
口搭建高可用Co nfig Server 叢集。當服務執行個體很多時，所有的服務執行個體需要同時從配置中心Config Server 讀取配置檔案，這時可以考慮将配置中心Config Server 做成一個微服務，并且将其叢集化，進而達到高可用。
口使用Spring Cloud Bus 重新整理配置。
Spring Cloud Bus 是用輕量的消息代理将分布式的節點連接配接起來，可以用于廣播配置檔案的更改或者服務的監控管理。個關鍵的思想就是，消息總線可以為微服務做監控，也可以實作應用程式之間相I T-L 通信。S pring Cloud Bus 可選的消息代理組建包括RabbitMQ 、AMQP 和Kafka 等。本節講述的是用RabbitMQ 作為Spring Cloud 的消息元件去重新整理更改微服務的配置檔案。
九、服務鍊路追蹤
Spring Cloud Sleuth 是Spring Cloud 的一個元件，它的主要功能是在分布式系統中提供服務鍊路追蹤的解決方案。
使用分布式鍊路的意義
微服務架構是一個分布式架構，微服務系統按業務劃分服務單元，一個微服務系統往往有很多個服務單元。由于服務單元數量衆多，業務的複雜性較高，如果出現了錯誤和異常，很難去定位。主要展現在一個請求可能需要調用很多個服務，而内部服務的調用複雜性決定了問題難以定位。是以在微服務架構中，必須實作分布式鍊路追蹤， 去跟進一個請求到底有哪些服務參與，參與的順序又是怎樣的，進而達到每個請求的步驟清晰可見，出了問題能夠快速定位的目的。
常見鍊路追蹤元件
常見的鍊路追蹤元件有Google 的Dapper 、Twitter 的Zipkin ， 以及阿裡的Eag leeye（鷹眼）等，它們都是非常優秀的鍊路追蹤開源元件。本章主要講述如何在Spring Cloud Sleuth 中內建Zipkin o 在Spring Cloud Sleuth 中內建Zipkin 非常簡單，隻需要引入相應的依賴并做相關的配置即可。
zipkin-server作為鍊路追蹤服務中心，負責存儲鍊路資料。gateway-service 作為服務網關工程，負責請求的轉發，同時它也作為鍊路追蹤用戶端，負責産生鍊路資料，并上傳給zipkin-service 。user-service是一個服務提供者，對外暴露API 接口，同時它也作為鍊路追蹤用戶端，負責産生鍊路資料。
Maven依賴
<parent>
<groupid>com.forezp</groupid>
<artifactid>sleuth</artifactid>
<version>0.0.1-SNAPSHOT</version>
</parent>
<dependencies>
<dependency>
<groupid>org.springframework.cloud</groupid>
<artifactid>spring-cloud starter eureka</artifactid>
</dependency>
<dependency>
<groupid>io.zipkin.java</groupid>
<artifactid>zipkin-server</artifactid>
</dependency>
<dependency>
<groupid>io.zipkin.java</groupid>
<artifactid>zipkin-autoconfigure-ui</artifactid>
</dependency>
</dependencies> 複制
程式啟動類
在程式的啟動類ZipkinServiceApplication 加上＠EnableZipkinSe凹er 注解，開啟ZipkinServer 的功能，加上＠EnableEurekaClient 注解， 啟動Eureka Client，代碼如下：
@SpringBootApplication
@EnableEurekaClient
@EnableZipkinServer
public class zipkinServerApplication {
public statrt void main(String[] args) {
SpringApplication.run(ZipkinServerApplication.class , args) ;
}
} 複制
在程式的配置檔案application.yml 檔案做程式的相關配置，指定程式名為zipkin-server,端口号為9411，服務注冊位址為http://localhost:8761 /eureka／，代碼如下：
eureka:
client:
serviceUrl:
defaultZone: http://localhost:8761/eureka/
server:
port: 9411
spring:
application:
name: zipkin-server 複制
操作界面
使用RabbitMQ傳輸鍊路資料
SpringCloudSleuth中支援消息元件來傳輸鍊路資料，本節使用RabbitMQ來傳輸鍊路資料。首先改造zipkinServer工程，在其porn檔案中将zipkinServer的依賴去掉，加上spring-cloud-sleuth-zipkin-stream 和spring-cloud-starter-stream-rabbit 的依賴，代碼如下：
<dependency>
<groupid>org.springframework.cloud</groupid>
<artifactid>spring-cloud-sleuth-zipkin-stream</artifactid>
</dependency>
<dependency>
<groupid>org.springframework.cloud</groupid>
<artifactid>spring-cloud-starter-stream-rabbit</artifactid>
</dependency> 複制
在工程的配置檔案application.yml 加上RabbitMQ 的配置，包括host 、端口、使用者名、密碼，代碼如下：
spring:
rabbitmq:
host: localhost
port: 5672
username: guest
password: guest 複制
在程式的啟動類ZipkinServerApplication中加上＠EnableZipkinStreamServer注解，開啟ZipkinStreamServer，代碼如下：
@SpringBootApplication
@EnableEurekaClient
@EnableZipkinStreamServer
public class ZipkinServerApplication {
public static void main (String [] args) {
SpringApplication.run(ZipkinServerApplication.class , args) ;
}
} 複制
十、微服務監控
Spring Boot Admin是一個管理和監控你的Spring Boot程式的應用程式。 這些應用程式通過 Spring Boot Admin Client（通過 HTTP）注冊或者使用SpringCloud（例如Eureka）發現。UI隻是 SpringBootActuator 端點上的一個 AngularJs 應用程式。
1、搭建Admin Server服務端
建立model：admin-server
pom.xml
<dependencies>
<dependency>
<groupId>de.codecentric</groupId>
<artifactId>spring-boot-admin-starter-server</artifactId>
<version>2.0.1</version>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-security</artifactId>
</dependency>
<dependency>
<groupId>org.jolokia</groupId>
<artifactId>jolokia-core</artifactId>
</dependency>
</dependencies> 複制
2、應用主類添加注解并添加配置(這個配置來資源官方文檔推薦)：
@SpringBootApplication
@EnableAdminServer
@EnableEurekaClient
public class AdminServerApplication {
public static void main(String[] args) {
SpringApplication.run(AdminServerApplication.class, args);
}
@Profile("insecure")
@Configuration
public static class SecurityPermitAllConfig extends WebSecurityConfigurerAdapter {
@Override
protected void configure(HttpSecurity http) throws Exception {
http.authorizeRequests().anyRequest().permitAll()//
.and().csrf().disable();
}
}
@Profile("secure")
@Configuration
public static class SecuritySecureConfig extends WebSecurityConfigurerAdapter {
private final String adminContextPath;
public SecuritySecureConfig(AdminServerProperties adminServerProperties) {
this.adminContextPath = adminServerProperties.getContextPath();
}
@Override
protected void configure(HttpSecurity http) throws Exception {
// @formatter:off
SavedRequestAwareAuthenticationSuccessHandler successHandler = new SavedRequestAwareAuthenticationSuccessHandler();
successHandler.setTargetUrlParameter("redirectTo");
http.authorizeRequests()
.antMatchers(adminContextPath + "/assets/**").permitAll()
.antMatchers(adminContextPath + "/login").permitAll()
.anyRequest().authenticated()
.and()
.formLogin().loginPage(adminContextPath + "/login").successHandler(successHandler).and()
.logout().logoutUrl(adminContextPath + "/logout").and()
.httpBasic().and()
.csrf().disable();
// @formatter:on
}
}
} 複制
3、修改用戶端
在原來service-feign，service-ribbon，eureka-client三個model的基礎上修改其依賴和配置，新增依賴：
<dependency>
<groupId>de.codecentric</groupId>
<artifactId>spring-boot-admin-starter-client</artifactId>
<version>2.0.1</version>
</dependency> 複制
配置檔案新增配置：
spring:
boot:
admin:
client:
url: "http://localhost:9997"
management:
endpoints:
web:
exposure:
include: '*'
endpoint:
health:
show-details: ALWAYS 複制
Spring Boot的Actuator隻暴露了/health、/info兩個端口（為了安全考慮），是以要配置 management.endpoints.web.exposure.include 的屬性。
十一、SpringSecurity
1、簡介
一個能夠為基于Spring的企業應用系統提供聲明式的安全訪問控制解決方式的安全架構（簡單說是對通路權限進行控制嘛），應用的安全性包括使用者認證（Authentication）和使用者授權（Authorization）兩個部分。使用者認證指的是驗證某個使用者是否為系統中的合法主體，也就是說使用者能否通路該系統。使用者認證一般要求使用者提供使用者名和密碼。系統通過校驗使用者名和密碼來完成認證過程。使用者授權指的是驗證某個使用者是否有權限執行某個操作。在一個系統中，不同使用者所具有的權限是不同的。比如對一個檔案來說，有的使用者隻能進行讀取，而有的使用者可以進行修改。一般來說，系統會為不同的使用者配置設定不同的角色，而每個角色則對應一系列的權限。spring security的主要核心功能為 認證和授權，所有的架構也是基于這兩個核心功能去實作的。
2、架構原理
衆所周知 想要對對Web資源進行保護，最好的辦法莫過于Filter，要想對方法調用進行保護，最好的辦法莫過于AOP。是以springSecurity在我們進行使用者認證以及授予權限的時候，通過各種各樣的攔截器來控制權限的通路，進而實作安全。
如下為其主要過濾器
WebAsyncManagerIntegrationFilter
SecurityContextPersistenceFilter
HeaderWriterFilter
CorsFilter
LogoutFilter
RequestCacheAwareFilter
SecurityContextHolderAwareRequestFilter
AnonymousAuthenticationFilter
SessionManagementFilter
ExceptionTranslationFilter
FilterSecurityInterceptor
UsernamePasswordAuthenticationFilter
BasicAuthenticationFilter
3、架構的核心元件
SecurityContextHolder：提供對SecurityContext的通路
SecurityContext,：持有Authentication對象和其他可能需要的資訊
AuthenticationManager 其中可以包含多個AuthenticationProvider
ProviderManager對象為AuthenticationManager接口的實作類
AuthenticationProvider 主要用來進行認證操作的類 調用其中的authenticate()方法去進行認證操作
Authentication：Spring Security方式的認證主體
GrantedAuthority：對認證主題的應用層面的授權，含目前使用者的權限資訊，通常使用角色表示
UserDetails：建構Authentication對象必須的資訊，可以自定義，可能需要通路DB得到。
UserDetailsService：通過username建構UserDetails對象，通過loadUserByUsername根據userName擷取UserDetail對象 （可以在這裡基于自身業務進行自定義的實作 如通過資料庫，xml,緩存擷取等）。