Spring Cloud+Nginx架構的主要組件

以crazy-springcloud開發(fā)腳手架為例鳍侣，一個Spring Cloud+Nginx應用的架構如圖1-1所示篱蝇。

Nginx作為反向代理服務器悔常，代理內部Zuul網關服務，通過Nginx自帶的負載均衡算法實現客戶端請求的代理轉發(fā)、負載均衡等功能。

Zuul網關主要實現了微服務集群內部的請求路由萝喘、負載均衡、統(tǒng)一校驗等功能琼懊。雖然在路由服務和負載均衡方面阁簸，Zuul和Nginx的功能比較類似，但是Zuul是自身注冊到Eureka/Nacos哼丈，通過微服務的serviceID實現微服務提供者之間的路由和轉發(fā)启妹。

Eureka、Nacos都是Spring Cloud技術體系中提供服務注冊與發(fā)現的中間件醉旦。Eureka是Netflix開源的一款產品饶米，提供了完整的服務注冊和發(fā)現，是Spring Cloud“全家桶”中的核心組件之一车胡。

Nacos是阿里巴巴推出來的一個開源項目檬输，也是一個服務注冊與發(fā)現中間件，它用于完成服務的動態(tài)注冊吨拍、動態(tài)發(fā)現褪猛、服務管理，還兼具了配置管理的功能羹饰。Nacos提供了一組簡單易用的特性集，用于實現動態(tài)服務發(fā)現碳却、服務配置队秩、服務元數據及流量管理。

由于新版本的Eureka已經閉源昼浦，而阿里巴巴的Nacos除了具備Eureka注冊中心功能外馍资，還具備Spring Cloud Config配置中心的功能，因此大大地降低了使用和維護的成本关噪。另外鸟蟹，Nacos還具有分組隔離功能乌妙，一套Nacos集群可以支撐多項目、多環(huán)境建钥。綜合上述多個原因藤韵，在實際的開發(fā)場景中，推薦大家使用Nacos熊经。但是泽艘，本文出于學習目的，注冊中心和配置中心的內容還是介紹Eureka+Config組合镐依，其實在原理上匹涮，Nacos和Eureka+Config組合是差不多的。

除了一系列基礎設施中間件技術組件之外槐壳，微服務架構中大部分獨立業(yè)務模型都是以服務提供者的角色出現的然低。一般來說，系統(tǒng)可以按照各類業(yè)務模塊進行細粒度的微服務拆分务唐，例如秒殺系統(tǒng)中的用戶雳攘、商品等，每個業(yè)務模塊拆分成一個微服務提供者Provider組件绍哎，作為獨立應用程序進行啟動和執(zhí)行来农。

在Spring Cloud生態(tài)中，微服務提供者Provider之間的遠程調用是通過Feign+Ribbon+Hystrix組合來完成的：Feign用于完成RPC遠程調用的代理封裝崇堰；Ribbon用于在客戶端完成各遠程目標服務實例之間的負載均衡沃于；Hystrix用于完成自動熔斷降級等多個維度的RPC保護。在Nginx+Spring Cloud架構中還存在一系列輔助中間件海诲，包括日志記錄繁莹、鏈路跟蹤、應用監(jiān)控特幔、JVM性能指標咨演、物理資源監(jiān)控等等。本文并沒有對上述輔助中間件做專門的介紹蚯斯。

Spring Cloud和Spring Boot的版本選擇

Spring Cloud是基于Spring Boot構建的薄风，它們之間的版本有配套的對應關系。在構建項目時拍嵌，要注意版本之間的這種對應關系遭赂，版本若對應不上則會出現問題。

Spring Cloud和Spring Boot的版本配套關系如表1-1所示横辆。

表1-1　Spring Cloud與Spring Boot的版本配套關系

Spring Cloud包含一系列子組件撇他，如Spring Cloud Config、Spring Cloud Netflix、Spring Cloud Openfeign等困肩，為了防止與這些子組件的版本號混淆划纽，Spring Cloud的版本號全部使用英文單詞形式命名。具體來說锌畸，Spring Cloud的版本號使用了英國倫敦地鐵站的名稱來命名勇劣，并按字母A~Z的次序發(fā)布版本，它的第一個版本叫作Angel蹋绽，第二個版本叫作Brixton芭毙，以此類推卸耘。另外，每個大版本在解決了一個嚴重的Bug后蚣抗，Spring Cloud會發(fā)布一個Service Release版本（小版本），簡稱SRX版本翰铡，其中X是順序的編號钝域，比如Finchley.SR4是Finchley大版本的第4個小版本。

大家做技術選型時非常喜歡用最高版本锭魔，但是對于Spring全家桶的選擇來說例证，高版本不一定是最佳選擇。比如迷捧，目前最高的Spring CloudHoxton版本是基于Spring Boot 2.2構建的织咧，Spring Boot 2.2又是基于Spring Framework 5.2構建的，也就是說漠秋，這是一次整體的笙蒙、全方位的大版本升級。大家在項目上會用到非常多的第三方組件庆锦，總會有一些組件沒有來得及進行配套升級而不能兼容Spring Boot 2.2或SpringFramework 5.2捅位，如果貿然地進行基礎框架的整體升級，就會給項目開發(fā)帶來各種各樣的疑難雜癥搂抒，甚至帶來潛在的線上Bug艇搀。

除此之外，Spring Cloud高版本推薦了不少自家的新組件求晶，但是這些新組件沒有經過大規(guī)模實踐應用的考驗中符，其功能尚待豐富和完善。以負載均衡組件為例誉帅，Spring Cloud Hoxton推薦的自家組件spring?cloud-loadbalancer在功能上與Ribbon的負載均衡功能相比就弱很多。

Spring Cloud Finchley到Greenwich版本的升級其實很小，可以說微乎其微蚜锨，主要是提升了對Java 11的兼容性档插。然而，在當前的生產場景中Java 8才是各大項目的主流選擇亚再，另外Java 11（2019年4月之后的升級補豆拧）已經不完全免費了氛悬。當然如捅，和Java 11一樣己肮，Java 8在2019年4月之后的補丁版本也面臨收費的問題谎僻。使用Java 8的理由是艘绍，自2014年3月18日發(fā)布起至目前诱鞠，Java 8被廣泛使用般甲，且被維護了這么多年敷存，已經非常成熟和穩(wěn)定了锚烦。

綜上所述涮俄，本文選用了Spring Cloud Finchley作為學習孕锄、研究和使用的版本畸肆，推薦使用的子版本為Finchley.SR4轴脐。具體的Maven依賴坐標如下：

org.springframework.cloudspring-cloud-dependenciesFinchley.SR4pomimportorg.springframework.bootspring-boot-dependencies2.0.8.RELEASEimportpom

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

在基于crazy-springcloud腳手架（其他的腳手架類似）的微服務開發(fā)和自驗證過程中大咱，所涉及的基礎中間件大致如下：

1.ZooKeeper

ZooKeeper是一個開放源碼的分布式協(xié)調應用程序注益，是大數據框架Hadoop和HBase的重要組件聊浅。在分布式應用中旷痕，它能夠高可用地提供保

障數據一致性的很多基礎功能：分布式鎖欺抗、選主绞呈、分布式命名服務等佃声。

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

2.Redis

Redis是一個高性能的緩存數據庫曹铃。在高并發(fā)的場景下陕见，Redis可以對關系數據庫起到很好的緩沖作用直撤；在提高系統(tǒng)的并發(fā)能力和響應速度方面，Redis至關重要承匣。crazy-springcloud腳手架的分布式Session用到了Redis韧骗。

3.Eureka

Eureka是Netflix開發(fā)的服務注冊和發(fā)現框架袍暴，它本身是一個REST服務提供者政模，主要用于定位運行在AWS（Amazon云）上的中間層服務，以達到負載均衡和中間層服務故障轉移的目的胁住。Spring Cloud將Eureka集成在子項目spring-cloud-netflix中彪见，以實現Spring Cloud的服務注冊和發(fā)現功能捕犬。

4.Spring Cloud Config

Spring Cloud Config是Spring Cloud全家桶中最早的配置中心或听，雖然在生產場景中很多企業(yè)已經使用Nacos或者Consul整合型的配置中心替代了獨立的配置中心誉裆，但是Config依然適用于Spring Cloud項目足丢，通過簡單地配置即可使用。

5.Zuul

Zuul是Netflix開源網關绍些，可以和Eureka柬批、Ribbon氮帐、Hystrix等組件配合使用上沐，Spring Cloud對Zuul進行了整合與增強，使用它作為微服務集群的內部網關硫眯，負責給集群內部的各個Provider（服務提供者）提供RPC路由和對請求進行過濾戈盈。

6.Nginx/OpenResty

Nginx是一個高性能HTTP和反向代理服務器塘娶，是由伊戈爾·賽索耶夫為俄羅斯訪問量第二的Rambler.ru站點開發(fā)的Web服務器刁岸。Nginx源代碼以類BSD許可證的形式對外發(fā)布虹曙，它的第一個公開版本0.1.0在2004年10月4日發(fā)布酝碳，1.0.4版本在2011年6月1日發(fā)布疏哗。Nginx因高穩(wěn)定性贝搁、豐富的功能集雷逆、內存消耗少膀哲、并發(fā)能力強而聞名全球等太，并被廣泛使用，百度包颁、京東娩嚼、新浪岳悟、網易贵少、騰訊滔灶、淘寶等都是它的用戶录平。OpenResty是一個基于Nginx與Lua的高性能Web平臺，它的內部集成了大量精良的Lua庫表箭、第三方模塊以及大多數的依賴項趁怔，用于快速搭建能夠處理超高并發(fā)的擴展性極高的動態(tài)Web應用伯襟、Web服務和動態(tài)網關姆怪。

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

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

Spring Cloud微服務開發(fā)和自驗證環(huán)境

在開始學習Spring Cloud核心編程之前事镣，先來介紹一下開發(fā)和自驗證環(huán)境的準備璃哟、中間件的安裝以及抓包工具的準備。

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

首先介紹開發(fā)和自驗證系統(tǒng)的選型铐伴。大部分開發(fā)人員學習開發(fā)都用過Windows環(huán)境当宴，在這種情況下即供，強烈建議使用虛擬機裝載CentOS作為自驗證環(huán)境逗嫡。為什么要推薦CentOS呢驱证？

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

在生產環(huán)境上，90%以上的Java應用都是使用Linux環(huán)境（如CentOS）來部署的。因此获高，使用CentOS作為自驗證環(huán)境可以提前暴露生產環(huán)境中的潛在問題，避免在開發(fā)時沒有發(fā)現有問題的程序摊趾，一旦部署到生產環(huán)境中就出現問題（筆者親歷）砾层。

2.學習Shell命令和腳本

在生產環(huán)境中定位、分析贱案、解決線上Bug時肛炮，需要用到基礎的Shell命令和腳本，因此平時要多使用宝踪、多練習铸董。另外，Shell命令和腳本是Java程序員必知必會的面試題肴沫。使用CentOS作為自驗證環(huán)境能方便大家學習Shell命令和腳本。

當然蕴忆，可以借助一些文件同步或共享工具提高開發(fā)效率卓鹿。比如，可以通過VMware Tools共享Windows和CentOS之間的文件夾巷挥，這樣在后續(xù)的Lua腳本的開發(fā)和調試過程中能避免來回地復制文件。

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

（1）中間件（含Eureka哈雏、Redis彭羹、MySQL等）相關信息的環(huán)境變量的配置毡惜。

（2）主機名稱的配置帕膜。

對于中間件相關信息（如IP地址危纫、端口搪桂、用戶賬號等），很多項目都是直接以明文編碼的方式存放在配置文件中，這樣存在安全隱患甚至會引發(fā)泄密的風險饵筑。對于這些信息，建議通過操作系統(tǒng)環(huán)境變量進行配置，然后在配置文件中使用環(huán)境變量而不是明文編碼骂铁。

例如茫蛹，可以對Eureka的IP提前配置好環(huán)境變量EUREKA_ZONE_HOST欢唾，然后在應用的配置文件bootstrap.yml中按照如下方式來使用：

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

在上面的配置中，通過${

SCAFFOLD_EUREKA_ZONE_HOSTS}表達式從環(huán)境變量中獲取Eureka的service-url地址。環(huán)境變量SCAFFOLD_EUREKA_ZONE_HOSTS后面跟著一個冒號和一個默認值滥朱，表示如果環(huán)境變量值為空，就會使用默認值

http://localhost:7777/eureka/作為配置項的值麦乞。

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

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

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

exportSCAFFOLD_DB_HOST=192.168.233.128exportSCAFFOLD_DB_USER=rootexportSCAFFOLD_DB_PSW=rootexportSCAFFOLD_REDIS_HOST=192.168.233.128exportSCAFFOLD_REDIS_PSW=123456exportSCAFFOLD_EUREKA_ZONE_HOSTS=http://192.168.233.128:7777/eureka/exportRABBITMQ_HOST=192.168.233.128exportSCAFFOLD_ZOOKEEPER_HOSTS=192.168.233.128:2181

以上環(huán)境變量中的192.168.233.128是筆者自驗證環(huán)境CentOS虛擬機的IP地址胃惜，Redis牲阁、ZooKeeper役电、Eureka、MySQL棉胀、Nginx等中間件都運行在這臺虛擬機上法瑟，大家在運行crazy-springcloud微服務開發(fā)腳手架之前需要進行相應的更改。

最后介紹一下有關主機名稱的配置唁奢。如果在調試過程中直接通過IP訪問REST接口霎挟，那么在Fiddler工具抓包中查看報文就不方便。為了方便抓包麻掸，將IP地址都映射成主機名稱酥夭。在筆者使用的Windows開發(fā)環(huán)境中，hosts文件內配置的主機名稱如下：

127.0.0.1crazydemo.com127.0.0.1file.crazydemo.com127.0.0.1admin.crazydemo.com127.0.0.1xxx.crazydemo.com192.168.233.128eureka.server192.168.233.128zuul.server192.168.233.128nginx.server192.168.233.128admin.nginx.server

注意脊奋，本書后文的演示用例用到的URL會使用以上主機名稱取代IP地址熬北。

使用Fiddler工具抓包和查看報文

在微服務程序開發(fā)和驗證的過程中，一般來說對HTTP接口發(fā)起請求有多種方式：

（1）直接發(fā)起請求诚隙。

（2）通過內部網關代理（如Zuul）發(fā)起請求讶隐。

（3）通過外部網關反向代理（如Nginx）發(fā)起請求。

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

在生產環(huán)境下，為了滿足內外網之間的轉發(fā)地消、多服務器之間的負載均衡要求炉峰，外部反向代理（Nginx）往往不止一層。因此脉执，請求的HTTP鏈路往往更加復雜疼阔。

無論是在開發(fā)環(huán)境、自驗證環(huán)境适瓦、測試環(huán)境還是在生產環(huán)境中竿开，查看HTTP接口的訪問鏈路和報文內容對于定位、分析玻熙、解決問題來說都非常重要否彩，這就需要使用抓包工具。抓包工具的類型比較多嗦随，筆者目前使用較多的為Fiddler列荔。

比如，在調試本書crazy-springcloud腳手架中的uaa-provider功能時枚尼，使用Fiddler能全面地查看發(fā)往服務端的HTTP報文的請求頭和響應頭贴浙，如圖1-3所示。

在開發(fā)過程中署恍，Fiddler這類抓包工具的使用對于分析和定位問題非常有用崎溃。筆者經常使用Fiddler完成下面的工作：

（1）查看REST接口的處理時間，在解決性能問題時幫助查看接口的整體時間盯质。

（2）查看REST接口的請求頭袁串、響應頭、響應內容呼巷，主要用于查看請求URL囱修、請求頭、響應頭是否正確王悍，并且在必要的時候可以將所有請求頭一次性地復制到Postman等請求發(fā)起工具破镰，幫助新請求快速地構造同樣的HTTP頭部。

（3）請求重發(fā)压储，除了可以使用獨立的請求工具（如Swagger?UI/Postman等）重發(fā)請求之外鲜漩，還可以在Fiddler中直接進行請求重發(fā)，重發(fā)的請求有相同的頭部和參數渠脉，調試時非常方便宇整。

crazy-springcloud微服務開發(fā)腳手架

無論是單體應用還是分布式應用，如果從零開始開發(fā)芋膘，那么都會涉及很多基礎性的鳞青、重復性的工作，比如用戶認證为朋、Session管理等臂拓。

有了開發(fā)腳手架，這些基礎工作就可以省去习寸，直接利用腳手架提供的基礎模塊胶惰，然后按照腳手架的規(guī)范進行業(yè)務模塊的開發(fā)即可。

筆者在開源平臺看到過不少開源的腳手架霞溪，但是發(fā)現這些腳手架很少可以直接拿來進行業(yè)務模塊的開發(fā)孵滞，要么封裝過于重量級而不好解耦中捆，要么業(yè)務模塊分包不清晰而不方便開發(fā)，所以本著簡潔和清晰的原則坊饶，筆者發(fā)起的瘋狂創(chuàng)客圈社群推出了自己的微服務開發(fā)腳手架crazy-springcloud泄伪，它的模塊和功能如下：

crazymaker-server-- 根項目│ ├─cloud-center-- 微服務的基礎設施中心│ │ ├─cloud-eureka-- 注冊中心│ │ ├─cloud-config-- 配置中心│ │ ├─cloud-zuul-- 網關服務│ │ ├─cloud-zipkin-- 監(jiān)控中心│ ├─crazymaker-base-- 公共基礎依賴模塊│ │ ├─base-common-- 普通的公共依賴，如utils類的公共方法│ │ ├─base-redis-- 公共的Redis操作模塊│ │ ├─base-zookeeper-- 公共的ZooKeeper操作模塊│ │ ├─base-session-- 分布式Session模塊│ │ ├─base-auth-- 基于JWT + SpringSecurity的用戶憑證與認證模塊│ │ ├─base-runtime-- 各Provider的運行時公共依賴匿级，裝配了一些通用SpringIOC Bean實例│ ├─crazymaker-uaa-- 業(yè)務模塊: 用戶認證與授權│ │ ├─uaa-api-- 用戶DTO蟋滴、Constants等│ │ ├─uaa-client-- 用戶服務的Feign遠程客戶端│ │ ├─uaa-provider-- 用戶認證與權限的實現，包含controller層痘绎、service層津函、dao層的代碼實現│ ├─crazymaker-seckill-- 業(yè)務模塊：秒殺練習│ │ ├─seckill-api-- 秒殺DTO、Constants等│ │ ├─seckill-client-- 秒殺服務的Feign遠程調用模塊│ │ ├─seckill-provider-- 秒殺服務核心實現孤页，包含controller層尔苦、service層、 dao層的代碼實現│ ├─crazymaker-demo-- 業(yè)務模塊：練習演示│ │ ├─demo-api-- 演示模塊的DTO散庶、Constants等│ │ ├─demo-client-- 演示模塊的Feign遠程調用模塊│ │ ├─demo-provider-- 演示模塊的核心實現蕉堰，包含controller層、service層悲龟、 dao層的代碼實現

在業(yè)務模塊如何分包的問題上屋讶，大部分企業(yè)都有自己的統(tǒng)一規(guī)范。crazy-springcloud腳手架從職責清晰须教、方便維護皿渗、能快速導航代碼的角度出發(fā)，將每一個業(yè)務模塊細分成以下3個子模塊轻腺。

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

（2）{module}-client：該子模塊定義了一些被外部模塊所依賴的Feign遠程調用客戶類挤土，是專供給外部模塊的依賴，不能被內部的其他子模塊所依賴误算。

（3）{module}-provider：該子模塊是整個業(yè)務模塊的核心仰美，也是一個能夠獨立啟動、運行的服務提供者（Application）儿礼。該模塊包含涉及業(yè)務邏輯的controller層咖杂、service層、dao層的完整代碼實現蚊夫。

crazy-springcloud微服務開發(fā)腳手架在以下兩方面進行了弱化：

（1）在部署方面對容器的介紹進行了弱化诉字，沒有使用Docker容器而是使用Shell腳本。這有多方面的原因：一是本腳手架的目的是學習，使用Shell腳本而不是Docker去部署壤圃，方便大家學習Shell命令和腳本陵霉；二是Java和Docker其實整合得很好，學習起來非常容易伍绳，稍加配置就能做到一鍵發(fā)布撩匕，找點資料學習一下就可以輕松掌握；三是部署和運維是一項專門的工作墨叛，生產環(huán)境的部署，甚至是整個自動化構建和部署的工作實際上是屬于運維的專項工作模蜡，由專門的運維人員去完成漠趁，而部署的核心仍然是Shell腳本，所以對于開發(fā)人員來說掌握Shell腳本才是重中之重忍疾。

（2）對監(jiān)控軟件的介紹進行了弱化闯传。本書沒有專門介紹鏈路監(jiān)控、JVM性能指標卤妒、熔斷器監(jiān)控軟件的使用甥绿，這也有多方面的原因：一是監(jiān)控軟件太多，如果介紹得太全则披，篇幅就不夠共缕，介紹得太少，大家又不一定會用到士复；二是監(jiān)控軟件的使用大多是一些軟件的操作步驟和說明图谷，原理性的內容比較少，傳播這類知識使用視頻的形式比文字的形式效果更好阱洪。瘋狂創(chuàng)客圈后續(xù)可能會推出一些微服務監(jiān)控方面的教學視頻供大家參考便贵，請大家關注社群博客。無論如何冗荸，只要掌握了Spring Cloud的核心原理承璃，那么掌握監(jiān)控組件的使用對大家來說基本上就是小菜一碟。

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

本文的綜合性實戰(zhàn)案例是實現一個高性能的秒殺系統(tǒng)蚌本。為何要以秒殺作為本書的綜合性實戰(zhàn)案例呢盔粹？先回顧一下在單體架構還是主流的年代，大家學習J2EE技術時的綜合性實戰(zhàn)案例魂毁。一般來說玻佩，都是從0開始編寫代碼，一行一行地編寫一個購物車應用席楚。通過編寫購物車應用能對J2EE有一個全方位的練習咬崔，包括前端的HTML網頁、JavaScript腳本，后端的MVC框架垮斯、數據庫郎仆、事務、多線程等各種技術兜蠕。

時代在變扰肌，技術的復雜度在變，前端和后端的分工也變了⌒苎睿現在的J2EE開發(fā)已經進入分布式微服務架構的時代曙旭，前端和后端框架都變得非常復雜，前端和后端工程師已經有比較明確的分工晶府。后端程序員專門做Java開發(fā)桂躏，前端程序員專門做前端的開發(fā)。后端程序員可以不需要懂前端的技術川陆，如Vue剂习、TypeScript等，當然较沪，很多前端程序員也不一定需要懂后端技術鳞绕。

相比單體服務時代，現在的分布式開發(fā)時代學習Java后端技術的難度大多了尸曼。首先面臨一大堆分布式们何、高性能中間件的學習，比如Netty控轿、ZooKeeper垂蜗、RabbitMQ、Spring Cloud解幽、Redis等都是當今后端程序員必知必會的贴见。然后像JMeter這類壓力測試工具和Fiddler這類抓包工具，已經成為每個后端程序員必須掌握的知識躲株。因為在分布式環(huán)境下需要定位片部、發(fā)現并解決數據一致性、高可靠性等問題霜定，通過壓力測試档悠，本來很正常的代碼也會在運行時出現很多性能相關的問題。

另外望浩，隨著移動互聯網辖所、物聯網的發(fā)展，當前面臨的高并發(fā)場景已經不局限于電商磨德，在其他的應用中也越來越多缘回。所以吆视，現在高并發(fā)開發(fā)技術由少數工程師需要掌握的高精尖技術變成了大多數人都需要掌握的基礎技能。一般來說酥宴，高并發(fā)開發(fā)的三大利器為緩存啦吧、降級和限流。緩存的目的是提高系統(tǒng)訪問速度拙寡，它是對抗高并發(fā)的銀彈授滓；而降級是當服務出問題或者服務影響到核心流程時，可以將服務暫時屏蔽掉肆糕，待高峰或者問題解決后再打開般堆；而有些場景并不能用緩存和降級來解決，比如稀缺資源（秒殺诚啃、搶購）郁妈、寫數據（如評論、下單）等绍申，這種情況下可以使用限流措施來對接口進行保護。

有了緩存顾彰、降級和限流這三大利器极阅，遇到像京東618、阿里雙11這樣的高并發(fā)應用場景涨享，才不用擔心瞬間流量導致系統(tǒng)雪崩筋搏，哪怕是最終只能做到有損的服務，也不會出現某些小電商平臺在活動期間服務器宕機數小時的事故厕隧。

秒殺程序的業(yè)務足夠簡單奔脐，涉及的技術又足夠全面，可以說是分布式應用場景非常好的實戰(zhàn)案例吁讨。另外髓迎，現在IT行業(yè)人才流動性比較大，大家都會為面試做準備建丧。在面試中排龄，秒殺業(yè)務所覆蓋的緩存、降級翎朱、高并發(fā)限流橄维、分布式鎖、分布式ID拴曲、數據一致性等問題一般是重點争舞、熱門問題。

本文給大家講解的內容是Spring Cloud+Nginx架構的主要組件

下篇文章給大家講解的是Spring Cloud入門實戰(zhàn)澈灼；

覺得文章不錯的朋友可以轉發(fā)此文關注小編竞川；

感謝大家的支持!

在開發(fā)過程中，Fiddler這類抓包工具的使用對于分析和定位問題非常有用。筆者經常使用Fiddler完成下面的工作：

（1）查看REST接口的處理時間流译，在解決性能問題時幫助查看接口的整體時間逞怨。

（2）查看REST接口的請求頭、響應頭福澡、響應內容叠赦，主要用于查看請求URL、請求頭革砸、響應頭是否正確除秀，并且在必要的時候可以將所有請求頭一次性地復制到Postman等請求發(fā)起工具，幫助新請求快速地構造同樣的HTTP頭部算利。

（3）請求重發(fā)册踩，除了可以使用獨立的請求工具（如Swagger?UI/Postman等）重發(fā)請求之外，還可以在Fiddler中直接進行請求重發(fā)效拭，重發(fā)的請求有相同的頭部和參數暂吉，調試時非常方便。

crazy-springcloud微服務開發(fā)腳手架

無論是單體應用還是分布式應用缎患，如果從零開始開發(fā)慕的，那么都會涉及很多基礎性的、重復性的工作挤渔，比如用戶認證肮街、Session管理等。

有了開發(fā)腳手架判导，這些基礎工作就可以省去嫉父，直接利用腳手架提供的基礎模塊，然后按照腳手架的規(guī)范進行業(yè)務模塊的開發(fā)即可眼刃。

筆者在開源平臺看到過不少開源的腳手架绕辖，但是發(fā)現這些腳手架很少可以直接拿來進行業(yè)務模塊的開發(fā)，要么封裝過于重量級而不好解耦擂红，要么業(yè)務模塊分包不清晰而不方便開發(fā)引镊，所以本著簡潔和清晰的原則，筆者發(fā)起的瘋狂創(chuàng)客圈社群推出了自己的微服務開發(fā)腳手架crazy-springcloud篮条，它的模塊和功能如下：

crazymaker-server-- 根項目│ ├─cloud-center-- 微服務的基礎設施中心│ │ ├─cloud-eureka-- 注冊中心│ │ ├─cloud-config-- 配置中心│ │ ├─cloud-zuul-- 網關服務│ │ ├─cloud-zipkin-- 監(jiān)控中心│ ├─crazymaker-base-- 公共基礎依賴模塊│ │ ├─base-common-- 普通的公共依賴弟头，如utils類的公共方法│ │ ├─base-redis-- 公共的Redis操作模塊│ │ ├─base-zookeeper-- 公共的ZooKeeper操作模塊│ │ ├─base-session-- 分布式Session模塊│ │ ├─base-auth-- 基于JWT + SpringSecurity的用戶憑證與認證模塊│ │ ├─base-runtime-- 各Provider的運行時公共依賴，裝配了一些通用SpringIOC Bean實例│ ├─crazymaker-uaa-- 業(yè)務模塊: 用戶認證與授權│ │ ├─uaa-api-- 用戶DTO涉茧、Constants等│ │ ├─uaa-client-- 用戶服務的Feign遠程客戶端│ │ ├─uaa-provider-- 用戶認證與權限的實現赴恨，包含controller層、service層伴栓、dao層的代碼實現│ ├─crazymaker-seckill-- 業(yè)務模塊：秒殺練習│ │ ├─seckill-api-- 秒殺DTO伦连、Constants等│ │ ├─seckill-client-- 秒殺服務的Feign遠程調用模塊│ │ ├─seckill-provider-- 秒殺服務核心實現雨饺，包含controller層、service層惑淳、 dao層的代碼實現│ ├─crazymaker-demo-- 業(yè)務模塊：練習演示│ │ ├─demo-api-- 演示模塊的DTO额港、Constants等│ │ ├─demo-client-- 演示模塊的Feign遠程調用模塊│ │ ├─demo-provider-- 演示模塊的核心實現，包含controller層歧焦、service層移斩、 dao層的代碼實現

在業(yè)務模塊如何分包的問題上，大部分企業(yè)都有自己的統(tǒng)一規(guī)范绢馍。crazy-springcloud腳手架從職責清晰向瓷、方便維護、能快速導航代碼的角度出發(fā)舰涌，將每一個業(yè)務模塊細分成以下3個子模塊猖任。

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

（2）{module}-client：該子模塊定義了一些被外部模塊所依賴的Feign遠程調用客戶類，是專供給外部模塊的依賴搁痛，不能被內部的其他子模塊所依賴长搀。

（3）{module}-provider：該子模塊是整個業(yè)務模塊的核心，也是一個能夠獨立啟動落追、運行的服務提供者（Application）。該模塊包含涉及業(yè)務邏輯的controller層涯肩、service層轿钠、dao層的完整代碼實現。

crazy-springcloud微服務開發(fā)腳手架在以下兩方面進行了弱化：

（1）在部署方面對容器的介紹進行了弱化病苗，沒有使用Docker容器而是使用Shell腳本疗垛。這有多方面的原因：一是本腳手架的目的是學習，使用Shell腳本而不是Docker去部署硫朦，方便大家學習Shell命令和腳本贷腕；二是Java和Docker其實整合得很好，學習起來非常容易咬展，稍加配置就能做到一鍵發(fā)布泽裳，找點資料學習一下就可以輕松掌握；三是部署和運維是一項專門的工作破婆，生產環(huán)境的部署涮总，甚至是整個自動化構建和部署的工作實際上是屬于運維的專項工作，由專門的運維人員去完成祷舀，而部署的核心仍然是Shell腳本瀑梗，所以對于開發(fā)人員來說掌握Shell腳本才是重中之重烹笔。

（2）對監(jiān)控軟件的介紹進行了弱化。本書沒有專門介紹鏈路監(jiān)控抛丽、JVM性能指標谤职、熔斷器監(jiān)控軟件的使用，這也有多方面的原因：一是監(jiān)控軟件太多亿鲜，如果介紹得太全允蜈，篇幅就不夠，介紹得太少狡门，大家又不一定會用到陷寝；二是監(jiān)控軟件的使用大多是一些軟件的操作步驟和說明，原理性的內容比較少其馏，傳播這類知識使用視頻的形式比文字的形式效果更好凤跑。瘋狂創(chuàng)客圈后續(xù)可能會推出一些微服務監(jiān)控方面的教學視頻供大家參考，請大家關注社群博客叛复。無論如何仔引，只要掌握了Spring Cloud的核心原理，那么掌握監(jiān)控組件的使用對大家來說基本上就是小菜一碟褐奥。

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

本文的綜合性實戰(zhàn)案例是實現一個高性能的秒殺系統(tǒng)咖耘。為何要以秒殺作為本書的綜合性實戰(zhàn)案例呢？先回顧一下在單體架構還是主流的年代撬码，大家學習J2EE技術時的綜合性實戰(zhàn)案例儿倒。一般來說，都是從0開始編寫代碼呜笑，一行一行地編寫一個購物車應用夫否。通過編寫購物車應用能對J2EE有一個全方位的練習，包括前端的HTML網頁叫胁、JavaScript腳本凰慈，后端的MVC框架、數據庫驼鹅、事務微谓、多線程等各種技術。

時代在變输钩，技術的復雜度在變豺型，前端和后端的分工也變了。現在的J2EE開發(fā)已經進入分布式微服務架構的時代买乃，前端和后端框架都變得非常復雜触创，前端和后端工程師已經有比較明確的分工。后端程序員專門做Java開發(fā)为牍，前端程序員專門做前端的開發(fā)哼绑。后端程序員可以不需要懂前端的技術岩馍，如Vue、TypeScript等抖韩，當然蛀恩，很多前端程序員也不一定需要懂后端技術。

相比單體服務時代茂浮，現在的分布式開發(fā)時代學習Java后端技術的難度大多了双谆。首先面臨一大堆分布式、高性能中間件的學習席揽，比如Netty顽馋、ZooKeeper、RabbitMQ幌羞、Spring Cloud寸谜、Redis等都是當今后端程序員必知必會的。然后像JMeter這類壓力測試工具和Fiddler這類抓包工具属桦，已經成為每個后端程序員必須掌握的知識熊痴。因為在分布式環(huán)境下需要定位、發(fā)現并解決數據一致性聂宾、高可靠性等問題果善，通過壓力測試，本來很正常的代碼也會在運行時出現很多性能相關的問題系谐。

另外巾陕，隨著移動互聯網纪他、物聯網的發(fā)展鄙煤，當前面臨的高并發(fā)場景已經不局限于電商，在其他的應用中也越來越多止喷。所以馆类，現在高并發(fā)開發(fā)技術由少數工程師需要掌握的高精尖技術變成了大多數人都需要掌握的基礎技能混聊。一般來說弹谁，高并發(fā)開發(fā)的三大利器為緩存、降級和限流句喜。緩存的目的是提高系統(tǒng)訪問速度预愤，它是對抗高并發(fā)的銀彈；而降級是當服務出問題或者服務影響到核心流程時咳胃，可以將服務暫時屏蔽掉植康，待高峰或者問題解決后再打開；而有些場景并不能用緩存和降級來解決展懈，比如稀缺資源（秒殺销睁、搶購）、寫數據（如評論冻记、下單）等睡毒，這種情況下可以使用限流措施來對接口進行保護。

有了緩存冗栗、降級和限流這三大利器演顾，遇到像京東618、阿里雙11這樣的高并發(fā)應用場景隅居，才不用擔心瞬間流量導致系統(tǒng)雪崩钠至，哪怕是最終只能做到有損的服務，也不會出現某些小電商平臺在活動期間服務器宕機數小時的事故胎源。

秒殺程序的業(yè)務足夠簡單棉钧，涉及的技術又足夠全面，可以說是分布式應用場景非常好的實戰(zhàn)案例乒融。另外掰盘，現在IT行業(yè)人才流動性比較大，大家都會為面試做準備赞季。在面試中愧捕，秒殺業(yè)務所覆蓋的緩存、降級申钩、高并發(fā)限流次绘、分布式鎖、分布式ID撒遣、數據一致性等問題一般是重點邮偎、熱門問題。

本文給大家講解的內容是Spring Cloud+Nginx架構的主要組件

原文鏈接：https://www.toutiao.com/a6955418439607419425/?log_from=1af9b21edb0ae_1638517199430