更新時間:2020-03-19 來源:傳智播客 瀏覽量:
1、微服務架構
目前微服務是非?;鸬募軜嫽蛘哒f概念,也是在構建大型互聯網項目時采用的架構方式。
1.1 單體架構
在軟件設計中,經常提及和使用經典的3層模型,即表示層、業(yè)務邏輯層和數據訪問層。
·表示層:用于直接和用戶交互,也稱為交互層,通常是網頁、UI 等。
·業(yè)務邏輯層:即業(yè)務邏輯處理層,例如用戶輸入的信息要經過業(yè)務邏輯層的處理后,才能展現給用戶。
·數據訪問層:用于操作數據庫,用戶在表示層會產生大量的數據,通過數據訪問層對數據庫進行讀寫操作。
雖然在軟件設計中劃分了經典的3層模型,但是對業(yè)務場景沒有劃分。一個典型的單體應用就是將所有的業(yè)務場景的表示層、業(yè)務邏輯層和數據訪問層放在一個工程中,最終經過編譯、打包,部署在一臺服務器上。
單體架構圖如下所示:
1.1.1 單體架構的優(yōu)點·部署簡單由于是完整的結構體,可以直接部署在一個服務器上即可。
·技術單一 項目不需要復雜的技術棧,往往一套熟悉的技術棧就可以完成開發(fā)。
·用人成本低 單個程序員可以完成業(yè)務接口到數據庫的整個流程。
1.1.2 單體架構的缺點
·系統(tǒng)啟動慢 , 一個進程包含了所有的業(yè)務邏輯,涉及到的啟動模塊過多,導致系統(tǒng)的啟動、重啟時間周期過長
·系統(tǒng)錯誤隔離性差、可用性差,任何一個模塊的錯誤均可能造成整個系統(tǒng)的宕機·可伸縮性差;系統(tǒng)的擴容只能只對這個應用進行擴容,不能做到對某個功能點進行擴容
·線上問題修復周期長;任何一個線上問題修復需要對整個應用系統(tǒng)進行全面升級
1.2 微服務架構
就目前來看微服務并沒有一個 嚴格 的定義 每一個人對 微服務 的理解都是不一樣的 . Martin Fowler在它的博客中是這樣表述微服務的
博客地址 : https://martinfowler.com/articles/microservices.html
微服務架構風格是一種將一個單一應用程序開發(fā)為一組小型服務的方法每一個服務運行在自己的進程中服務間通信采用的輕量級通信機制通(常用HTTP 資源 API ). 這些服務圍繞業(yè)務能力構建并且可通過全自動部署機制獨立部署這些服務公用一個最小型的集中式的管理服務可用不同的語言開發(fā),使用不同的數據存儲技術。
微服務架構架構如如下圖所示下圖所示:
·易于開發(fā)和維護:一個微服務只會關注一個特定的業(yè)務功能,所以它業(yè)務清晰、代碼量少。開發(fā)和維護單個微服務相當簡單。而整個應用是若干個微服務構建而成的,所以整個應用也被維持在一個可控狀態(tài)。
·單個微服務啟動較快 單個微服務代碼量較少,所以啟動會比較快。
·局部修改容易部署:單個應用只要有修改,就得重新部署整個應用,微服務解決了這樣的問題。一般來說,對某個微服務進行修改,只需要重新部署這個服務即可。
·技術棧不受限:在微服務架構中,可以結合項目業(yè)務及團隊的特點,合理選擇技術棧。例如某些服務可以使用關系型數據庫Mysql有些服務??梢允褂梅顷P系型數據庫如redis;甚至可根據需求,部分微服務使用Java開發(fā),部分微服務使用Node.js開發(fā)。
·按需收縮可根據需求,實現細粒度的擴展。例如,系統(tǒng)中的某個微服務遇到了瓶頸,可以結合這個微服務的業(yè)務特點,增加內存、升級CPU或者增加節(jié)點。
1.2.2 微服務的缺點
·運維要求較高: 更多的服務意味著更多的運維投入。在單體架構中,只需要保證一個應用的正常運行。而在微服務中,需要保證幾十甚至幾百個服務正常運行與協作,這給運維帶來了很大的挑戰(zhàn)。
·分布式固有的復雜性:使用微服務構建的是分布式 系統(tǒng)。對于一個分布式系統(tǒng),系統(tǒng)容錯、網絡延遲等都會帶來巨大的挑戰(zhàn)。
·接口調整成本高:微服務之間通過接口進行通信。如果修改某一個微服務 API ,可能所有使用該接口的微服務都需要調整。
2、Spring Cloud 簡介
2.1 簡介
Spring Cloud項目的官方網址: https://projects.spring.io/spring-cloud/
Spring Cloud并不是一個項目而是一組項目的集合在Spring Cloud中包含了很多的子項目每一個子項目都是一種微服務開發(fā)過程中遇到的問題的一種解決方案它利用Spring Boot的開發(fā)便利性巧妙地簡化了分布式系統(tǒng)基礎設施的開發(fā),如服務發(fā)現注冊、配置中心、消息總線、負載均衡、斷路器、數據監(jiān)控等,都可以用Spring Boot的開發(fā)風格做到一鍵啟動和部署。Spring Cloud并沒有重復制造輪子,它只是將目前各家公司開發(fā)的比較成熟、經得起實際考驗的服務框架組合起來,通過Spring Boot風格進行再封裝屏蔽掉了復雜的配置和實現原理,最終給開發(fā)者留出了一套簡單易懂、易部署和易維護的分布式系統(tǒng)開發(fā)工具包。
2.2 子項目介紹
當我們通過搜索引擎查找一些Spring Cloud 的文章或者示例的時候往往可以在依賴中看到很多不同版本的名字 , 比如 : Angel.SR6, Brixton.SR5等。 那么,為什么 Spring Cloud 沒有像其他的 Spring 的項目使用類似1.x.x 版本命名規(guī)則呢?
由于Spring Cloud不像Spring社區(qū)其他項目那樣相對獨立,它是擁有諸多子項目的大型綜合項目??梢哉f是對微服務架構解決方案的綜合套件的組合,起包含的各個子項目也都是進行獨立的更新和迭代,各自都維護自己的發(fā)布版本號。因此,每一個Spring Cloud的版本都會包含多個不同版本的子項目,為了管理每一個版本的子項目清單避免Spring Cloud的版本號與其子項目的版本號相混淆,沒有采用版本號的方式,而是通過命名的方式。
我們也可以在spring的官網上查看到對應的最新穩(wěn)定版本信息 : https://projects.spring.io/spring-cloud/
并且也可以看到最新Edgware.SR4穩(wěn)定版對應的子項目的各個版本號。關于Spring Cloud的歷史版本信息我們可以在github上查看到 : https://github.com/spring-cloud/spring-cloud/release/releases我們本次講解的是最新的穩(wěn)定版本Edgware.SR4 ,是基于Spring Boot 1.5.14.RELEASE版本實現的。
3、Spring Boot 實現微服務
業(yè)務非常簡單:
1、商品微服務:通過商品id 查詢商品的服務;2、訂單微服務:通過訂單id 查詢訂單數據,同時需要調用商品微服務查詢出訂單詳情數據對應的商品數據。
3.1 實現商品微服務
3.1.1 pom .xml文件的配置
3.1.3 編寫ItemService
3.1.4 編寫ItemController
3.1.5 程序入口
3.1.6 創(chuàng)建配置文件
指定服務啟動占用的端口
3.1.7 啟動項目進行訪問
3.2 實現訂單微服務
3.2.1 pom.xml文件的配置
3.2.3 創(chuàng)建實體OrderDetail
3.2.4 復制Item實體
3.2.6 實現ItemService
3.2.8 編寫OrderController
3.2.10 創(chuàng)建配置文件
在src/main/resources 目錄下創(chuàng)建一個application.properties 配置文件在該文件中可以配置如下內容
server.port=8082
3.2.11 啟動測試
3.3 發(fā)現問題與解決問題
3.3.1 問題描述
·在剛才的服務調用過程中我們的商品服務地址是直接寫死在程序中存在硬編碼問題
·如果商品微服務部署了多個,那么我們訂單微服務如何去調用呢?
3.3.2 問題處理
關于硬編碼的問題我們可以使用配置文件處理,我們可以將地址信息編寫到配置文件中然后讀取配置文件獲取請求地址信息。
在配置文件中加入如下配置:itcast.item.url=http://127.0.0.1:8081/item/修改ItemService的實現通過@Value 注解獲取該值2. 如果商品微服務部署了多個那么我們訂單微服務如何去調用呢?關于這個問題有的開發(fā)人員可能會想 . 我們可以將多個商品微服務的地址配置到配置文件中,然后在進行讀取配置文件的地址進行調用聽起來好像可以,但是我們需要考慮以后問題就是后期維護的問題。
·如果商品微服務的我們又添加或者減少了一個部署,相應的我們需要去更改配置文件的內容;
·如果商品微服務的ip地址發(fā)送了改變,那么我們也需要相應的修改配置文件的地址。
所以我們自己這樣實現比較麻煩。
我們可以使用服務注冊于發(fā)現機制來完成。
由上圖可以看出:
1、服務提供者將服務注冊到注冊中心
2、服務消費者通過注冊中心查找服務
3、查找到服務后進行調用(這里就是無需硬編碼 url 的解決方案)
4.1 注冊中心 Eureka
Spring Cloud提供了多種注冊中心的支持,如: Eureka 、 ZooKeeper 等。推薦使用Eureka 。
Spring Cloud Eureka是Spring Cloud Netflix 微服務套件中的一部分,它基于Netflix Eureka做了二次封裝。主要負責完成微服務架構中的服務治理功能。
原理如下圖所示
Eureka包含兩個組件: Eureka Server 和 Eureka Client 。
Eureka Server 提供服務注冊服務,各個節(jié)點啟動后,會在 Eureka Server中進行注冊,這樣 EurekaServer中的服務注冊表中將會存儲所有可用服務節(jié)點的信息,服務節(jié)點的信息可以在界面中直觀的看到。
Eureka Client是一個java 客戶端,用于簡化與 Eureka Server的交互在應用啟動后,將會向Eureka Server發(fā)送心跳默認周期為 30 秒,如果 Eureka Server在多個心跳周期內沒有接收到某個節(jié)點的心跳,Eureka Server將會從服務注冊表中把這個服務節(jié)點移除默認 90 秒 。
Eureka Server之間通過復制的方式完成數據的同步,Eureka還提供了客戶端緩存機制,即使所有的Eureka Server都掛掉,客戶端依然可以利用緩存中的信息消費其他服務的 API 。綜上,Eureka通過心跳檢查、客戶端緩存等機制,確保了系統(tǒng)的高可用性、靈活性和可伸縮性。
啟動類
4.2.3 配置文件
4.2.4 啟動程序訪問服務端
訪問地址 : http://localhost:6868/
4.3 商品微服務注冊到注冊中心
接下來,我們需要將商品的微服務注冊到Eureka服務中。
4.3.1 修改pom文件
引入Spring Cloud的管理依賴以及Eureka服務依賴。
4.3.3 修改啟動類
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.client.discovery.EnableDiscoveryClient;
@EnableDiscoveryClient // 聲明這是 Eureka 的客戶端
@SpringBootApplication // 聲明這是一個 Spring Boot 項目
public class ItemApplication {
public static void main(String[] args) {SpringApplication.run(ItemApplication.class, args);
}}4.5.4 Eureka的高可用
前面的測試,我們會發(fā)現,Eureka服務是一個單點服務,在生產環(huán)境就會出現單點故障,為了確保Eureka服務的高可用,我需要搭建Eureka服務的集群。
搭建Eureka集群非常簡單,只要啟動多個Eureka服務并且讓這些服務之間彼此進行注冊即可實現。
修改itcast microservice eureka的application.properties配置文件
可以看到,2個Eureka服務進行了彼此注冊
4.5.5 將服務注冊到 Eureka集群中