Spring Cloud - 簡介

時間  2021-07-14 標籤 SpringCloud Java java spring

Spring Cloud - 簡介

文章目錄

一、前言

1.1 、微服務出現前的單體應用架構

一個歸檔包（可以是JAR、WAR、EAR或其它歸檔格式）包含所有功能的應用程序，通常稱爲單體應用。
而架構單體應用的方法論，就是單體應用架構。單體應用是將所有功能模塊放在一個單一進程中，並且通過在不同的服務器上面複製這個單體進行擴展。

單體架構圖.png

1.2、單體應用架構的優缺點

  • 優點

    • 便於共享：單個歸檔文件包含所有功能，便於在團隊之間以及不同的部署階段之間共享。
    • 易於測試：單體應用一旦部署，所有的服務或特性就都可以使用了，這簡化了測試過程，因爲沒有額外的依賴，每項測試都可以在部署完成後立刻開始。
    • 易於部署：只需將單個歸檔文件複製到單個目錄下。

  • 缺點

    • 複雜性高：由於是單個歸檔文件，所以整個項目文件包含的模塊非常多，導致模塊的邊界模糊、依賴關係不清晰、代碼的質量參差不齊，混亂的堆在一起，使得整個項目非常複雜。以致每次修改代碼，都非常小心，可能添加一個簡單的功能，或者修改一個Bug都會帶來隱藏的缺陷。
    • 技術債務：隨着時間的推移、需求的變更和技術人員的更替，會逐漸形成應用程序的技術債務，並且越積越多。
    • 擴展能力受限：單體應用只能作爲一個整體進行擴展，無法根據業務模塊的需要進行伸縮。
    • 部署頻率低：隨着代碼的增多，構建和部署的時間也會相應增加。每次功能的變更與迭代，都會導致整個應用需要重新部署，使得部署的影響大，風險高，從而使得單體應用的上線部署頻率下降。
    • 可靠性差：如果其中某個功能出現死循環、OOM等，都會造成整個應用崩潰。
    • 阻礙技術創新：對於單體應用來說，技術是在開發之前經過慎重評估後選定的，每個團隊成員都必須使用相同的開發語言、持久化存儲及消息系統。

1.3、微服務

2014年Martin Fowler（馬丁福勒）提出微服務架構設計理念，全文可見自博客鏈接。其中有個段落：

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

簡單翻譯就是：微服務架構風格是將一個單一應用程序開發爲一組小型服務的方式，每個服務運行在自己的進程中，服務間通訊採用輕量級通訊機制（通常用HTTP資源API），這些服務圍繞業務能力構建並可通過全自動部署機制獨立部署。這些服務共用一個小型的集中式管理，服務可用不同的語言開發，使用不同的數據存儲技術。

微服務簡單架構圖

1.4、微服務優點與缺點

  • 優點
    • 易於開發和維護：一個微服務只會關注一個特定的業務功能，所以業務清晰、代碼量較少。開發和維護單個微服務相對簡單。
    • 單個微服務啓動較快
    • 局部修改容易部署：單體應用只要有修改，就得重新部署整個應用。微服務解決了這樣的問題。一般來說，對某個微服務進行修改，只需要重新部署這個服務即可。
    • 技術棧不受限制：在微服務架構中，可以結合項目業務及團隊的特點，合理的選擇技術棧。
    • 按需伸縮：可根據需求，實現細粒度的擴展。
  • 缺點及挑戰
    • 運維要求高：更多的服務意味着要投入更多的運維。
    • 分佈式固有的複雜性：使用微服務構建的是分佈式系統。對於一個分佈式系統，系統容錯、網絡延遲、分佈式事務等都會帶來巨大的問題。
    • 接口調整成本高：微服務之間通過接口進行通信。如果修改某一個微服務的API，可能所有用到這個接口的微服務都需要進行調整。
    • 重複勞動：很多服務可能都會有使用到相同的功能，而這些功能並沒有達到分解爲一個微服務的程度的時候，需要每個服務都去開發這一功能，從而導致代碼重複。
    • 可測試性的挑戰：在動態環境中，服務間的交互會產生非常微妙的行爲，難以進行可視化及全面的測試。

1.5、微服務設計原則

  • 單一職責原則：指一個單元只應關注整個系統功能中單獨、有界限的一部分。
  • 服務自治原則：每個微服務應具備獨立的業務能力、依賴與運行環境，應該與其他服務高度解耦。
  • 輕量級通信機制：微服務間應該通過輕量級的通信機制進行交互。例如使用REST協議等。
  • 微服務粒度：合理劃分粒度，而不是一味地把服務做小。

1.6、常見的微服務框架

  • SpringCloud（本文主題）
  • Dubbo
  • gRPC
  • …

二、SpringCloud

2.1、版本說明

SpringCloud 是個綜合項目，包含了很多子項目，由於子項目也維護着自己的版本，爲了避免與子項目的版本混淆，SpringCloud採用不同的版本命名方式，按照倫敦地址站字母順序進行發行版本。

詳細可見SpringCloud版本。

Release Train Boot Version
Hoxton 2.2.x
Greenwich 2.1.x
Finchley 2.0.x
Edgware 1.5.x
Dalston 1.5.x

Greenwich builds and works with Spring Boot 2.1.x, and is not expected to work with Spring Boot 1.5.x.

The Dalston release train will reach end-of-life in December 2018. Edgware will follow the end-of-life cycle of Spring Boot 1.5.x. The Dalston and Edgware release trains build on Spring Boot 1.5.x, and are not expected to work with Spring Boot 2.0.x.

The Camden release train was marked end-of-life. The Camden release train builds on Spring Boot 1.4.x, but is also tested with 1.5.x.

The Brixton and Angel release trains were marked end-of-life (EOL) in July 2017. The Brixton release train builds on Spring Boot 1.3.x, but is also tested with 1.4.x. The Angel release train builds on Spring Boot 1.2.x, and is incompatible in some areas with Spring Boot 1.3.x. Brixton builds on Spring Boot 1.3.x and is similarly incompatible with 1.2.x. Some libraries and most apps built on Angel will run fine on Brixton, but changes will be required anywhere that the OAuth2 features from spring-cloud-security 1.0.x are used (they were mostly moved to Spring Boot in 1.3.0).

也可以訪問https://start.spring.io/actuator/info，查看SpringCloud與SpringBoot的版本兼容性。

springcloud與springboot的版本對應關係圖

不過最近 Spring Cloud 的版本貌似修改了版本命名方式，由YYYY.MINOR.MICRO的形式進行命名。詳見Blog。

本文章通篇使用的 Spring Boot 版本爲2.3.0.RELEASE, 而 Spring Cloud 版本爲Hoxton.SR4。

2.2、SpringCloud組成

  • 服務註冊與發現：服務提供方將己方調用地址註冊到服務註冊中心，讓服務調用方能夠方便地找到自己；服務調用方從服務註冊中心找到自己需要調用的服務地址。例如：Eureka、Zookeeper、Consul（官網）、Nacos等。
  • 服務調用：常見的服務調用方式有Ribbon、OpenFeign（前身 Feign）。
  • 負載均衡：服務提供方一般會以多實例的形式提供服務，負載均衡功能能夠讓服務調用方連接到合適的服務節點，並且，服務節點選擇的過程對服務調用方來說是透明的。
  • 服務網關：服務網關是服務調用的唯一入口，可用在該組件中實現用戶鑑權、動態路由、灰度發佈、負載限流等功能。例如：Zuul、Gateway、Kong（官網）、Soul（國產網關Gitee）等。
  • 配置中心：將本地化的配置信息註冊到配置中心，實現服務包在開發、測試、生產環境中的無差別性、方便程序包的遷移。例如除了 SpringCloud 自帶的 Config 配置中心，還有Alibaba的 Nacos 配置中心，以及攜程的 Apollo（Github）等。
  • 集成框架：微服務組件都以職責單一的程序包對外提供服務，集成框架以配置的形式將所有微服務組件集成到統一的界面框架下，讓用戶能夠在統一的界面中使用系統。
  • 鏈路監控：記錄完成一次請求的先後銜接和調用關係，並將這種串行或並行的調用關係展示出來，從而在系統出錯時，能夠方便找到出錯點。例如：Sleuth，Zikpin、Skywalking（官網）、PinPoint（GitHub）等。
  • 支撐平臺：系統微服務化後，各個業務模塊經過拆分變得更加細化，系統的部署、運維、監控等都比單體應用架構更加複雜，則需要將大部分的工作自動化，比如 Docker、Kubernetes 等。
  • 斷路器/熔斷器：微服務間不可避免地發生相互調用，但是沒有一個系統能夠保證自身運行的絕對正確，很可能面臨依賴服務失效的問題，因此在該情況下，斷路器能夠對延遲和失敗提供強大的容錯能力，從而爲服務間調用提供保護和控制。例如常見的 Hystrix ，Sentinel 。
  • 消息組件：服務間的通訊事件（刷新配置）。例如常見的 Stream 和 Bus 、Nacos。
  • 健康檢查：Actuator端點。
  • …

微信公衆號：Java知識集訓

微信公衆號

联系我们 沪ICP备13005482号-10