基於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的資料庫、執行時、網路、外掛已經落地經驗；微服務架構、元件、監控方案等，點選下方圖片檢視詳情。