微服務架構之Spring Cloud Eureka簡單理解與實戰(一)

微服務架構之Spring Cloud Eureka簡單理解與實戰(一)
1 Star2 Stars3 Stars4 Stars5 Stars 給文章打分!
Loading...

微服務架構之Spring Cloud Eureka簡單理解

微服務並沒有一個官方的解釋,但是主要就是為了解決單體架構專案(圖1)的一些弊端,以往我們開發java web工程,基本上都是採用的ssh框架或者ssm框架,開發工作完畢後,測試打成war包放在tomcat下執行。這樣的弊端很多,比如說常見的電商專案,隨著業務的擴大,專案模組越來越多,程式碼量幾十萬行甚至百萬行,維護起來特別不方便,所以發版的間隔也是很長的,甚至一個模組的改動,要測試整個專案工程,同時也不利於技術的改革,例如想把ssh框架改成ssm框架,這裡的工作量是非常大的,所以微服務應運而生。究竟什麼是微服務(圖2)?結合一張圖說明一下

圖1:

圖2:

將原先的每一個模組都做成微服務,每一個微服務模組對應他們相應的資料庫,甚至可以將其獨立扔到tomcat下執行。各個微服務模組通過rest api進行通訊,通常是指http協議或者https協議。每一個微服務模組都有獨立的程序。

這樣就解決了單體架構的弊端,維護性更強,擴充套件性強,避免了技術債務的疊加,各模組也可按需配置伺服器規格。

這裡來說明一點,通常我們微服務之間的呼叫是通過rest api進行的,spring提供了一種介面,RestTemplate(圖3)

圖3:

消費者通過restTemplate介面,傳入生產者微服務所需要的引數和目標url,即可呼叫生產者微服務。但是這裡有一個問題,就是說,targetURL在消費者當中肯定不止呼叫一次,甚至有可能不會只呼叫一個。不止一次就是說我們不能用硬編碼的方式,直接把請求的url地址寫在restTemplate的方法裡面,這可以通過建立配置檔案的方式進行解決,例如可以在springboot的配置檔案xxxxx.yml檔案中配置(圖4)。然後在controller中定義一個成員變數,使其對映到配置中的url值(圖5、6).

圖4:

圖5:

圖6:

不止請求一次的問題解決了,那麼也可能不止請求一個url,也就是說,作為消費者的微服務需要呼叫多個生產者微服務(圖7),此時上面的解決方案就變得束手無策.

圖7:

圖7中就是一種情況,使用者模組有多臺伺服器例項來提供高可用服務或者負載均衡服務,每一個伺服器例項都是單獨的url地址,那麼怎麼辦呢。解決的方案是使用nignx路由(圖8)。

圖8:

但是,這樣看起來確實可以解決上述問題,但是實際專案中可以龐大到有很多個模組,每個模組又可能部署在不同的伺服器上,如果每一個模組都用nginx路由,是非常麻煩的一件事情。正是這樣,Eureka誕生了,我們把微服務注射到Eureka中(圖9)。

圖9:

上圖中,服務啟動的時候,會把服務的ip和埠注射到服務發現組(Eureka)裡面去,具體的是放到一張登錄檔中,當服務消費者呼叫服務叢集的時候,先進行的是從服務發現元件中獲取服務提供者列表,並快取到本地,之後通過負載均衡的相關演算法,從快取表中選一個來用。需要注意的是,該架構是一個動態的,服務提供者叢集每隔一段時間就會向服務發現元件續約自己的列表,如果哪一臺伺服器沒有即是續約,那服務發現元件就會將其在提供者列表中剔除掉,同時,服務消費者也是每間隔一段時間向發現元件傳送心跳,來不斷更新自己快取的提供者列表,這樣就避免了消費者因提供者宕機而請求不到的情況。

接下來重點介紹一下Eureka,這是Eureka的github地址:https://github.com/Netflix/eureka/wiki/Eureka-at-a-glance

結合其中一張結構圖來看一下,eureka被定義成高水平的架構(圖10)。

圖9:

服務發現元件,也可以說是服務註冊中心,它是Eureka Server,作為微服務的橋樑,儲存和管理微服務列表的。應用的生產者和消費者都屬於Eureka Client,他們可以和Eureka Server進行通訊,向其獲取或註冊相關的資訊。而兩個Eureka Client之間呼叫(make remote call)的過程就是通過Eureka Server完成的。

具體的實戰操作,會出現在《微服務架構之Spring Cloud Eureka簡單理解(二)》。

相關文章

程式語言 最新文章