思維導圖:
引言:
Spring Cloud學習系列是我對<<Spring Cloud微服務始實戰>>一書的讀書筆記.本片文章則是第一章:基礎知識的歸納總結.
本文主要是通過對比單體服務和微服務的優缺點來說明微服務相關基礎知識.最後會介紹微服務的普遍性的實現Spring Cloud.
一.系統架構
此處的系統架構指的是整個系統的服務架構模式.一般來說,分爲兩種,一種是單體服務,一種是微服務.他們各有什麼優缺點呢?
1.1 單體服務
所謂的系統架構是單體服務是指整個系統都由一個服務所支撐,所有的業務邏輯也都在一個應用中.隨着業務的增加而不停的增加業務模塊.這樣做有以下優缺點:
- 優點:前期業務邏輯和應用較小時,開發,測試,運維都比較方便和容易.
- 缺點:隨着業務的不斷增加,應用組件龐大起來.此時修改一個微小的功能,卻需要將整個應用重新部署,影響其他業務模塊的使用.
所以,爲了解決上述缺點,就逐漸開始使用微服務了.
1.2 微服務
微服務是指將一個原本獨立的系統拆分成多個小型服務,這些小型服務都在各自獨立的進程中運行,服務之間通過RESTful API進行通信協作.由於有了輕量級的通信協作基礎,所以,這些微服務可以使用不同的語言實現.當然,微服務也擁有其自身的優缺點:
- 優點:與單體服務的缺點相對應,微服務可以在某一個業務上進行快速的開發,測試和部署.因爲一個微服務只對應一個業務模塊,所以體積小,易改動.
- 缺點:由於一整個服務被拆分成了需要通信協作的多個微服務,也會產生一些新的問題.比如如何對多個微服務進行運維.各個微服務之間的接口一致性問題,分佈式環境的相關問題.
Martin Fowler 在 Microservices一文中提煉出了微服務的如下幾種特性,用於指導大家進行設計:
- 服務組件化:組件是可以獨立更換和升級的單元.一個微服務的更替不影響其他微服務.
- 團隊業務化:根據業務劃分微服務並以此對團隊進行組織.
- 做產品的態度:某一業務的微服務小團隊需要對其產品的整個生命週期負責,而不是以開發和交付爲目標
- 只能端點與啞管道:若將 微服務之間的通信改爲RPC方式調用,會產生繁瑣的通信,所以需要更粗粒度的通訊協議
- 去中心化治理:各個不同的微服務可以選用不同的技術平臺,而不必有某種原生的短板出現
- 去中心化數據管理:每個微服務獨自管理其自有的數據庫.
- 基礎設施自動化:隨着業務的增加而微服務不斷增加,運維和測試的難度隨之增加.所以需要自動化測試和運維.
- 容錯設計:微服務之間的調用可能出現不可控的錯誤,所以需要快速檢測故障源並儘可能自動恢復服務
- 演進式設計:系統初期體量不大時可以使用單體服務,業務不同增加後可以轉化爲微服務.
二.Spring Cloud
根據上述對微服務的描述可知,要使用微服務,我們就必須解決服務治理,分佈式配置管理,服務跟蹤,負載均衡等一系列的問題,一個問題可以使用某一個特殊的插件解決.最後,我們將使用大量的功能插件來實現微服務.Spring Cloud則是一個微服務架構的綜合性解決框架,它整合了諸多被廣泛實踐和證明過的框架作爲實施的基礎部件,又在該基礎上創建了一些非常優秀的邊緣組件.如:
- Spring Cloud Config:配置管理工具
- Spring Cloud Netflix:核心組件,對多個Netflix OSS開源套件進行整合,如Eureke,Hystrix,Ribbon等.
- Spring Cloud Bus:事件,消息總線
Spirng Cloud的功能組件還有很多,此處不一一列舉.
