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

基於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)

分享創造快樂