歡迎光臨
每天分享高質量文章

基於Spring Cloud的微服務容器化實踐

近幾年,網際網路飛速發展的同時,也推動了雲端計算、大資料、人工智慧的快速落地,資料本身價值也得到提升。網際網路發展對應用開發提出了更高要求。首先資料採集的量級和效率提高,傳統的單體架構將出現瓶頸,其次是資料聯通性的需求,對資料對接必須保證高效能、高安全、高標準。使用微服務架構恰好解決了大部分痛點。
本次主要介紹基於Spring Cloud構建微服務,以及配套的DevOps思路,並著重介紹在Docker容器裡如何部署基於Spring Cloud的微服務。


1、基於Spring Cloud構建微服務

歷史總是驚人的相似,合久必分,分久必合。我們經歷了“合”:單體架構(軟)、計算能力超強的小型機(硬)到“分”:分散式架構的轉變,後期可能會將分發揮到了極致(去中心化的分散式,如區塊鏈),最後很可能再經歷“合”:計算和儲存能力超強的“智人”(集超級計算和儲存一身的人工智慧)。
單體架構也有自身優勢,這裡不做詳細介紹,大家在做架構選型時可以根據公司組織架構和業務需求綜合考慮。
Spring Cloud作為Java語言的微服務框架,它依賴於Spring Boot,是由Pivotal團隊提供的全新Web框架。有快速開發、持續交付和容易部署等特點。Spring Cloud提供了開發分散式服務系統的一些常用元件,例如服務註冊和發現、配置中心、熔斷器、智慧路由、微代理、控制匯流排、全域性鎖、分散式會話等。
先看看我們使用的一個架構:

  • 服務發現中心(Service Discovery):服務註冊與發現元件(選用Erueka)

  • 監控面板(Monitor Dashboard):整合了熔斷監控(選用Hystrix)、服務呼叫鏈路監控(選用Spring Cloud Sleuth)

  • 日誌分析面板(Logging Analyses):基於efk構建的日誌採集系統

    服務閘道器(Edge Server):服務閘道器元件(Zuul & Spring Cloud Security)

  • OAuth認證伺服器(OAuth Authorization Server):授權認證模組(Spring Cloud security OAuth2)

  • 配置伺服器(Configuration Server):配置中心(Spring Cloud Config & Spring Cloud Bus)


2、基於微服務架構體系的DevOps思路

DevOps帶來的不僅是技術挑戰,還受公司組織架構和文化影響,這裡是從技術角度去實現的思路。
先看兩個微服務應用案例:
案例1:基於微服務架構的介面開發
平臺主要提供Restful API服務,服務方式多樣,其中一個最簡單的案例流程如下:
  • 首先企業透過申請賬號、密碼和需要呼叫的API

  • 平臺針對申請企業建立可呼叫API的賬號和密碼,並將該企業呼叫端IP加入服務白名單,使用者可在平臺下載檔案、SDK,併進行測試

  • 企業根據使用者名稱、密碼去獲取token,併在請求essay-header中加入申請的token呼叫介面

案例2:基於微服務架構的應用開發
Web應用開發採用前後端分離方式,前端採用AngularJS,後端仍是基於Spring Cloud的微服務,整套系統部署到容器雲實現CI/CD,架構如下圖所示:

微服務引入增加了團隊配合、測試、運維等後續一系列操作的複雜度,必須考慮自動化,因此需要有一套CI/ CD方案應對:

大致流程:
  1. 研發完成本地開發和測試提交程式碼

  2. 程式碼連同Dockerfile等構建檔案一起push到GitLab(可以自己搭建)

  3. 程式碼提交觸發Jenkins自動構建

  4. Jenkins呼叫單元測試、程式碼檢查等測試任務,如果測試透過自動構建Docker映象

  5. Jenkins將構建好的映象推送到私有映象倉庫(自己搭建Harbor映象庫)

  6. Jenkins呼叫容器管理平臺(我們使用的Rancher)的介面進行升級

  7. 容器管理平臺拉取映象完成部署(測試環境or生產環境)

說明:這裡我們不僅使用了Docker,還選用容器編排工具構建了容器雲平臺,以方便我們快速實現CI/CD。大家可以根據自己情況選擇,如Kubernetes、Rancher(Rancher 2.0以後底層使用的編排工具也是Kubernetes)等。


3、Spring Cloud基於Docker的實踐

我們使用Docker,主要因為以下4點:
  1. Docker提供一個簡單、輕量的建模方式

  2. Docker使團隊職責的邏輯分離

  3. 可以實現快速高效的開發生命週期

  4. 團隊使用面向服務的架構

以下介紹如何構建Docker映象和配置細節。
1. 專案目錄
Dockerfile及相關檔案一般放到專案子目錄,由開發維護。這種方式對研發提出了更高的技能要求,這也是近期全棧工程師比較火的一個原因。當然,具體協作方式還是根據公司情況定。以下是我們的專案目錄:

2. 編寫Dockerfile(供參考)
註:配合自動化工具使用效果更好。
FROM harbor.jry.com/library/alpine-jdk-time:slim
ADD *.jar service.jar
COPY formFile /
ENTRYPOINT [ "sh""-c""java -jar service.jar" ]

3、模組配置

我們將Spring Cloud相關的配置放到了bootstrap.yml檔案,需要註意的配置如下:

註意標紅部分,服務要以IP地址方式註冊到註冊中心,否則註冊中心無法做心跳檢測,因為容器之間預設無法透過hostname通訊。我們也可以搭建內部DNS方式解決此問題。
服務發現中心建議配置成高可用(比如兩個註冊中心互相註冊),也需要上圖配置。
4、打包構建
這裡截取了Jenkins裡的打包及構建命令:
  1. 打包

  2. 構建

5、容器啟動配置(docker-compose.yml)

version: '2'
services:
  zipkin:
    image: harbor.jry.com/zipkin:v1.0.1
    environment:
      eureka.client.service-url.defaultZone: http://discovery:8761/eureka/
    stdin_open: true
    tty: true
     links:
    - discovery2:discovery
     volumes:
    - /data/log:/target/log
    ports:
    - 9411:9411/tcp

  service-config:
    image: harbor.jry.com/service-config:v1.0.1
    hostname: config
    environment:
      eureka.client.service-url.defaultZone: http://discovery:8761/eureka/
    stdin_open: true
    tty: true
    links:
    - discovery2:discovery
    volumes:
    - /data/log:/target/log
    ports:
    - 8889:8889/tcp

  service-monitor:
    image: harbor.jry.com/service-monitor:v1.0.1
    environment:
      eureka.client.service-url.defaultZone: http://discovery:8761/eureka/
    stdin_open: true
    tty: true
    links:
    - discovery1:discovery
    volumes:
    - /data/log:/target/log

  discovery2:
    image: harbor.jry.com/service-discovery
    environment:
      eureka.client.service-url.defaultZone: http://discovery:8761/eureka/
    stdin_open: true
    tty: true
    links:
    - discovery1:discovery
    volumes:
    - /data/log:/target/log
    ports:
    - 8762:8761/tcp

  discovery1:
    image: harbor.jry.com/service-discovery:v1.0.1
    environment:
      eureka.client.service-url.defaultZone: http://discovery:8761/eureka/
    stdin_open: true
    tty: true
    links:
    - discovery2:discovery
    volumes:
    - /data/log:/target/log

  daas-monitor:
    image: harbor.jry.com/daas-monitor:v1.0.1
    environment:
      eureka.client.service-url.defaultZone: http://discovery:8761/eureka/
    stdin_open: true
    tty: true
    links:
    - discovery1:discovery
    volumes:
    - /data/log:/target/log
    ports:
    - 9080:9080/tcp

  proxy-server:
    image: harbor.jry.com/service-proxy:v1.0.1
    environment:
      eureka.client.serviceUrl.defaultZone: http://discovery:8761/eureka/
    stdin_open: true
    links:
    - discovery1:discovery
    tty: true
    links:
    - oauth2-server:oauth
    volumes:
    - /data/log:/target/log
    ports:
    - 8111:8443/tcp

  oauth2-server:
    image: harbor.jry.com/oauth2-cg:v1.0.1
    environment:
      eureka.client.serviceUrl.defaultZone: http://discovery:8761/eureka/
    stdin_open: true
    links:
    - discovery2:discovery
    volumes:
    - /data/log:/target/log
    tty: true
    ports:
    - 9999:9999/tcp
說明:
  • Zipkin:服務呼叫鏈路監控

  • service-config:配置中心服務

  • service-monitor:斷路監控服務

  • discovery1, discovery2:高可用的服務發現中心

  • daas-monitor:自研的監控面板,整合其他監控服務

  • proxy-server:服務閘道器

  • oauth2-server:OAuth認證伺服器

註:
  1. 雖然使用的配置檔案,但維護起來還是很麻煩,所以建議使用編排工具,一般會提供部分DevOps工具集。

  2. 上述各服務模組可以根據實際情況啟動多個相同容器,以保證高可用。

  3. 以上各服務模組做了磁碟對映,主要為採集日誌,這裡我們使用的EFK,時間關係暫不展開。

Q&A;

Q:WSO2的API Manager會將所有流量都統一到他這裡進出,如何解決統一API閘道器的大流量問題?
A:API Manager是可以拆開的,分開部署,比如呼叫你介面走閘道器模組,可以做高可用。當然不拆開也可以做高可用,前面加負載均衡。
Q:Eureka在生產上的Kubernetes中是如何做到高可用和動態擴容的?
A :好問題,Eureka我們目前是指定數量,可以結合指令碼(或程式碼)做動態擴容和高可用。目前我們Hadoop就是結合程式碼做到的。
Q:服務之間二階段事務控制一般怎麼做?或者說有沒有現成工具或程式碼?服務間用http靠譜還是其他協議靠譜?
A:這個網上有一些思路比如補償的方式,還有就是透過流資料庫(Kafka),事件驅動的方式。我們目前正在嘗試這種方式。

基於Kubernetes的DevOps實踐培訓

基於Kubernetes的DevOps實踐培訓將於2018年8月24日在北京開課,3天時間帶你係統掌握Kubernetes本次培訓包括:容器特性、映象、網路;Kubernetes架構、核心元件、基本功能;Kubernetes設計理念、架構設計、基本功能、常用物件、設計原則;Kubernetes的資料庫、執行時、網路、外掛已經落地經驗;微服務架構、元件、監控方案等,點選下方圖片檢視詳情。

贊(0)

分享創造快樂