1.分布式項目為什么會崛起 有那些優勢 什么是分布式項目
在沒有分布式項目之前，一個系統所有的功能可能都是在一個項目中創建的，拿商城項目來說明
商城項目組成部分（基礎數據，用戶，商品，訂單，支付，一些輔助的排程/腳本服務）
在沒有分布式項目之前，這些可能都是寫在同一個項目中，然后把項目放到不同的服務器 A/B/C服務器。最前端有一個NGINX服務器，負責做負載均衡，客戶端請求的是Nginx服務器，由Nginx把請求轉發到A/B/C服務器，來減輕 在高並發的情況下，單服務器的壓力。
1.1什么是分布式項目,我們先來看下 傳統項目和分布式項目的結構圖
傳統項目
分布式項目
從項目結構圖中可以看出，傳統項目所有模塊都創建在一個項目中的，而分布式項目是按照不同的模塊創建不同的項目，模塊和模塊之間的耦合度得到了解耦，
1.DB風險
項目發布也不需要整個項目發布，只需要發布對應的模塊項目即可，分了模塊數據庫也得到了划分，假設那一天 某個程序員不小心把數據庫給刪除了，在傳統項目中所有模塊都是放在同一個數據庫的，這樣就會導致整個系統的DB都沒了，而分布式項目項目划分了模塊，數據庫也得到了切割，即使刪除也是刪除一個模塊的數據庫，雖然這樣也是災難性的操作，不過這樣也降低了風險。
2.發布風險
項目發布如果設計到修改文件過多，是需要真個項目發布，假設需要發布用戶模塊的一個bug，而小A在修復訂單模塊bug的時候，沒測試就提交了代碼，這個時候發布就會把bug發布到正式環境，從而影響到客戶使用，可能你會說不是有人會check代碼嗎？發布前都要做文件檢測的，是人都會有犯錯和疏漏，我們要在源頭把風險降低到最低。
說道這里就想起來最近阿里的一件事情，一個實習生把阿里雲的一個xx刪了，導致阿里雲系統出現故障。
3.項目解耦&降低訪問並發量
傳統項目，當訪問訂單接口的時候，還是會訪問整個系統所在的tomcat服務。用數據來說 比如有一萬個用戶訪問訂單模塊，這時候並發是一萬，對於tomcat來說是很有壓力，即使前端有Nginx做了負載，不過有的時候還是會存在丟失數據的情況。如果這個時候還有其他模塊的訪問量，那么對於tomcat的壓力就更大了。
https://blog.csdn.net/hll814/article/details/50935765
大禹治水分而治之，分布式項目也是這樣道理。
不同的模塊放放在不同的tomcat里面，即使訂單模塊服務掛了，也不會影響到登錄和用戶模塊的訪問。
Spring Cloud 流程圖
個人理解的 spring cloud 流程，如有不對 歡迎留言...
// 注冊中心管理器 private java.util.List<String> service = new ArrayList<String>(); public static void main(String[] args) { // 客戶端請求 zuul("/user/userInfo/getInfoById"); } /** * zuul 路由/網關 接受客戶端請求 轉發到對應的服務 **/ public static void zuul(String url) { // 1.匹配url 定位serviceId 【equals只是一個象征性的假設 匹配規則是xxx開頭的url 轉發到xxx服務】 if (url.equals("/user/**")) { // 轉發到【用戶服務】 serviceId 【serviceId對應一個項目 每個項目都有一個serviceId】 } if (url.equals("/order/**")) { // 轉發到【訂單服務】 serviceId 【serviceId對應一個項目 每個項目都有一個serviceId】 } if (url.equals("/basedata/**")) { // 轉發到【基礎數據服務】 serviceId 【serviceId對應一個項目 每個項目都有一個serviceId】 } // ...很多個if判斷 } /** * serviceId 服務ID/名稱 當項目啟動的時候 會把服務注冊到注冊中心【eureka】 注冊中心統一管理服務 **/ public void setService(String serviceId) { service.add(serviceId); } //zuul 等同於nginx的 根據URL匹配不同的服務 /*http { server { server_name example.com; location /mail/ { proxy_pass http://example.com:protmail/; } location /com/ { proxy_pass http://example.com:portcom/main/; } location / { proxy_pass http://example.com:portdefault; } } }*/
2.介紹
spring cloud核心組成部分
1.路由 Zuul
簡介
Zuul是Netflix基於JVM的路由器和服務器端負載均衡器。最常用的場景是替換Nginx反向代理后台微服務供前端UI訪問。
Zuul使用Ribbon來定位一個通過發現轉發的實例，所有請求都以hystrix命令執行，所以故障將顯示在Hystrix指標中。
注：Zuul不包括發現客戶端，因此對於基於服務ID的路由，需要在類路徑中提供其中一個路由
Zuul的能力：
智能路由：通過與Eureka整合，將自身注冊到服務中心，可以獲到所有其他微服務實例信息。Zuul默認通過以服務名作為ContextPath來創建路由映射，可以滿足大多數情況需要，特殊路由可以通過配置來實現,在Zuul默認路由規則小節有詳細描述。
2.注冊中心
收集袋，所有的服務進行統一收集,相當於放到同一個代碼塊，代碼塊里面的變量是可以直接拿到的。
3.配置中心
所有配置不配置在本地，而是配置在GIT里面,從GIT獲取配置信息。
也可以把配置中心搞錯一個集群，在並發獲取配置文件的時候，可以減輕單服務的壓力。
配置文件放本地和放到git上，除了方便管理還有一點是 在使用@value注解獲取配置信息的時候，如果配置文件中信息發生變化，需要重啟服務，這個一般是不可取的。
簡單的來說 spring cloud 配置中心 解耦了@value注解對配置文件讀取的操作。
4.斷路器監控(Hystrix)
當程序訪問接口，接口所依賴的服務出現故障，會導致訪問時間過長，線程消耗，堵塞 系統宕機。
用Hystrix可以很好的避開這一點。