如何理解Spring Cloud和Docker的微服務(wù)架構(gòu)

如何理解Spring Cloud和Docker的微服務(wù)架構(gòu)，針對這個問題，這篇文章詳細(xì)介紹了相對應(yīng)的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

　　Spring Cloud和Docker的微服務(wù)架構(gòu)

　　功能服務(wù)

　　整體應(yīng)用被分解成三個核心的微服務(wù)。這些微服務(wù)是圍繞某些業(yè)務(wù)功能進(jìn)行組織，可獨立部署的應(yīng)用程序。

服務(wù)間關(guān)系

　　Account Service(賬戶服務(wù))

　　包含用戶的輸入邏輯和驗證：收入/支出，儲蓄和賬戶設(shè)置。

　　Statistics Service(統(tǒng)計服務(wù))

　　對主要統(tǒng)計參數(shù)執(zhí)行計算，并獲取每個帳戶的時間線。數(shù)據(jù)點包含標(biāo)準(zhǔn)化為基本貨幣和時間段的值。這些數(shù)據(jù)可用于追蹤賬戶一生中的現(xiàn)金流動態(tài)

　　Notification Service(通知服務(wù))

　　保存用戶聯(lián)系信息和消息設(shè)置(比如提醒和備份頻率)，定時器從其他服務(wù)器上收集所需的信息并通過 emial 發(fā)送給訂閱者。

　　注意

　　·每個微服務(wù)都有自己的數(shù)據(jù)庫，不能繞過微服務(wù)提供的 API 直接訪問微服務(wù)的持久化數(shù)據(jù)。

　　·這個例子中我采用 mongoDB 作為每個微服務(wù)的數(shù)據(jù)庫，用戶可以根據(jù)微服務(wù)的類型選擇合適的數(shù)據(jù)庫。

　　·微服務(wù)和微服務(wù)間的采用同步的 REST API 進(jìn)行通信，通常的做法是采用交互風(fēng)格進(jìn)行通信，比如：通過同步的 GET 請求來檢索數(shù)據(jù)，通過Message Broker使用異步方法來創(chuàng)建/更新操作，以便分離服務(wù)和緩沖區(qū)消息，目標(biāo)是實現(xiàn)最終一致性。

　　Infrastructure Services(基礎(chǔ)設(shè)施服務(wù))

　　分布式系統(tǒng)中有許多共同的模式，可以幫助我們描述核心服務(wù)。spring cloud提供了強(qiáng)大的工具以幫助 spring boot 應(yīng)用實現(xiàn)這些模式，下面會做一些簡單的介紹：

系統(tǒng)架構(gòu)

　　Config Service(配置服務(wù))

　　spring cloud config 是分布式系統(tǒng)中的集中式配置服務(wù)。

　　在這個項目中，我使用 native profile 從本地的 classpath 上加載配置文件，你可以在 shared 目錄下面查看 config service resources。比如：當(dāng)Notification-service請求它的配置信息，配置服務(wù)會返回如下來兩個文件：shared/notification-service.yml 和 shared/application.yml(這個文件會被所有的應(yīng)用共享).

　　Client-side Usage(客戶端使用)

　　只要用spring-cloud-starter-config依賴構(gòu)建Spring Boot應(yīng)用程序，其余部分將自動配置

　　應(yīng)用中不需要其他任何內(nèi)置的properties，只需要提供一個bootstrap.yml文件，這個文件中需要包含當(dāng)前應(yīng)用的名字和Config service 的url

　　spring:

　　  application:

　　    name: notification-service

　　  cloud:

　　    config:

　　      uri: http://config:8888

　　      fail-fast: true

　　spring cloud config支持動態(tài)修改 App 的配置信息，比如： 在EmailService bean上添加@RefreshScope注解，這就意味著你可以修改 email 的正文和標(biāo)題而不用重新編譯或者重啟Notification service。具體操作如下：

　　1、修改config server 上相關(guān)的屬性

　　2、對Notification service執(zhí)行刷新請求：

　　curl -H "Authorization: Bearer #token#" -XPOST http://127.0.0.1:8000/notifications/refresh

　　也可以采用webhooks自動執(zhí)行這個流程

　　注意

　　1、動態(tài)刷新有如下限制：@RefreshScope 注解無法在@Configuration 類和 @Scheduled 方法上生效。

　　2、fail-fast屬性意味著如果服務(wù)無法連接上 config service，則服務(wù)會在啟動期間立即失敗。這在一起啟動所有服務(wù)的時候十分有用。

　　Auth Service(鑒權(quán)服務(wù))

　　授權(quán)職責(zé)完全提取到單獨的服務(wù)器，后者為后端資源服務(wù)授予OAuth3令牌。 身份驗證服務(wù)器用于用戶授權(quán)以及在外圍進(jìn)行安全的機(jī)器對機(jī)器通信。

　　在這個項目中，我使用密碼憑證作為用戶授權(quán)的授權(quán)類型(因為它只被本機(jī)應(yīng)用程序UI使用)，而客戶端憑證作為微服務(wù)授權(quán)的授權(quán)類型。

　　Spring Cloud Security提供了便利的注釋和自動配置，使得從服務(wù)器和客戶端都可以輕松實現(xiàn)。 您可以在文檔中了解更多信息，并查看Auth Server代碼中的配置詳細(xì)信息。

　　客戶端與傳統(tǒng)的基于 session 的權(quán)限驗證類似，你可以從 request 中獲取Principal對象信息，校驗用戶的角色，使用@PreAuthorize注解進(jìn)行基于正則的訪問控制。

　　每個 client (account-service, statistics-service, notification-service 和 browser)都有一個 scope屬性: server ：后臺服務(wù), ui: 瀏覽器，通過scope 能防止 controller 被外部訪問：

　　@PreAuthorize("#oauth3.hasScope('server')")

　　@RequestMapping(value = "accounts/{name}", method = RequestMethod.GET)

　　public List getStatisticsByAccountName(@PathVariable String name) {

　　    return statisticsService.findByAccountName(name);

　　}

　　API Gateway

　　在這個例子中，存在三個核心服務(wù)，將外部API 暴露給客戶端，但是在現(xiàn)實世界中，隨著系統(tǒng)復(fù)雜度的增加，核心服務(wù)數(shù)也會急劇增長?？赡艽嬖谝粋€復(fù)雜頁面，渲染這個頁面需要調(diào)用上百個服務(wù)。

　　理論上，客戶端應(yīng)該直接請求每一個微服務(wù)，但是這種方式存在很多挑戰(zhàn)和局限性，比如：客戶端需要了解所有微服務(wù)的地址，為每一個信息獨立地執(zhí)行 http 調(diào)用，然后在客戶端 merger 這些信息。Another problem is non-web-friendly protocols, which might be used on the backend.

　　通常一個更好的實現(xiàn)方式是使用 API Gateway，它是一個進(jìn)入系統(tǒng)的單入口，目的是將請求路由到合適的后臺服務(wù)或者調(diào)用多個后臺服務(wù)并將結(jié)果聚合返回給客戶端。API Gateway也會被用來做權(quán)限驗證，監(jiān)控，壓力測試，服務(wù)遷移，靜態(tài)響應(yīng)處理和主動流量管理

　　在 Spring cloud 項目中可以通過@EnableZuulProxyannotation注解使用Netflix開源的項目edge service，

　　在這個例子中我們使用Zuul存儲靜態(tài)內(nèi)容(UI application)，路由請求到合適的微服務(wù)上，下面是Notification service的路由配置：

　　zuul:

　　    routes:

　　        notification-service:

　　            path: /notifications/**

　　            serviceId: notification-service

　　            stripPrefix: false

　　這個配置意味著所有以 /notifications開頭的請求都會被路由到Notification service，Notification service 地址并沒有硬編碼，Zuul使用服務(wù)發(fā)現(xiàn)機(jī)制定位Notification service 實例并實現(xiàn)訪問的負(fù)載均衡。

　　Service Discovery(服務(wù)發(fā)現(xiàn))

　　通過服務(wù)發(fā)現(xiàn)能夠自動地確定服務(wù)實例的網(wǎng)絡(luò)位置(由于實例數(shù)擴(kuò)展，實例失敗/更新，會導(dǎo)致服務(wù)實例的網(wǎng)絡(luò)地址發(fā)生變化)

　　服務(wù)發(fā)現(xiàn)的關(guān)鍵部分是服務(wù)注冊，在這個例子中我們使用Netflix Eureka 實現(xiàn)這個功能，Eureka是基于客戶端服務(wù)發(fā)現(xiàn)模式的一個好的例子，客戶端負(fù)責(zé)確定可用服務(wù)實例(使用注冊服務(wù)器)的位置和負(fù)載均衡請求。

　　在Spring Boot中，您可以使用spring-cloud-starter-eureka-server依賴項，通過@EnableEurekaServer注釋和簡單的配置屬性來構(gòu)建Eureka Registry。

　　客戶端支持需要使用@EnableDiscoveryClient注解和添加包含應(yīng)用名稱的bootstrap.yml文件

　　spring:

　　    application:

　　        name: notification-service

　　在應(yīng)用啟動的時候，它會在Eureka Serve中注冊，并提供相關(guān)的meta-data信息(比如：host，port，健康檢查頁，主頁等)。Eureka從微服務(wù)的每個實例接收心跳信息，如果在約定的時間內(nèi)(可配置)沒有接受到心跳信息，這個實例就會被注冊中心移除。

　　Eureka提供了一個簡單的頁面，在這個頁面上你可以查看運行的微服務(wù)以及這些服務(wù)對應(yīng)的實例

Eureka

　　Load Balancer, Circuit Breaker, and Http Client(負(fù)載均衡，斷路器以及 http Client)

　　Netflix OSS 提供了另外一套優(yōu)秀的工具集

　　Ribbon

　　Ribbon是一個客戶端的負(fù)載均衡器，可以通過它控制 HTTP 和 TCP client 請求，與傳統(tǒng)的負(fù)載均衡器相比，每個線上調(diào)用不需要額外的跳躍，你可以直接聯(lián)系所需的服務(wù)。

　　Eureka本身與Spring Cloud 和 Service Discovery集成在一起，開箱即用，Eureka Client提供了一個可用服務(wù)的動態(tài)列表，Ribbon可以通過這個列表來實現(xiàn)負(fù)載均衡。

　　Hystrix

　　Hystrix是熔斷器模式的實現(xiàn)，通過網(wǎng)絡(luò)訪問依賴關(guān)系來控制延遲和失敗。核心思想是在大量微服務(wù)的分布式環(huán)境中停止級聯(lián)失敗，這有助于系統(tǒng)盡快恢復(fù) 。

　　除了提供熔斷器，Hystrix還可以添加一個fallback方法，在主命令失敗的情況下返回默認(rèn)值。

　　而且，Hystrix為每個命令生成執(zhí)行結(jié)果和延遲的度量標(biāo)準(zhǔn)，我們可以用它來監(jiān)視系統(tǒng)行為。

　　Feign

　　Feign是一個聲明式HTTP客戶端，與Ribbon和Hystrix無縫集成。 實際上，通過一個Spring-Cloud-Starter-Feign依賴和@EnableFeignClients批注，您可以擁有一整套負(fù)載均衡器，斷路器和HTTP客戶端，并具有合理的隨時可用的默認(rèn)配置。

　　下面是Account Service的一個列子：

　　@FeignClient(name = "statistics-service")

　　public interface StatisticsServiceClient {

　　    @RequestMapping(method = RequestMethod.PUT, value = "/statistics/{accountName}", consumes = MediaType.APPLICATION_JSON_UTF8_VALUE)

　　    void updateStatistics(@PathVariable("accountName") String accountName, Account account);

　　}

　　上面的例子指定了所需的服務(wù)id - statistics-service，依靠Eureka的自動發(fā)現(xiàn)

　　Monitor Dashboard

　　在這個項目配置中，搭載Hystrix的每個微服務(wù)都通過Spring Cloud Bus(使用AMQP代理)向Turbine推送指標(biāo)。Monitoring project只是一個小型的包含Turbine和Hystrix儀表板的Spring boot應(yīng)用程序。

　　讓我們看看不同負(fù)載下的系統(tǒng)行為：Account service調(diào)用Statistics service ，Statistics service 響應(yīng)模擬不同的延遲。響應(yīng)超時閾值設(shè)置為1秒。

Monitor Dashboard

　　Log Analysis

　　集中式日志在分析分布式系統(tǒng)中存在的問題時十分有效。Elasticsearch, Logstash, 和 Kibana的技術(shù)棧讓你輕松搜索和分析你的日志，系統(tǒng)利用率和網(wǎng)絡(luò)活動數(shù)據(jù)。在這篇文章中可以找到相關(guān)的描述。

　　Security

　　高級安全配置超出了這個概念驗證項目的范圍。 要更真實地模擬真實系統(tǒng)，請考慮使用https和JCE密鑰庫來加密微服務(wù)密碼和配置服務(wù)器屬性內(nèi)容(請參閱文檔以了解詳細(xì)信息)。

　　Infrastructure Automation(基礎(chǔ)設(shè)置自動化)

　　部署相互依賴的微服務(wù)，比部署整體應(yīng)用程序要復(fù)雜得多。 擁有完全自動化的基礎(chǔ)設(shè)施非常重要。 采用持續(xù)交付方式，我們可以獲得以下好處：

　　·隨時發(fā)布軟件的能力。

　　·任何構(gòu)建可能最終成為一個release。

　　·一次構(gòu)建工件，根據(jù)需要進(jìn)行部署

　　這是在這個項目中實現(xiàn)一個簡單的持續(xù)交付工作流程：

持續(xù)交付流程

　　在這個配置中，Travis CI為每個成功的Git推送建立標(biāo)記的圖像。 因此，Docker Hub上的每個微服務(wù)總是有最新的鏡像，而舊鏡像使用Git commit hash進(jìn)行標(biāo)記。 如果需要的話，部署它們很容易并且快速回滾。

　　How to Run All the Things?

　　你將啟動8個Spring Boot應(yīng)用程序，4個MongoDB實例和RabbitMq。 確保您的機(jī)器上有4 Gb RAM。 通過Gateway，Registry，Config，Auth Service和Account Service，您始終可以運行重要的服務(wù)。

　　開始之前

　　·安裝Docker和Docker Compose。

　　·導(dǎo)出環(huán)境變量: CONFIG_SERVICE_PASSWORD, NOTIFICATION_SERVICE_PASSWORD, STATISTICS_SERVICE_PASSWORD, ACCOUNT_SERVICE_PASSWORD, MONGODB_PASSWORD

　　Production Mode

　　在這種模式下，會從 docker hub 下抓取最新的 images，只需復(fù)制docker-compose.yml并點擊docker-compose up -d

　　Development Mode

　　如果您想自己構(gòu)建鏡像(例如，在代碼中進(jìn)行了一些更改)，則必須克隆所有repository并使用Maven構(gòu)建。 然后運行

　　docker-compose -f docker-compose.yml -f docker-compose.dev.yml up -d

　　docker-compose.dev.yml繼承了docker-compose.yml，可以在本地構(gòu)建鏡像并公開所有容器端口以方便開發(fā)。

　　·Important Endpoints

　　·Ilocalhost:80 - Gateway

　　·Ilocalhost:8761 - Eureka Dashboard

　　·Ilocalhost:9000 - Hystrix Dashboard

　　·Ilocalhost:8989 - Turbine stream (source for Hystrix Dashboard)

　　·Ilocalhost:15672 - RabbitMq management

　　注意

　　所有Spring Boot應(yīng)用程序都需要依賴運行中的Config Server才能啟動。 但是，我們可以同時啟動所有的容器，因為docker-compose選項始終存在Spring Boot的fail-fast和restart屬性。 這意味著所有從屬容器將嘗試重新啟動，直到配置服務(wù)器啟動并運行。

　　此外，在所有應(yīng)用程序啟動之后，服務(wù)發(fā)現(xiàn)機(jī)制還需要一些時間，服務(wù)都不會立馬被客戶端的發(fā)現(xiàn)，直到實例，Eureka服務(wù)器和客戶端在其本地緩存中都具有相同的元數(shù)據(jù)，因此可能需要3個心跳。 默認(rèn)心跳周期是30秒。

關(guān)于如何理解Spring Cloud和Docker的微服務(wù)架構(gòu)問題的解答就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注億速云行業(yè)資訊頻道了解更多相關(guān)知識。