Spring Cloud學習筆記（一）概要
什麼是微服務
微服務是一種架構風格，是以開發一組小型服務的方式來作爲一個獨立的應用系統，每個服務都運行在自已的進程中，服務之間採用輕量級的HTTP通信機制 ( 通常是採用HTTP的RESTful API )進行通信。些服務都是圍繞具體業務進行構建的，並且可以獨立部署到生產環境上。這些服務可以用不同的編程語言編寫，並且可以使用不同的數據存儲技術。對這些微服務我們只需要使用一個非常輕量級的集中式管理來進行協調。
單體應用架構
單體應用架構概念
一個應用中包含了應用程序的所有功能（比如：頁面，代碼，配置等），把應用打成一個war或jar包部署到Tomcat中，通常稱爲單體應用架構。
單體架構圖
可以看到單體架構就是把所有的東西都揉到一起去了，它的優缺點如下：
優點
- 易於開發&測試：單個應用包含所有功能，不涉及多個應用的互聯互調，便於在團隊之間開發與測試。
- 易於部署：只需將單個應用打成war或jar包，進行部署到Tomcat即可，運維起來比較方便。
- 易於整體擴展：當應用負載壓力大時，將這個應用複製幾份，分別部署在不同的服務器上，再通過負載均衡即可提高應用的併發能力。
缺點
- 複雜性高：由於是單個應用，所以整個項目文件包含的模塊非常多，導致模塊的邊界模糊、依賴關係不清晰、代碼的質量參差不齊，混亂的堆在一起，使得整個項目非常複雜。以致每次修改代碼，都非常小心，可能添加一個簡單的功能，或者修改一個Bug都會帶來隱藏的缺陷。
- 技術債務：隨着時間的推移、需求的變更和技術人員的更替，會逐漸形成應用程序的技術債務，並且越積越多。
- 阻礙技術創新：對於單體應用來說，技術是在開發之前經過慎重評估後選定的，每個團隊成員都必須使用相同的開發語言、持久化存儲及消息系統。
微服務架構
微服務架構概念
開頭已經說明了微服務架構的概念，就是把項目分爲不同的業務模塊，每個模塊都作爲一個單獨的應用來開發，既然是單獨的項目那就可以使用不同的語言，不同的技術，不同的數據存儲系統等等。如果一個業務模塊需要另一個業務模塊的功能的話，怎麼辦呢？採用輕量級RESTful API通信進行交互即可。然後採用一個集中式管理工具來管理這些個獨立模塊的應用，這些獨立的模塊就稱之爲微服務。springcloud就是提供了一站式管理技術的管理工具。至於如何管理的，之後會有說明。
微服務架構圖
通過這張圖可以說明微服務的擴展優勢。
優點
- 易於開發和維護：一個微服務只會關注一個特定的業務功能，所以業務清晰、代碼量較少。開發和維護單個微服務相對簡單。
- 單個微服務啓動較快
- 局部修改容易部署：單一應用只要有修改，就得重新部署整個應用。微服務解決了這樣的問題。一般來說，對某個微服務進行修改，只需要重新部署這個服務即可。
- 技術棧不受限制：在微服務架構中，可以結合項目業務及團隊的特點，合理的選擇技術棧。
- 按需伸縮：可根據需求，實現細粒度的擴展。
缺點
- 運維要求高：更多的服務意味着要投入更多的運維。
- 分佈式固有的複雜性：使用微服務構建的是分佈式系統。對於一個分佈式系統，系統容錯、網絡延遲、分佈式事務等都會帶來巨大的問題。
- 接口調整成本高：微服務之間通過接口進行通信。如果修改某一個微服務的API，可能所有用到這個接口的微服務都需要進行調整。
微服務架構總結：
- 微服務的核心就是將傳統的單一應用，根據業務拆分成一個一個的服務，徹底地去耦合,每一個微服務提供單個業務功能的服務，一個服務做一件事。
- 在 IDEA 工具中使用Maven構建的一個個獨立的 Module ，也就是使用Spring Boot 開發的一個個小模塊就是一個個微服務，將專業的事交給專業的模塊來做。比如一個大型項目可能有上百個微服務，將這些微服務集中起來構成一個大的系統，對外暴露服務進行調用與使用。
- 從技術角度看就是一種小而獨立的處理過程，類似進程概念，能夠自行單獨啓動或銷燬，擁有自己獨立的數據庫。
微服務架構技術棧
|
微服務技術維度
|
技術實現
|
|
服務開發
|
Spring Boot
、
Spring
、
Spring MVC
等
|
|
服務註冊與發現
|
Eureka
、
Zookeeper
等
|
|
服務調用
|
Rest
、
RPC
等
|
|
服務熔斷器
|
Hystrix
、
Envoy
等
|
|
負載均衡
|
Ribbon
、
Nginx
等
|
|
服務接口調用
(
客戶端調用服務的簡化工具
)
|
Feign
等
|
|
消息隊列
|
Kafka
、
ActiveMQ
等
|
|
服務配置中心管理
|
Spring Cloud Confifig
等
|
|
服務路由（
API
網關）
|
Zuul
等
|
|
服務監控
|
Zabbix
、
Nagios
等
|
|
全鏈路追蹤
|
Zipkin
，
Brave
等
|
|
服務部署
|
Docker
、
OpenStack
等
|
|
數據流處理
|
Spring Cloud Stream
（
Redis,Rabbit,Kafka
等發送接收消息）
|
|
事件消息總線
|
Spring Cloud Bus
|
以上列出了部分技術棧，更多信息請看官網，有同學說我看英文很難受，嘻嘻，來這裏，springcloud中文網
以上的技術棧，後續我在學習的過程中會一一介紹的。
什麼是 Spring Cloud
所以，Spring Cloud，基於 Spring Boot 提供了一套微服務解決方案，包括服務註冊與發現，配置中心，全鏈路監控，服務網關，負載均衡，熔斷器等組件。NetFlix是美國的一家網絡影音公司，差不多就像騰訊視頻，愛奇藝這樣的，他們有一些很牛X的分佈式開源組件，spring對他們的開源組件進行了進一步的封裝，又集合了其他的優秀的開源組件，就變成了現在的這個微服務架構管理工具。
來張圖：
上圖包含了技術棧中的部分內容，先簡單解釋一下：
Zuul 路由網關：網關大家都瞭解，通過一個子網的信息都走網關，這裏如果我們爲微服務架構配置一個網關，那麼訪問整個系統所有的微服務的請求，都要先經手網關，然後再轉發給各個微服務，有什麼用呢？那就要問一問朋友們，攔截器有什麼用呢？Zuul就是整個系統的一個攔截器，在這裏搞一個權限控制，每個微服務都攔的到，它不香嗎？
Eureka 服務註冊中心:這個是啥呢？大家思考這麼個問題，我們搞了很多個微服務，微服務之間要通信吧？要相互之間用對方的功能。不通信搞什麼微服務對不對？那通信要不要對方地址？怎麼找對方地址？曾記得很久很久以前，也許是民國時代，那時候打電話還不能直接打給對方，要打到一箇中轉站，然後告訴人家，我要找陳冠希，人家就幫你轉給了陳冠希，這樣你跟陳冠希就能友好的交流。那它爲什麼可以轉呢？明顯這個轉發中心有所有人的聯繫方式，當來一個電話說我要找誰誰誰，就給你轉過去。服務註冊中心是個啥？就是一個記錄各個微服務地址的一個集中站。每個微服務把自己信息註冊到註冊中心，然後，A微服務想要訪問B微服務就去註冊中心找B註冊的信息，從而就知道B在哪裏了。至於這麼做的好處，我們在學習Eureka那一章節再討論。
Hystrix 熔斷器：微服務之間會相互調用，這個調用不單單是兩級或者一對一，也許會出現A調用B，B調用C，C還調用了D，E，F等等。假如此時D掛掉了，咋辦？C得等着，C等着B就得等着，B等着A就得等着。這時候又來一個Q調用B，Q也得等着，巴拉巴拉。於是出現了掛了一個D，慢慢整個系統都掛掉了。這就是微服務調用可能產生的雪崩效應。熔斷器是啥？家裏電路短路時，電流過大會燒壞保險絲，保證不會因此造成更多的危險。這叫及時止損。熔斷器就是這樣，D掛掉了，訪問D的微服務等不到D的迴應，就假裝D有問題了，然後就不等了，直接返回一個預設好的熔斷信息。及時止損。這裏說的是客戶端熔斷，還有服務端熔斷，之後討論。
Spring Cloud Confifig配置中心：這個概念簡單，就是把配置文件集中管理不寫在本地了，應用啓動時去配置中心拿配置信息。目的是爲了配置文件的管理。
服務跟蹤：這是一個追蹤微服務的日誌收集工具包。
SpringBoot和SpringCloud的關係
- Spring Boot 可以離開 Spring Cloud 單獨使用開發項目，但是Spring Cloud離不開SpringBoot，屬於依賴的關係.
- Spring Boot 專注於快速方便的開發單個個體微服務，Spring Cloud 關注全局的服務治理框架。
- Spring Cloud 是關注全局的微服務協調整理治理框架，它將 Spring Boot 開發的一個個單體微服務整合並管理起來，爲各個微服務之間提供，配置管理、服務發現、斷路器、路由、微代理、事件總線、全局鎖、決策競選、分佈式會話等等集成服務。