Spring Cloud+Nginx架構(gòu)的主要組件

以crazy-springcloud開(kāi)發(fā)腳手架為例，一個(gè)Spring Cloud+Nginx應(yīng)用的架構(gòu)如圖1-1所示。

圖1-1 基于Spring Cloud+Nginx的應(yīng)用架構(gòu)

Nginx作為反向代理服務(wù)器，代理內(nèi)部Zuul網(wǎng)關(guān)服務(wù)，通過(guò)Nginx自帶的負(fù)載均衡算法實(shí)現(xiàn)客戶(hù)端請(qǐng)求的代理轉(zhuǎn)發(fā)、負(fù)載均衡等功能。

Zuul網(wǎng)關(guān)主要實(shí)現(xiàn)了微服務(wù)集群內(nèi)部的請(qǐng)求路由、負(fù)載均衡、統(tǒng)一校驗(yàn)等功能。雖然在路由服務(wù)和負(fù)載均衡方面，Zuul和Nginx的功能比較類(lèi)似，但是Zuul是自身注冊(cè)到Eureka/Nacos，通過(guò)微服務(wù)的serviceID實(shí)現(xiàn)微服務(wù)提供者之間的路由和轉(zhuǎn)發(fā)。

Eureka、Nacos都是Spring Cloud技術(shù)體系中提供服務(wù)注冊(cè)與發(fā)現(xiàn)的中間件。Eureka是Netflix開(kāi)源的一款產(chǎn)品，提供了完整的服務(wù)注冊(cè)和發(fā)現(xiàn)，是Spring Cloud“全家桶”中的核心組件之一。

Nacos是阿里巴巴推出來(lái)的一個(gè)開(kāi)源項(xiàng)目，也是一個(gè)服務(wù)注冊(cè)與發(fā)現(xiàn)中間件，它用于完成服務(wù)的動(dòng)態(tài)注冊(cè)、動(dòng)態(tài)發(fā)現(xiàn)、服務(wù)管理，還兼具了配置管理的功能。Nacos提供了一組簡(jiǎn)單易用的特性集，用于實(shí)現(xiàn)動(dòng)態(tài)服務(wù)發(fā)現(xiàn)、服務(wù)配置、服務(wù)元數(shù)據(jù)及流量管理。

由于新版本的Eureka已經(jīng)閉源，而阿里巴巴的Nacos除了具備Eureka注冊(cè)中心功能外，還具備Spring Cloud Config配置中心的功能，因此大大地降低了使用和維護(hù)的成本。另外，Nacos還具有分組隔離功能，一套Nacos集群可以支撐多項(xiàng)目、多環(huán)境。綜合上述多個(gè)原因，在實(shí)際的開(kāi)發(fā)場(chǎng)景中，推薦大家使用Nacos。但是，本文出于學(xué)習(xí)目的，注冊(cè)中心和配置中心的內(nèi)容還是介紹Eureka+Config組合，其實(shí)在原理上，Nacos和Eureka+Config組合是差不多的。

除了一系列基礎(chǔ)設(shè)施中間件技術(shù)組件之外，微服務(wù)架構(gòu)中大部分獨(dú)立業(yè)務(wù)模型都是以服務(wù)提供者的角色出現(xiàn)的。一般來(lái)說(shuō)，系統(tǒng)可以按照各類(lèi)業(yè)務(wù)模塊進(jìn)行細(xì)粒度的微服務(wù)拆分，例如秒殺系統(tǒng)中的用戶(hù)、商品等，每個(gè)業(yè)務(wù)模塊拆分成一個(gè)微服務(wù)提供者Provider組件，作為獨(dú)立應(yīng)用程序進(jìn)行啟動(dòng)和執(zhí)行。

在Spring Cloud生態(tài)中，微服務(wù)提供者Provider之間的遠(yuǎn)程調(diào)用是通過(guò)Feign+Ribbon+Hystrix組合來(lái)完成的：Feign用于完成RPC遠(yuǎn)程調(diào)用的代理封裝；Ribbon用于在客戶(hù)端完成各遠(yuǎn)程目標(biāo)服務(wù)實(shí)例之間的負(fù)載均衡；Hystrix用于完成自動(dòng)熔斷降級(jí)等多個(gè)維度的RPC保護(hù)。在Nginx+Spring Cloud架構(gòu)中還存在一系列輔助中間件，包括日志記錄、鏈路跟蹤、應(yīng)用監(jiān)控、JVM性能指標(biāo)、物理資源監(jiān)控等等。本文并沒(méi)有對(duì)上述輔助中間件做專(zhuān)門(mén)的介紹。

Spring Cloud和Spring Boot的版本選擇

Spring Cloud是基于Spring Boot構(gòu)建的，它們之間的版本有配套的對(duì)應(yīng)關(guān)系。在構(gòu)建項(xiàng)目時(shí)，要注意版本之間的這種對(duì)應(yīng)關(guān)系，版本若對(duì)應(yīng)不上則會(huì)出現(xiàn)問(wèn)題。

Spring Cloud和Spring Boot的版本配套關(guān)系如表1-1所示。

表1-1　Spring Cloud與Spring Boot的版本配套關(guān)系

表1-1 Spring Cloud與Spring Boot的版本配套關(guān)系

Spring Cloud包含一系列子組件，如Spring Cloud Config、Spring Cloud Netflix、Spring Cloud Openfeign等，為了防止與這些子組件的版本號(hào)混淆，Spring Cloud的版本號(hào)全部使用英文單詞形式命名。具體來(lái)說(shuō)，Spring Cloud的版本號(hào)使用了英國(guó)倫敦地鐵站的名稱(chēng)來(lái)命名，并按字母A~Z的次序發(fā)布版本，它的第一個(gè)版本叫作Angel，第二個(gè)版本叫作Brixton，以此類(lèi)推。另外，每個(gè)大版本在解決了一個(gè)嚴(yán)重的Bug后，Spring Cloud會(huì)發(fā)布一個(gè)Service Release版本（小版本），簡(jiǎn)稱(chēng)SRX版本，其中X是順序的編號(hào)，比如Finchley.SR4是Finchley大版本的第4個(gè)小版本。

大家做技術(shù)選型時(shí)非常喜歡用最高版本，但是對(duì)于Spring全家桶的選擇來(lái)說(shuō)，高版本不一定是最佳選擇。比如，目前最高的Spring CloudHoxton版本是基于Spring Boot 2.2構(gòu)建的，Spring Boot 2.2又是基于Spring Framework 5.2構(gòu)建的，也就是說(shuō)，這是一次整體的、全方位的大版本升級(jí)。大家在項(xiàng)目上會(huì)用到非常多的第三方組件，總會(huì)有一些組件沒(méi)有來(lái)得及進(jìn)行配套升級(jí)而不能兼容Spring Boot 2.2或SpringFramework 5.2，如果貿(mào)然地進(jìn)行基礎(chǔ)框架的整體升級(jí)，就會(huì)給項(xiàng)目開(kāi)發(fā)帶來(lái)各種各樣的疑難雜癥，甚至帶來(lái)潛在的線上Bug。

除此之外，Spring Cloud高版本推薦了不少自家的新組件，但是這些新組件沒(méi)有經(jīng)過(guò)大規(guī)模實(shí)踐應(yīng)用的考驗(yàn)，其功能尚待豐富和完善。以負(fù)載均衡組件為例，Spring Cloud Hoxton推薦的自家組件springcloud-loadbalancer在功能上與Ribbon的負(fù)載均衡功能相比就弱很多。

Spring Cloud Finchley到Greenwich版本的升級(jí)其實(shí)很小，可以說(shuō)微乎其微，主要是提升了對(duì)Java 11的兼容性。然而，在當(dāng)前的生產(chǎn)場(chǎng)景中Java 8才是各大項(xiàng)目的主流選擇，另外Java 11（2019年4月之后的升級(jí)補(bǔ)丁）已經(jīng)不完全免費(fèi)了。當(dāng)然，和Java 11一樣，Java 8在2019年4月之后的補(bǔ)丁版本也面臨收費(fèi)的問(wèn)題。使用Java 8的理由是，自2014年3月18日發(fā)布起至目前，Java 8被廣泛使用，且被維護(hù)了這么多年，已經(jīng)非常成熟和穩(wěn)定了。

綜上所述，本文選用了Spring Cloud Finchley作為學(xué)習(xí)、研究和使用的版本，推薦使用的子版本為Finchley.SR4。具體的Maven依賴(lài)坐標(biāo)如下：

 <dependencyManagement>
 <dependencies>
 <dependency>
 <groupId>org.springframework.cloudgroupId>
 <artifactId>spring-cloud-dependenciesartifactId>
 <version>Finchley.SR4version>
 <type>pomtype>
 <scope>importscope>
 dependency>
 <dependency>
 <groupId>org.springframework.bootgroupId>
 <artifactId>spring-boot-dependenciesartifactId>
 <version>2.0.8.RELEASEversion>
 <scope>importscope>
 <type>pomtype>
 dependency>
 dependencies>
 dependencyManagement>

Spring Cloud微服務(wù)開(kāi)發(fā)所涉及的中間件

在基于crazy-springcloud腳手架（其他的腳手架類(lèi)似）的微服務(wù)開(kāi)發(fā)和自驗(yàn)證過(guò)程中，所涉及的基礎(chǔ)中間件大致如下：

1.ZooKeeper

ZooKeeper是一個(gè)開(kāi)放源碼的分布式協(xié)調(diào)應(yīng)用程序，是大數(shù)據(jù)框架Hadoop和HBase的重要組件。在分布式應(yīng)用中，它能夠高可用地提供保

障數(shù)據(jù)一致性的很多基礎(chǔ)功能：分布式鎖、選主、分布式命名服務(wù)等。

在crazy-springcloud腳手架中，高性能分布式ID生成器用到了ZooKeeper。

2.Redis

Redis是一個(gè)高性能的緩存數(shù)據(jù)庫(kù)。在高并發(fā)的場(chǎng)景下，Redis可以對(duì)關(guān)系數(shù)據(jù)庫(kù)起到很好的緩沖作用；在提高系統(tǒng)的并發(fā)能力和響應(yīng)速度方面，Redis至關(guān)重要。crazy-springcloud腳手架的分布式Session用到了Redis。

3.Eureka

Eureka是Netflix開(kāi)發(fā)的服務(wù)注冊(cè)和發(fā)現(xiàn)框架，它本身是一個(gè)REST服務(wù)提供者，主要用于定位運(yùn)行在AWS（Amazon云）上的中間層服務(wù)，以達(dá)到負(fù)載均衡和中間層服務(wù)故障轉(zhuǎn)移的目的。Spring Cloud將Eureka集成在子項(xiàng)目spring-cloud-netflix中，以實(shí)現(xiàn)Spring Cloud的服務(wù)注冊(cè)和發(fā)現(xiàn)功能。

4.Spring Cloud Config

Spring Cloud Config是Spring Cloud全家桶中最早的配置中心，雖然在生產(chǎn)場(chǎng)景中很多企業(yè)已經(jīng)使用Nacos或者Consul整合型的配置中心替代了獨(dú)立的配置中心，但是Config依然適用于Spring Cloud項(xiàng)目，通過(guò)簡(jiǎn)單地配置即可使用。

5.Zuul

Zuul是Netflix開(kāi)源網(wǎng)關(guān)，可以和Eureka、Ribbon、Hystrix等組件配合使用，Spring Cloud對(duì)Zuul進(jìn)行了整合與增強(qiáng)，使用它作為微服務(wù)集群的內(nèi)部網(wǎng)關(guān)，負(fù)責(zé)給集群內(nèi)部的各個(gè)Provider（服務(wù)提供者）提供RPC路由和對(duì)請(qǐng)求進(jìn)行過(guò)濾。

6.Nginx/OpenResty

Nginx是一個(gè)高性能HTTP和反向代理服務(wù)器，是由伊戈?duì)枴べ愃饕驗(yàn)槎砹_斯訪問(wèn)量第二的Rambler.ru站點(diǎn)開(kāi)發(fā)的Web服務(wù)器。Nginx源代碼以類(lèi)BSD許可證的形式對(duì)外發(fā)布，它的第一個(gè)公開(kāi)版本0.1.0在2004年10月4日發(fā)布，1.0.4版本在2011年6月1日發(fā)布。Nginx因高穩(wěn)定性、豐富的功能集、內(nèi)存消耗少、并發(fā)能力強(qiáng)而聞名全球，并被廣泛使用，百度、京東、新浪、網(wǎng)易、騰訊、淘寶等都是它的用戶(hù)。OpenResty是一個(gè)基于Nginx與Lua的高性能Web平臺(tái)，它的內(nèi)部集成了大量精良的Lua庫(kù)、第三方模塊以及大多數(shù)的依賴(lài)項(xiàng)，用于快速搭建能夠處理超高并發(fā)的擴(kuò)展性極高的動(dòng)態(tài)Web應(yīng)用、Web服務(wù)和動(dòng)態(tài)網(wǎng)關(guān)。

以上中間件的端口配置以及部分安裝與使用的演示視頻如表1-2所示。

表1-2　本文案例涉及的主要中間件的端口配置以及部分安裝與使用的演示視頻

Spring Cloud微服務(wù)開(kāi)發(fā)和自驗(yàn)證環(huán)境

在開(kāi)始學(xué)習(xí)Spring Cloud核心編程之前，先來(lái)介紹一下開(kāi)發(fā)和自驗(yàn)證環(huán)境的準(zhǔn)備、中間件的安裝以及抓包工具的準(zhǔn)備。

開(kāi)發(fā)和自驗(yàn)證環(huán)境的系統(tǒng)選項(xiàng)和環(huán)境變量配置

首先介紹開(kāi)發(fā)和自驗(yàn)證系統(tǒng)的選型。大部分開(kāi)發(fā)人員學(xué)習(xí)開(kāi)發(fā)都用過(guò)Windows環(huán)境，在這種情況下，強(qiáng)烈建議使用虛擬機(jī)裝載CentOS作為自驗(yàn)證環(huán)境。為什么要推薦CentOS呢？

1.提前暴露生產(chǎn)環(huán)境中的問(wèn)題

在生產(chǎn)環(huán)境上，90%以上的Java應(yīng)用都是使用Linux環(huán)境（如CentOS）來(lái)部署的。因此，使用CentOS作為自驗(yàn)證環(huán)境可以提前暴露生產(chǎn)環(huán)境中的潛在問(wèn)題，避免在開(kāi)發(fā)時(shí)沒(méi)有發(fā)現(xiàn)有問(wèn)題的程序，一旦部署到生產(chǎn)環(huán)境中就出現(xiàn)問(wèn)題（筆者親歷）。

2.學(xué)習(xí)Shell命令和腳本

在生產(chǎn)環(huán)境中定位、分析、解決線上Bug時(shí)，需要用到基礎(chǔ)的Shell命令和腳本，因此平時(shí)要多使用、多練習(xí)。另外，Shell命令和腳本是Java程序員必知必會(huì)的面試題。使用CentOS作為自驗(yàn)證環(huán)境能方便大家學(xué)習(xí)Shell命令和腳本。

當(dāng)然，可以借助一些文件同步或共享工具提高開(kāi)發(fā)效率。比如，可以通過(guò)VMware Tools共享Windows和CentOS之間的文件夾，這樣在后續(xù)的Lua腳本的開(kāi)發(fā)和調(diào)試過(guò)程中能避免來(lái)回地復(fù)制文件。

這里給大家介紹一下crazy-springcloud腳手架開(kāi)發(fā)和自驗(yàn)證環(huán)境的準(zhǔn)備，主要涉及兩個(gè)方面：

（1）中間件（含Eureka、Redis、MySQL等）相關(guān)信息的環(huán)境變量的配置。

（2）主機(jī)名稱(chēng)的配置。

對(duì)于中間件相關(guān)信息（如IP地址、端口、用戶(hù)賬號(hào)等），很多項(xiàng)目都是直接以明文編碼的方式存放在配置文件中，這樣存在安全隱患甚至?xí)l(fā)泄密的風(fēng)險(xiǎn)。對(duì)于這些信息，建議通過(guò)操作系統(tǒng)環(huán)境變量進(jìn)行配置，然后在配置文件中使用環(huán)境變量而不是明文編碼。

例如，可以對(duì)Eureka的IP提前配置好環(huán)境變量EUREKA_ZONE_HOST，然后在應(yīng)用的配置文件bootstrap.yml中按照如下方式來(lái)使用：

eureka:
 client:
 serviceUrl:
 defaultZone: ${SCAFFOLD_EUREKA_ZONE_HOSTS:http://localhost:7777/eureka/}

在上面的配置中，通過(guò)${
SCAFFOLD_EUREKA_ZONE_HOSTS}表達(dá)式從環(huán)境變量中獲取Eureka的service-url地址。環(huán)境變量SCAFFOLD_EUREKA_ZONE_HOSTS后面跟著一個(gè)冒號(hào)和一個(gè)默認(rèn)值，表示如果環(huán)境變量值為空，就會(huì)使用默認(rèn)值
http://localhost:7777/eureka/作為配置項(xiàng)的值。

通過(guò)環(huán)境變量配置中間件的信息有什么好處呢？

一是使配置信息的切換多了一層靈活性，如果切換IP，那么只需修改環(huán)境變量即可；二是可以不用在配置文件中以明文編碼方式存放密碼之類(lèi)的敏感信息，多了一層安全性。

crazy-springcloud微服務(wù)開(kāi)發(fā)腳手架用到的環(huán)境變量較多，以自驗(yàn)證環(huán)境CentOS中的配置文件/etc/profile為例，部分內(nèi)容大致如下：

export SCAFFOLD_DB_HOST=192.168.233.128
export SCAFFOLD_DB_USER=root
export SCAFFOLD_DB_PSW=root
export SCAFFOLD_REDIS_HOST=192.168.233.128
export SCAFFOLD_REDIS_PSW=123456
export SCAFFOLD_EUREKA_ZONE_HOSTS=http://192.168.233.128:7777/eureka/
export RABBITMQ_HOST=192.168.233.128
export SCAFFOLD_ZOOKEEPER_HOSTS=192.168.233.128:2181

以上環(huán)境變量中的192.168.233.128是筆者自驗(yàn)證環(huán)境CentOS虛擬機(jī)的IP地址，Redis、ZooKeeper、Eureka、MySQL、Nginx等中間件都運(yùn)行在這臺(tái)虛擬機(jī)上，大家在運(yùn)行crazy-springcloud微服務(wù)開(kāi)發(fā)腳手架之前需要進(jìn)行相應(yīng)的更改。

最后介紹一下有關(guān)主機(jī)名稱(chēng)的配置。如果在調(diào)試過(guò)程中直接通過(guò)IP訪問(wèn)REST接口，那么在Fiddler工具抓包中查看報(bào)文就不方便。為了方便抓包，將IP地址都映射成主機(jī)名稱(chēng)。在筆者使用的Windows開(kāi)發(fā)環(huán)境中，hosts文件內(nèi)配置的主機(jī)名稱(chēng)如下：

127.0.0.1 crazydemo.com
127.0.0.1 file.crazydemo.com
127.0.0.1 admin.crazydemo.com
127.0.0.1 xxx.crazydemo.com
192.168.233.128 eureka.server
192.168.233.128 zuul.server
192.168.233.128 nginx.server
192.168.233.128 admin.nginx.server

注意，本書(shū)后文的演示用例用到的URL會(huì)使用以上主機(jī)名稱(chēng)取代IP地址。

使用Fiddler工具抓包和查看報(bào)文

在微服務(wù)程序開(kāi)發(fā)和驗(yàn)證的過(guò)程中，一般來(lái)說(shuō)對(duì)HTTP接口發(fā)起請(qǐng)求有多種方式：

（1）直接發(fā)起請(qǐng)求。

（2）通過(guò)內(nèi)部網(wǎng)關(guān)代理（如Zuul）發(fā)起請(qǐng)求。

（3）通過(guò)外部網(wǎng)關(guān)反向代理（如Nginx）發(fā)起請(qǐng)求。

以crazy-springcloud腳手架中的uaa-provider服務(wù)的HTTP接口/api/user/detail/v1為例，通過(guò)以上3種方式發(fā)起請(qǐng)求的HTTP鏈路示意圖如圖1-2所示。

圖1-2 3種方式請(qǐng)求uaa-provider的HTTP鏈路示意圖

在生產(chǎn)環(huán)境下，為了滿(mǎn)足內(nèi)外網(wǎng)之間的轉(zhuǎn)發(fā)、多服務(wù)器之間的負(fù)載均衡要求，外部反向代理（Nginx）往往不止一層。因此，請(qǐng)求的HTTP鏈路往往更加復(fù)雜。

無(wú)論是在開(kāi)發(fā)環(huán)境、自驗(yàn)證環(huán)境、測(cè)試環(huán)境還是在生產(chǎn)環(huán)境中，查看HTTP接口的訪問(wèn)鏈路和報(bào)文內(nèi)容對(duì)于定位、分析、解決問(wèn)題來(lái)說(shuō)都非常重要，這就需要使用抓包工具。抓包工具的類(lèi)型比較多，筆者目前使用較多的為Fiddler。

比如，在調(diào)試本書(shū)crazy-springcloud腳手架中的uaa-provider功能時(shí)，使用Fiddler能全面地查看發(fā)往服務(wù)端的HTTP報(bào)文的請(qǐng)求頭和響應(yīng)頭，如圖1-3所示。

圖1-3 使用Fiddler查看請(qǐng)求頭和響應(yīng)頭

在開(kāi)發(fā)過(guò)程中，F(xiàn)iddler這類(lèi)抓包工具的使用對(duì)于分析和定位問(wèn)題非常有用。筆者經(jīng)常使用Fiddler完成下面的工作：

（1）查看REST接口的處理時(shí)間，在解決性能問(wèn)題時(shí)幫助查看接口的整體時(shí)間。

（2）查看REST接口的請(qǐng)求頭、響應(yīng)頭、響應(yīng)內(nèi)容，主要用于查看請(qǐng)求URL、請(qǐng)求頭、響應(yīng)頭是否正確，并且在必要的時(shí)候可以將所有請(qǐng)求頭一次性地復(fù)制到Postman等請(qǐng)求發(fā)起工具，幫助新請(qǐng)求快速地構(gòu)造同樣的HTTP頭部。

（3）請(qǐng)求重發(fā)，除了可以使用獨(dú)立的請(qǐng)求工具（如SwaggerUI/Postman等）重發(fā)請(qǐng)求之外，還可以在Fiddler中直接進(jìn)行請(qǐng)求重發(fā)，重發(fā)的請(qǐng)求有相同的頭部和參數(shù)，調(diào)試時(shí)非常方便。

crazy-springcloud微服務(wù)開(kāi)發(fā)腳手架

無(wú)論是單體應(yīng)用還是分布式應(yīng)用，如果從零開(kāi)始開(kāi)發(fā)，那么都會(huì)涉及很多基礎(chǔ)性的、重復(fù)性的工作，比如用戶(hù)認(rèn)證、Session管理等。

有了開(kāi)發(fā)腳手架，這些基礎(chǔ)工作就可以省去，直接利用腳手架提供的基礎(chǔ)模塊，然后按照腳手架的規(guī)范進(jìn)行業(yè)務(wù)模塊的開(kāi)發(fā)即可。

筆者在開(kāi)源平臺(tái)看到過(guò)不少開(kāi)源的腳手架，但是發(fā)現(xiàn)這些腳手架很少可以直接拿來(lái)進(jìn)行業(yè)務(wù)模塊的開(kāi)發(fā)，要么封裝過(guò)于重量級(jí)而不好解耦，要么業(yè)務(wù)模塊分包不清晰而不方便開(kāi)發(fā)，所以本著簡(jiǎn)潔和清晰的原則，筆者發(fā)起的瘋狂創(chuàng)客圈社群推出了自己的微服務(wù)開(kāi)發(fā)腳手架crazy-springcloud，它的模塊和功能如下：

crazymaker-server -- 根項(xiàng)目
│ ├─cloud-center -- 微服務(wù)的基礎(chǔ)設(shè)施中心
│ │ ├─cloud-eureka -- 注冊(cè)中心
│ │ ├─cloud-config -- 配置中心
│ │ ├─cloud-zuul -- 網(wǎng)關(guān)服務(wù)
│ │ ├─cloud-zipkin -- 監(jiān)控中心
│ ├─crazymaker-base -- 公共基礎(chǔ)依賴(lài)模塊
│ │ ├─base-common -- 普通的公共依賴(lài)，如utils類(lèi)的公共方法
│ │ ├─base-redis -- 公共的Redis操作模塊
│ │ ├─base-zookeeper -- 公共的ZooKeeper操作模塊
│ │ ├─base-session -- 分布式Session模塊
│ │ ├─base-auth -- 基于JWT + SpringSecurity的用戶(hù)憑證與認(rèn)證模塊
│ │ ├─base-runtime -- 各Provider的運(yùn)行時(shí)公共依賴(lài)，裝配了一些通用Spring
 IOC Bean實(shí)例
│ ├─crazymaker-uaa -- 業(yè)務(wù)模塊: 用戶(hù)認(rèn)證與授權(quán)
│ │ ├─uaa-api -- 用戶(hù)DTO、Constants等
│ │ ├─uaa-client -- 用戶(hù)服務(wù)的Feign遠(yuǎn)程客戶(hù)端
│ │ ├─uaa-provider -- 用戶(hù)認(rèn)證與權(quán)限的實(shí)現(xiàn)，包含controller層、service層、dao層的代碼實(shí)現(xiàn)
│ ├─crazymaker-seckill -- 業(yè)務(wù)模塊：秒殺練習(xí)
│ │ ├─seckill-api -- 秒殺DTO、Constants等
│ │ ├─seckill-client -- 秒殺服務(wù)的Feign遠(yuǎn)程調(diào)用模塊
│ │ ├─seckill-provider -- 秒殺服務(wù)核心實(shí)現(xiàn)，包含controller層、service層、 dao層的代碼實(shí)現(xiàn)
│ ├─crazymaker-demo -- 業(yè)務(wù)模塊：練習(xí)演示
│ │ ├─demo-api -- 演示模塊的DTO、Constants等
│ │ ├─demo-client -- 演示模塊的Feign遠(yuǎn)程調(diào)用模塊
│ │ ├─demo-provider -- 演示模塊的核心實(shí)現(xiàn)，包含controller層、service層、 dao層的代碼實(shí)現(xiàn)

在業(yè)務(wù)模塊如何分包的問(wèn)題上，大部分企業(yè)都有自己的統(tǒng)一規(guī)范。crazy-springcloud腳手架從職責(zé)清晰、方便維護(hù)、能快速導(dǎo)航代碼的角度出發(fā)，將每一個(gè)業(yè)務(wù)模塊細(xì)分成以下3個(gè)子模塊。

（1）{module}-api：該子模塊定義了一些公共的Constants業(yè)務(wù)常量和DTO傳輸對(duì)象，既被業(yè)務(wù)模塊內(nèi)部依賴(lài)，又可能被依賴(lài)該業(yè)務(wù)模塊的外部模塊所依賴(lài)。

（2）{module}-client：該子模塊定義了一些被外部模塊所依賴(lài)的Feign遠(yuǎn)程調(diào)用客戶(hù)類(lèi)，是專(zhuān)供給外部模塊的依賴(lài)，不能被內(nèi)部的其他子模塊所依賴(lài)。

（3）{module}-provider：該子模塊是整個(gè)業(yè)務(wù)模塊的核心，也是一個(gè)能夠獨(dú)立啟動(dòng)、運(yùn)行的服務(wù)提供者（Application）。該模塊包含涉及業(yè)務(wù)邏輯的controller層、service層、dao層的完整代碼實(shí)現(xiàn)。

crazy-springcloud微服務(wù)開(kāi)發(fā)腳手架在以下兩方面進(jìn)行了弱化：

（1）在部署方面對(duì)容器的介紹進(jìn)行了弱化，沒(méi)有使用Docker容器而是使用Shell腳本。這有多方面的原因：一是本腳手架的目的是學(xué)習(xí)，使用Shell腳本而不是Docker去部署，方便大家學(xué)習(xí)Shell命令和腳本；二是Java和Docker其實(shí)整合得很好，學(xué)習(xí)起來(lái)非常容易，稍加配置就能做到一鍵發(fā)布，找點(diǎn)資料學(xué)習(xí)一下就可以輕松掌握；三是部署和運(yùn)維是一項(xiàng)專(zhuān)門(mén)的工作，生產(chǎn)環(huán)境的部署，甚至是整個(gè)自動(dòng)化構(gòu)建和部署的工作實(shí)際上是屬于運(yùn)維的專(zhuān)項(xiàng)工作，由專(zhuān)門(mén)的運(yùn)維人員去完成，而部署的核心仍然是Shell腳本，所以對(duì)于開(kāi)發(fā)人員來(lái)說(shuō)掌握Shell腳本才是重中之重。

（2）對(duì)監(jiān)控軟件的介紹進(jìn)行了弱化。本書(shū)沒(méi)有專(zhuān)門(mén)介紹鏈路監(jiān)控、JVM性能指標(biāo)、熔斷器監(jiān)控軟件的使用，這也有多方面的原因：一是監(jiān)控軟件太多，如果介紹得太全，篇幅就不夠，介紹得太少，大家又不一定會(huì)用到；二是監(jiān)控軟件的使用大多是一些軟件的操作步驟和說(shuō)明，原理性的內(nèi)容比較少，傳播這類(lèi)知識(shí)使用視頻的形式比文字的形式效果更好。瘋狂創(chuàng)客圈后續(xù)可能會(huì)推出一些微服務(wù)監(jiān)控方面的教學(xué)視頻供大家參考，請(qǐng)大家關(guān)注社群博客。無(wú)論如何，只要掌握了Spring Cloud的核心原理，那么掌握監(jiān)控組件的使用對(duì)大家來(lái)說(shuō)基本上就是小菜一碟。

以秒殺作為Spring Cloud+Nginx的實(shí)戰(zhàn)案例

本文的綜合性實(shí)戰(zhàn)案例是實(shí)現(xiàn)一個(gè)高性能的秒殺系統(tǒng)。為何要以秒殺作為本書(shū)的綜合性實(shí)戰(zhàn)案例呢？先回顧一下在單體架構(gòu)還是主流的年代，大家學(xué)習(xí)J2EE技術(shù)時(shí)的綜合性實(shí)戰(zhàn)案例。一般來(lái)說(shuō)，都是從0開(kāi)始編寫(xiě)代碼，一行一行地編寫(xiě)一個(gè)購(gòu)物車(chē)應(yīng)用。通過(guò)編寫(xiě)購(gòu)物車(chē)應(yīng)用能對(duì)J2EE有一個(gè)全方位的練習(xí)，包括前端的HTML網(wǎng)頁(yè)、JavaScript腳本，后端的MVC框架、數(shù)據(jù)庫(kù)、事務(wù)、多線程等各種技術(shù)。

時(shí)代在變，技術(shù)的復(fù)雜度在變，前端和后端的分工也變了。現(xiàn)在的J2EE開(kāi)發(fā)已經(jīng)進(jìn)入分布式微服務(wù)架構(gòu)的時(shí)代，前端和后端框架都變得非常復(fù)雜，前端和后端工程師已經(jīng)有比較明確的分工。后端程序員專(zhuān)門(mén)做Java開(kāi)發(fā)，前端程序員專(zhuān)門(mén)做前端的開(kāi)發(fā)。后端程序員可以不需要懂前端的技術(shù)，如Vue、TypeScript等，當(dāng)然，很多前端程序員也不一定需要懂后端技術(shù)。

相比單體服務(wù)時(shí)代，現(xiàn)在的分布式開(kāi)發(fā)時(shí)代學(xué)習(xí)Java后端技術(shù)的難度大多了。首先面臨一大堆分布式、高性能中間件的學(xué)習(xí)，比如Netty、ZooKeeper、RabbitMQ、Spring Cloud、Redis等都是當(dāng)今后端程序員必知必會(huì)的。然后像JMeter這類(lèi)壓力測(cè)試工具和Fiddler這類(lèi)抓包工具，已經(jīng)成為每個(gè)后端程序員必須掌握的知識(shí)。因?yàn)樵诜植际江h(huán)境下需要定位、發(fā)現(xiàn)并解決數(shù)據(jù)一致性、高可靠性等問(wèn)題，通過(guò)壓力測(cè)試，本來(lái)很正常的代碼也會(huì)在運(yùn)行時(shí)出現(xiàn)很多性能相關(guān)的問(wèn)題。

另外，隨著移動(dòng)互聯(lián)網(wǎng)、物聯(lián)網(wǎng)的發(fā)展，當(dāng)前面臨的高并發(fā)場(chǎng)景已經(jīng)不局限于電商，在其他的應(yīng)用中也越來(lái)越多。所以，現(xiàn)在高并發(fā)開(kāi)發(fā)技術(shù)由少數(shù)工程師需要掌握的高精尖技術(shù)變成了大多數(shù)人都需要掌握的基礎(chǔ)技能。一般來(lái)說(shuō)，高并發(fā)開(kāi)發(fā)的三大利器為緩存、降級(jí)和限流。緩存的目的是提高系統(tǒng)訪問(wèn)速度，它是對(duì)抗高并發(fā)的銀彈；而降級(jí)是當(dāng)服務(wù)出問(wèn)題或者服務(wù)影響到核心流程時(shí)，可以將服務(wù)暫時(shí)屏蔽掉，待高峰或者問(wèn)題解決后再打開(kāi)；而有些場(chǎng)景并不能用緩存和降級(jí)來(lái)解決，比如稀缺資源（秒殺、搶購(gòu)）、寫(xiě)數(shù)據(jù)（如評(píng)論、下單）等，這種情況下可以使用限流措施來(lái)對(duì)接口進(jìn)行保護(hù)。

有了緩存、降級(jí)和限流這三大利器，遇到像京東618、阿里雙11這樣的高并發(fā)應(yīng)用場(chǎng)景，才不用擔(dān)心瞬間流量導(dǎo)致系統(tǒng)雪崩，哪怕是最終只能做到有損的服務(wù)，也不會(huì)出現(xiàn)某些小電商平臺(tái)在活動(dòng)期間服務(wù)器宕機(jī)數(shù)小時(shí)的事故。

秒殺程序的業(yè)務(wù)足夠簡(jiǎn)單，涉及的技術(shù)又足夠全面，可以說(shuō)是分布式應(yīng)用場(chǎng)景非常好的實(shí)戰(zhàn)案例。另外，現(xiàn)在IT行業(yè)人才流動(dòng)性比較大，大家都會(huì)為面試做準(zhǔn)備。在面試中，秒殺業(yè)務(wù)所覆蓋的緩存、降級(jí)、高并發(fā)限流、分布式鎖、分布式ID、數(shù)據(jù)一致性等問(wèn)題一般是重點(diǎn)、熱門(mén)問(wèn)題。

本文給大家講解的內(nèi)容是Spring Cloud+Nginx架構(gòu)的主要組件

1. 下篇文章給大家講解的是Spring Cloud入門(mén)實(shí)戰(zhàn)；

2. 覺(jué)得文章不錯(cuò)的朋友可以轉(zhuǎn)發(fā)此文關(guān)注小編；

3. 感謝大家的支持!