spring cloud(一):瞭解spring cloud 和微服務

前言

最近一段時間比較空閒,可以抽空去學習一些新知識,看了一本不錯的書-Spring Microservices IN ACTION。中文翻譯《Spring微服務實在》,是學習spring cloud的好工具書,絕對推薦購買。讀完一部分,想寫一些筆記和技術總結,也相當鞏固加強記憶。

什麼是微服務

當一個普通web項目功能越來越多,項目變大了,人員也變多,項目得開發進度越來越慢。

如圖1展示,每當項目要開發一個新的功能時,整個項目都需要重新構建,重新測試和重新部署,這樣要花費不少時間在這裏,才能上線。可見這種傳統項目很笨重,迭代速度慢,跟不上時代步伐了。

如果使用微服務重構這些項目得架構,如圖2所示那樣

可以看出微服務將大型應用分解成幾個,獨立的,鬆耦合的組件。用一句簡單的話概括:分解和分離應用程序的功能,是他們完全彼此獨立。
微服務的主要特點

  • 應用程序邏輯分解爲職責分明的粗細顆組件,組件相互獨立,互相協調提供解決方案

  • 每個組件都有一個小的職責領域,並且完全獨立部署

  • 微服務採用輕量級通信原則,可以是http 或者tcp等。通信方式是支持跨語言、跨平臺的。

構建一個微服務要考慮的主題



下面我們來詳細描述下這些構建要點:

  • 大小適當: 如果確保正確地劃分服務的大小,以避免微服務承擔大多的職責。適當的大小允許快遞更改應用程序,並降低整個應用中斷的總體風險
  • 位置透明: 在實際環境中,多個服務快速啓動和關閉時,如果管理這些服務的物理細節
  • 有彈性: 如果繞過失敗的服務,確保採取“快速失敗”的方法來保護微服務消費者和應用的整體完整性。
  • 可重複: 如果確保提供的每一個新服務實例與生產環境中的所有其他服務實例具有相同的配置和代碼塊
  • 可伸縮: 如果使用異步處理和事件來最小化服務之間的依賴關係,並確保可以優雅地擴展微服務?
    像這些要點都不用愁,spring cloud早已經給我們封裝了一套完成解決方案。

認識Spring Cloud

引用Spring 官方說明

Spring Cloud爲開發人員提供了快速構建分佈式系統中一些常見模式的工具(例如配置管理,服務發現,熔斷器,智能路由,微代理,控制總線,一次性令牌,全局鎖定,領導選舉,分佈式會話,集羣狀態)。分佈式系統的協調導致鍋爐板模式,使用Spring Cloud開發人員可以快速站起來實現這些模式的服務和應用程序。它們適用於任何分佈式環境,包括開發人員自己的筆記本電腦,裸機數據中心或者Cloud Foundry等託管平臺

服務發現

記得以前做負載均衡的時候,當要添加新的機器到集羣中時,需要開發人員修改配置文件,添加新機器ip,重啓服務器,這就是服務發現要做的事。可以想象,當有成百上千個應用會在快速啓動或關閉,單靠人爲是無法管理這些應用的註冊或者註銷,服務發現就是處理這些的。當有應用啓動時,服務發現會讓加入整個集羣中,讓其他應用去消費。如果應該關閉或者故障了,服務發現會監聽到這些情況,將他移出集羣,其他應用也不會消費故障的服務。還可以抽象出部署應用服務器的物理細節(IP或者域名),通過邏輯名稱而不是物理位置調用服務。Spring Cloud服務發現主要實現有Netfix Eureka、Consul和ZooKeeper。

配置管理

分離部署應用的配置文件,進行集中式管理,這樣可以確保無論啓動多少個微服務實例,這些微服務實例始終具有相同的配置。 主要通過Spring Cloud Config實現這些操作,可以與git,svn,本地文件,Consul,Eureka,ZooKeeper等集成管理配置文件。

熔斷器

在家庭用電中,發生短路故障,跳閘開發會斷開短路與整個線路的連接,已達到保護電路的目的。熔斷器就是發生故障時,實現快速失敗,以達到保護整體不受影響。在微服務中,各個應用之間相互調用,有個別應用故障了或者堵塞中,會拖累整體處理速度。當併發很大的時候,處理跟不上,有很多請求會等待處理,積累等待請求越來越多,系統處理速度越來越慢,整個系統都會僵死。就好像雪崩效應,一個小小問題,引發一場災難。

spring cloud其實是spring團隊將開源市場一些優秀的開源項目整合在一起,spring cloud 在這些開源軟件之上提供一層抽象的統一,讓這些開源軟件實現具體的細節。就像Java中jpa 規範一樣,讓不同廠商實現這些規範即可。spring cloud跟spring boot、spring data 不一樣,他不是一個專業領域的框架,而是微服務架構下,從實際開發調試到線上運維,一套完整解決方案。繼承spring 家族開箱即用特性,基本是就是加幾個註解就可以一套微服務搭建出來。

spring cloud config

spring cloud config通知集中式服務來處理應用程序配置管理文件,式這些微服務組件配置文件與部署的環境分離。這些組件啓動統計從config server獲取配置文件,從而保證了無論啓動多少個微服務實例,這些微服務配置始終保存相同的配置。支持本地文件存儲、Git以及Subversion。

Netflix Eureka

服務發現,這個可以隔離每個微服務物理路徑,根據每一個服務名,即可調用服務的業務處理。自動剔除故障的微服務,故障轉移。

Netflix Hystrix

熔斷器,容錯管理工具,旨在通過熔斷機制控制服務和第三方庫的節點,從而對延遲和故障提供更強大的容錯能力。、

spring cloud bus

事件、消息總線,用於在集羣(例如,配置變化事件)中傳播狀態變化,可與Spring Cloud Config聯合實現熱部署。

Netfix Zuul

路由網關,所有的請求必經的大門,相當於負載均衡中nginx,apahce的前端控制器的角色。它可以實現安全校驗,內容過濾,動態路由,流量監控。

Netfix Archaius

配置管理API,包含一系列配置管理API,提供動態類型化屬性、線程安全配置操作、輪詢框架、回調機制等功能。

Spring Cloud Stream

信息處理集成,封裝了與Redis,RabbitMQ、Kafka等發送接收消息。

Spring Cloud Sleuth

日誌收集工具包,將每個請求的唯一跟蹤標識符集成到應用程序的HTTP調用和信息通道之中。這些跟蹤號碼,可以讓開發人員在事務流經不同服務時跟蹤事務,瞭解整一個http請求流程情況。spring cloud sleuth封裝了Dapper和log-based追蹤以及Zipkin和HTrace操作,爲SpringCloud應用實現了一種分佈式追蹤解決方案。

Spring Cloud Security

驗證和授權框架,用戶認證,服務限制。在接收調用每個服務時可以檢查HTTP 調用中提供的令牌,確認用戶的身份以及用戶對該服務的訪問權限。

Spring Cloud Zookeeper

操作Zookeeper的工具包,用於使用zookeeper方式的服務發現和配置管理。

Netfix Ribbon

客戶端負載均衡,支持http reful風格調用服務,也可以跟熔斷器和服務發現配置使用,可以省去服務物理路徑,故障處理,她都會自動幫你實現的。

Feign

基於接口模式的客戶端負載均衡,Ribbon的代替品,只要聲明調用遠程服務的接口,他會自動幫你實現接口,調用更加優雅。

還有很多我就不一一列舉了,有興趣的同學可以去spring cloud 官網 瞭解,英文不好的可以去 spring cloud中文網

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章