微服務架構(gòu)解決方案介紹[java培訓]

更新時間:2020-03-19 來源:傳智播客瀏覽量:

1、微服務架構(gòu)

目前微服務是非?；鸬募軜?gòu)或者說概念，也是在構(gòu)建大型互聯(lián)網(wǎng)項目時采用的架構(gòu)方式。

1.1 單體架構(gòu)

在軟件設計中，經(jīng)常提及和使用經(jīng)典的3層模型，即表示層、業(yè)務邏輯層和數(shù)據(jù)訪問層。

·表示層：用于直接和用戶交互，也稱為交互層，通常是網(wǎng)頁、UI 等。

·業(yè)務邏輯層：即業(yè)務邏輯處理層，例如用戶輸入的信息要經(jīng)過業(yè)務邏輯層的處理后，才能展現(xiàn)給用戶。

·數(shù)據(jù)訪問層：用于操作數(shù)據(jù)庫，用戶在表示層會產(chǎn)生大量的數(shù)據(jù)，通過數(shù)據(jù)訪問層對數(shù)據(jù)庫進行讀寫操作。

雖然在軟件設計中劃分了經(jīng)典的3層模型，但是對業(yè)務場景沒有劃分。一個典型的單體應用就是將所有的業(yè)務場景的表示層、業(yè)務邏輯層和數(shù)據(jù)訪問層放在一個工程中，最終經(jīng)過編譯、打包，部署在一臺服務器上。

單體架構(gòu)圖如下所示：

Spring-Cloud微服務01

1.1.1 單體架構(gòu)的優(yōu)點

·部署簡單由于是完整的結(jié)構(gòu)體，可以直接部署在一個服務器上即可。

·技術(shù)單一項目不需要復雜的技術(shù)棧，往往一套熟悉的技術(shù)棧就可以完成開發(fā)。

·用人成本低單個程序員可以完成業(yè)務接口到數(shù)據(jù)庫的整個流程。

1.1.2 單體架構(gòu)的缺點

·系統(tǒng)啟動慢 , 一個進程包含了所有的業(yè)務邏輯，涉及到的啟動模塊過多，導致系統(tǒng)的啟動、重啟時間周期過長

·系統(tǒng)錯誤隔離性差、可用性差，任何一個模塊的錯誤均可能造成整個系統(tǒng)的宕機

·可伸縮性差;系統(tǒng)的擴容只能只對這個應用進行擴容，不能做到對某個功能點進行擴容

·線上問題修復周期長;任何一個線上問題修復需要對整個應用系統(tǒng)進行全面升級

1.2 微服務架構(gòu)

就目前來看微服務并沒有一個嚴格的定義每一個人對微服務的理解都是不一樣的 . Martin Fowler在它的博客中是這樣表述微服務的

Spring-Cloud微服務02

博客地址 : https://martinfowler.com/articles/microservices.html

微服務架構(gòu)風格是一種將一個單一應用程序開發(fā)為一組小型服務的方法每一個服務運行在自己的進程中服務間通信采用的輕量級通信機制通（常用HTTP 資源 API ). 這些服務圍繞業(yè)務能力構(gòu)建并且可通過全自動部署機制獨立部署這些服務公用一個最小型的集中式的管理服務可用不同的語言開發(fā)，使用不同的數(shù)據(jù)存儲技術(shù)。

微服務架構(gòu)架構(gòu)如如下圖所示下圖所示:

Spring-Cloud微服務03

1.2.1 微服務微服務的的優(yōu)點優(yōu)點

·易于開發(fā)和維護:一個微服務只會關(guān)注一個特定的業(yè)務功能,所以它業(yè)務清晰、代碼量少。開發(fā)和維護單個微服務相當簡單。而整個應用是若干個微服務構(gòu)建而成的，所以整個應用也被維持在一個可控狀態(tài)。

·單個微服務啟動較快單個微服務代碼量較少，所以啟動會比較快。

·局部修改容易部署：單個應用只要有修改，就得重新部署整個應用，微服務解決了這樣的問題。一般來說，對某個微服務進行修改，只需要重新部署這個服務即可。

·技術(shù)棧不受限：在微服務架構(gòu)中，可以結(jié)合項目業(yè)務及團隊的特點，合理選擇技術(shù)棧。例如某些服務可以使用關(guān)系型數(shù)據(jù)庫Mysql有些服務。可以使用非關(guān)系型數(shù)據(jù)庫如redis;甚至可根據(jù)需求，部分微服務使用Java開發(fā)，部分微服務使用Node.js開發(fā)。

·按需收縮可根據(jù)需求，實現(xiàn)細粒度的擴展。例如，系統(tǒng)中的某個微服務遇到了瓶頸，可以結(jié)合這個微服務的業(yè)務特點，增加內(nèi)存、升級CPU或者增加節(jié)點。

1.2.2 微服務的缺點

·運維要求較高：更多的服務意味著更多的運維投入。在單體架構(gòu)中，只需要保證一個應用的正常運行。而在微服務中，需要保證幾十甚至幾百個服務正常運行與協(xié)作，這給運維帶來了很大的挑戰(zhàn)。

·分布式固有的復雜性：使用微服務構(gòu)建的是分布式系統(tǒng)。對于一個分布式系統(tǒng)，系統(tǒng)容錯、網(wǎng)絡延遲等都會帶來巨大的挑戰(zhàn)。

·接口調(diào)整成本高：微服務之間通過接口進行通信。如果修改某一個微服務 API ，可能所有使用該接口的微服務都需要調(diào)整。

2、Spring Cloud 簡介

2.1 簡介

Spring Cloud項目的官方網(wǎng)址： https://projects.spring.io/spring-cloud/

Spring-Cloud微服務04

Spring Cloud并不是一個項目而是一組項目的集合在Spring Cloud中包含了很多的子項目每一個子項目都是一種微服務開發(fā)過程中遇到的問題的一種解決方案它利用Spring Boot的開發(fā)便利性巧妙地簡化了分布式系統(tǒng)基礎設施的開發(fā)，如服務發(fā)現(xiàn)注冊、配置中心、消息總線、負載均衡、斷路器、數(shù)據(jù)監(jiān)控等，都可以用Spring Boot的開發(fā)風格做到一鍵啟動和部署。Spring Cloud并沒有重復制造輪子，它只是將目前各家公司開發(fā)的比較成熟、經(jīng)得起實際考驗的服務框架組合起來，通過Spring Boot風格進行再封裝屏蔽掉了復雜的配置和實現(xiàn)原理，最終給開發(fā)者留出了一套簡單易懂、易部署和易維護的分布式系統(tǒng)開發(fā)工具包。

2.2 子項目介紹

Spring-Cloud微服務05

2.3 Spring Cloud的版本介紹

當我們通過搜索引擎查找一些Spring Cloud 的文章或者示例的時候往往可以在依賴中看到很多不同版本的名字 , 比如 : Angel.SR6, Brixton.SR5等。那么，為什么 Spring Cloud 沒有像其他的 Spring 的項目使用類似1.x.x 版本命名規(guī)則呢?

由于Spring Cloud不像Spring社區(qū)其他項目那樣相對獨立，它是擁有諸多子項目的大型綜合項目?？梢哉f是對微服務架構(gòu)解決方案的綜合套件的組合，起包含的各個子項目也都是進行獨立的更新和迭代，各自都維護自己的發(fā)布版本號。因此，每一個Spring Cloud的版本都會包含多個不同版本的子項目，為了管理每一個版本的子項目清單避免Spring Cloud的版本號與其子項目的版本號相混淆，沒有采用版本號的方式，而是通過命名的方式。

我們也可以在spring的官網(wǎng)上查看到對應的最新穩(wěn)定版本信息 : https://projects.spring.io/spring-cloud/

Spring-Cloud微服務06

并且也可以看到最新Edgware.SR4穩(wěn)定版對應的子項目的各個版本號。

Spring-Cloud微服務07

關(guān)于Spring Cloud的歷史版本信息我們可以在github上查看到 : https://github.com/spring-cloud/spring-cloud/release/releases

Spring-Cloud微服務08

我們本次講解的是最新的穩(wěn)定版本Edgware.SR4 ,是基于Spring Boot 1.5.14.RELEASE版本實現(xiàn)的。

3、Spring Boot 實現(xiàn)微服務

在正式學習Spring Cloud 之前我們先使用Spring Boot實現(xiàn)一個微服務。

業(yè)務非常簡單：

1、商品微服務：通過商品id 查詢商品的服務；

2、訂單微服務：通過訂單id 查詢訂單數(shù)據(jù)，同時需要調(diào)用商品微服務查詢出訂單詳情數(shù)據(jù)對應的商品數(shù)據(jù)。

Spring-Cloud微服務09

說明：

1、對于商品微服務而言，商品微服務是服務的提供者，訂單微服務是服務的消費者

2、對于訂單微服務而言，訂單微服務是服務的提供者，人是服務的消費者。

3.1 實現(xiàn)商品微服務

3.1.1 pom .xml文件的配置

3.1.2 創(chuàng)建實體Item

3.1.3 編寫ItemService

Spring-Cloud微服務11.1

3.1.4 編寫ItemController

Spring-Cloud微服務11.2

3.1.5 程序入口

Spring-Cloud微服務11.3

3.1.6 創(chuàng)建配置文件

在src/main/resources目錄下創(chuàng)建一個application.properties配置文件在該文件中可以配置如下內(nèi)容

server.port=8081

指定服務啟動占用的端口

3.1.7 啟動項目進行訪問

Spring-Cloud微服務12

3.2 實現(xiàn)訂單微服務

3.2.1 pom.xml文件的配置

Spring-Cloud微服務13

3.2.2 創(chuàng)建實體Order

Spring-Cloud微服務11

3.2.3 創(chuàng)建實體OrderDetail

Spring-Cloud微服務12.1

3.2.4 復制Item實體

Spring-Cloud微服務14

3.2.5 編寫OrderService

該Service實現(xiàn)的根據(jù)訂單Id查詢訂單的服務，為了方便測試，我們將構(gòu)造數(shù)據(jù)實現(xiàn)，不采用查詢數(shù)據(jù)庫的方式。

3.2.6 實現(xiàn)ItemService

3.2.7 完善OrderService

3.2.8 編寫OrderController

3.2.9 編寫啟動類

3.2.10 創(chuàng)建配置文件

在src/main/resources 目錄下創(chuàng)建一個application.properties 配置文件在該文件中可以配置如下內(nèi)容

server.port=8082

3.2.11 啟動測試

Spring-Cloud微服務15

3.3 發(fā)現(xiàn)問題與解決問題

3.3.1 問題描述

·在剛才的服務調(diào)用過程中我們的商品服務地址是直接寫死在程序中存在硬編碼問題

·如果商品微服務部署了多個，那么我們訂單微服務如何去調(diào)用呢？

3.3.2 問題處理

關(guān)于硬編碼的問題我們可以使用配置文件處理，我們可以將地址信息編寫到配置文件中然后讀取配置文件獲取請求地址信息。

在配置文件中加入如下配置：

itcast.item.url=http://127.0.0.1:8081/item/

修改ItemService的實現(xiàn)通過@Value 注解獲取該值

Spring-Cloud微服務13.6

2. 如果商品微服務部署了多個那么我們訂單微服務如何去調(diào)用呢?

關(guān)于這個問題有的開發(fā)人員可能會想 . 我們可以將多個商品微服務的地址配置到配置文件中，然后在進行讀取配置文件的地址進行調(diào)用聽起來好像可以，但是我們需要考慮以后問題就是后期維護的問題。

·如果商品微服務的我們又添加或者減少了一個部署，相應的我們需要去更改配置文件的內(nèi)容;

·如果商品微服務的ip地址發(fā)送了改變，那么我們也需要相應的修改配置文件的地址。

所以我們自己這樣實現(xiàn)比較麻煩。

我們可以使用服務注冊于發(fā)現(xiàn)機制來完成。

4 Spring Cloud快速入門

服務注冊于發(fā)現(xiàn)機制架構(gòu)圖如下：

由上圖可以看出：

1、服務提供者將服務注冊到注冊中心

2、服務消費者通過注冊中心查找服務

3、查找到服務后進行調(diào)用(這里就是無需硬編碼 url 的解決方案)

4.1 注冊中心 Eureka

Spring Cloud提供了多種注冊中心的支持，如： Eureka 、 ZooKeeper 等。推薦使用Eureka 。

Spring Cloud Eureka是Spring Cloud Netflix 微服務套件中的一部分，它基于Netflix Eureka做了二次封裝。主要負責完成微服務架構(gòu)中的服務治理功能。

原理如下圖所示

Spring-Cloud微服務17

Eureka包含兩個組件： Eureka Server 和 Eureka Client 。

Eureka Server 提供服務注冊服務，各個節(jié)點啟動后，會在 Eureka Server中進行注冊，這樣 EurekaServer中的服務注冊表中將會存儲所有可用服務節(jié)點的信息，服務節(jié)點的信息可以在界面中直觀的看到。

Eureka Client是一個java 客戶端，用于簡化與 Eureka Server的交互在應用啟動后，將會向Eureka Server發(fā)送心跳默認周期為 30 秒，如果 Eureka Server在多個心跳周期內(nèi)沒有接收到某個節(jié)點的心跳，Eureka Server將會從服務注冊表中把這個服務節(jié)點移除默認 90 秒。

Eureka Server之間通過復制的方式完成數(shù)據(jù)的同步，Eureka還提供了客戶端緩存機制，即使所有的Eureka Server都掛掉，客戶端依然可以利用緩存中的信息消費其他服務的 API 。綜上，Eureka通過心跳檢查、客戶端緩存等機制，確保了系統(tǒng)的高可用性、靈活性和可伸縮性。

4.2 編寫Eureka Server
4.2.1 pom.xml

Spring-Cloud微服務13.7

啟動類

Spring-Cloud微服務14

4.2.3 配置文件

4.2.4 啟動程序訪問服務端

訪問地址 : http://localhost:6868/

Spring-Cloud微服務18

4.3 商品微服務注冊到注冊中心

接下來，我們需要將商品的微服務注冊到Eureka服務中。

4.3.1 修改pom文件

引入Spring Cloud的管理依賴以及Eureka服務依賴。

Spring-Cloud微服務16

4.3.2 修改配置文件

Spring-Cloud微服務18.1

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.3.4 啟動商品微服務

至此我們就已經(jīng)將商品微服務注冊到Eureka注冊中心了

4.4 訂單系統(tǒng)從Eureka中發(fā)現(xiàn)服務

4.4.1 修改pom.xml

之前我們在訂單系統(tǒng)中是將商品微服務的地址進行了硬編碼，現(xiàn)在，由于已經(jīng)將商品服務注冊到Eureka中，所以，只需要從Eureka中發(fā)現(xiàn)服務即可。引入Spring Cloud 的管理依賴以及Eureka服務依賴。

4.4.2 修改配置文件

4.4.3 修改ItemService

4.4.4 修改啟動

4.4.5 啟動測試

響應的數(shù)據(jù)如下:

可以看到以及獲取到數(shù)據(jù)，但是，我們發(fā)現(xiàn)響應的數(shù)據(jù)變成了xml結(jié)構(gòu)。

4.4.6 解決響應變成xml的問題

由于我們引入了eureka server的依賴，導致破壞了之前SpringMVC默認的配置，從而導致了響應成了xml 。

解決方法：排除eureka server中的xml依賴，如下：

測試

4.5 Eureka詳解

4.5.1 為Eureka添加用戶認證

在前面的示例中，我們可以看到我們需要登錄即可訪問到Eureka服務，這樣其實是不安全的。

接下來，我們?yōu)镋ureka添加用戶認證。

為itcast microservice eureka添加安全認證依賴

在application.properties配置文件中添加如下內(nèi)容

開啟http basic的登錄方式

# security.basic.enable= true

# 配置用戶賬號信息

security.user.name= itcast

security.user.password= itcast123

重啟 Eureka服務端測試

4.5.2 服務注冊和發(fā)現(xiàn)設置賬號

http://USER:PASSWORD@127.0.0.1:6868/eureka/

配置如下:

eureka.client.serviceUrl.defaultZone=http://itcast:itcast123 @127.0.0.1:6868/

4.5.3 Eureka的自我保護模式

大家有的時候在訪問Eureka服務端的時候會出現(xiàn)紅色的提示信息這個就是Eureka的自我保護模式。

默認情況下,如何Eureka Server在一定時間內(nèi)沒有接收到某一個微服務實例的心跳,Eureka Server將會注銷該實例(默認是90秒). 但是這種行為是不安全的, 因為有的時候監(jiān)聽不到客戶端的心跳,有可能是因為網(wǎng)絡故障導致的,而并非是服務本身出現(xiàn)了問題,服務本身是健康的.這么草率的將服務注銷是不安全的。

Eureka通過“自我保護模式”來解決個問題當Eureka Server節(jié)點在短時間內(nèi)丟失過多的客戶端時可能發(fā)生了網(wǎng)絡分區(qū)故障),那么，這個節(jié)點就會進入自我保護模式一旦進入該模式,Eureka Server就會保護服務注冊表紅的信息不在刪除服務注冊表中的數(shù)據(jù)，也就，不會注銷任何的微服務。當網(wǎng)絡故障恢復后該Eureka Server節(jié)點會自動退出自我保護模式。

綜上自我保護模式是一種應對網(wǎng)絡異常的安全保護措施。它的架構(gòu)哲學是寧可同時保留所有的微服務（健康的微服務和不健康的微服務），也不盲目注銷任何健康的微服務，使用自我保護模式,可以讓Eureka集群更加的健壯穩(wěn)定，默認。

Eureka自我保護模式是開啟的，無需處理。如果，需要禁用自我保護模式，只需要在配置文件中添加配置即可：

# 禁用eureka的自我保護模式

eureka.server.enable self preservation=false

但是當我們禁用了自我保護模式以后，在此訪問Eureka Server的時候又出現(xiàn)了一個新的錯誤。