我的那些年(13)~主推微服務架構

張佔嶺發表於2019-07-17
微服務架構

我的那些年(13)~主推微服務架構

  • 整個系統走向微服務架構
  • 閘道器
  • 服務註冊與發現
  • 配置中心
  • 熔斷器
  • 鏈路跟蹤
  • 授權與鑑權
  • 服務間的通訊-同步feign
  • 服務間的通訊-非同步訊息
  • 日誌收集

個系統走向微服務架構

公司系統比較多，耦合度比較大，將這些模組進行拆分，各個負責自己的模組，減少相互之間的直接依賴，版本迭代互不影響，做到最小粒度的部署，這就是微服務，也是未來軟體架構與設計的一個趨勢！

我們系統的流程圖

graph TD classDef default fill:#f90,stroke:#555,stroke-width:4px; client-->gateway gateway-->gateway1 gateway-->gateway2 gateway1-->|使用者|user gateway1-->|產品|product gateway1-->|訂單|order gateway2-->|投票|devote gateway2-->|抽獎|lottery

服務間的呼叫

graph LR classDef default fill:#f90,stroke:#555,stroke-width:2px,stroke-dasharray:2,2; user-->|feign|product user-->|feign|order order-->|feign|product

服務間鏈式響應過程

graph LR classDef default fill:#f90,stroke:#555,stroke-width:2px,stroke-dasharray:2,2; user-->|請求|order order-->|請求|product product-->|響應|order order-->|響應|user

閘道器

閘道器作為整個系統的門面存在，當然一個超級大系統可能出現多個閘道器，而把關係比較緊密的系統通過一個閘道器對外提供服務，這是一種比較好的作法，對前端和使用者來說，它還是一個系統，而對於後端來說，它是由多個子服務組成，我們選擇的閘道器產品是比較流行的zuul，而springcloud2.0出來後，也推出了新的gateway元件，當然無論是使用哪個閘道器產品，功能都是相同的！

閘道器主要起到了路由，請求過濾，統一授權，限流等功能

    zuul.routes.userinfo.path=/getuser/**
    zuul.routes.userinfo.serviceId=userinfo-consumer
    zuul.ratelimit.enabled=true
    zuul.ratelimit.policies.userinfo.limit=3
    zuul.ratelimit.policies.userinfo.refresh-interval=60
    zuul.ratelimit.policies.userinfo.type=origin
    # 測試客戶端如果60s內請求超過三次，服務端就丟擲異常，一分鐘後又可以正常請求
    # 某個IP的客戶端被限流並不影響其他客戶端，即API閘道器對每個客戶端限流是相互獨立的

服務註冊與發現

讓多個子服務進行通訊，要求這些服務在一個網路裡，它們之間是可以互通的，而當服務越來越多，每個服務的埠，IP地址也會越來越繁瑣，而這時服務註冊元件就派上用場了，它將服務的IP和埠與一個服務名稱進行對映，讓開發人員只關注名稱,application.name即可，而名稱與真實服務的鏈路過程由服務註冊元件實現，我們在選擇服務註冊元件時，選擇了eureka。 eureka服務端

server:
  port: ${PORT:8761}
management:
  port: ${BG_PORT:8762}
application:
  name: ${NAME:eurekaserver}
spring:
  profiles:
    active: dev
---
eureka:
  profile: dev
  instance:
    hostname: ${application.name}
    perferIpAddress: true #基於IP地址註冊
  client:
    registerWithEureka: false #false表示不向註冊中心註冊自己。
    fetchRegistry: false #false表示自己端就是註冊中心，我的職責就是維護服務例項，並不需要去檢索服務
    serviceUrl:
      defaultZone: ${URL:http://${eureka.instance.hostname}:${server.port}/eureka/}

eureka客戶端註冊到服務端

spring:
  application:
    name: gateway
  profiles:
    active: ${SPRING_PROFILES_ACTIVE:dev}
server:
  port: 8003

eureka:
  client:
    service-url:
      defaultZone: http://${eureka.host:localhost}:${eureka.port:6761}/eureka/,
                   http://${eureka.host:localhost}:${eureka.port:5761}/eureka/

配置中心

將所有服務的配置都集中管理，這是一個不錯的想法，當配置更新後，不需要啟動服務，而通過訊息廣播的方法通訊服務即可，這就是配置中心的作用。之前的單體應用時，每個應用都有自己的配置檔案，而當專案多了之後，這些配置檔案不容易管理，要修改其中一些配置時，需要分別進入對應的服務裡，而且這些配置也無法實現繼承，重複的程式碼很多，比如很多服務都用了rabbitmq,redis等，單體應用裡，你需要複製這些配置到每個服務裡，而有了配置中心，你只需要在application.yml裡進行公用配置即可，而其它服務的配置會自動繼承。

配置中心使用了加密演算法儲存了配置檔案中的敏感資訊

server.port: ${PORT:8888}
management.port: ${BG_PORT:8889}
spring:
  application.name: lind-configserver
  profiles.active: development

encrypt:
  key-store:
    location: file:///Users/lind.zhang/github/dockerDeploy/swarm/server.jks
    password: changeit
    alias: config-server-key
    secret: changeit

---
spring:
  profiles: svt
  cloud:
    config:
      server:
        git:
          uri: /config_repo

---
spring:
  profiles: development
  cloud:
    config:
      server:
        git:
uri: /config_repo
對配置進行加密碼

要配置非對稱金鑰，您可以將金鑰設定為PEM編碼的文字值（encrypt.key），也可以通過金鑰庫設定金鑰（例如由JDK附帶的keytool實用程式建立）。金鑰庫屬性為encrypt.keyStore.*，*等於

  • location（a Resource位置），
  • password（解鎖金鑰庫）
  • alias（以識別商店中使用的金鑰）。

使用公鑰進行加密，需要私鑰進行解密。因此，原則上您只能在伺服器中配置公鑰，如果您只想進行加密（並準備使用私鑰本地解密值）。實際上，您可能不想這樣做，因為它圍繞所有客戶端傳播金鑰管理流程，而不是將其集中在伺服器中。另一方面，如果您的配置伺服器真的相對不安全，並且只有少數客戶端需要加密的屬性，這是一個有用的選項。

建立用於測試的金鑰庫

要建立一個金鑰庫進行測試，您可以執行以下操作：

$ keytool -genkeypair -alias mytestkey -keyalg RSA \
  -dname "CN=Web Server,OU=Unit,O=Organization,L=City,S=State,C=US" \
  -keypass changeme -keystore server.jks -storepass letmein

將server.jks檔案放在類路徑（例如）中，然後在您的application.yml中配置伺服器：

encrypt:
  keyStore:
    location: classpath:/server.jks
    password: letmein
    alias: mytestkey
    secret: changeme

使用端的yml檔案

foo:
  bar: `{cipher}{key:testkey}...`

熔斷器

熔斷在微服務中表現非常突出，在多個服務進行並行式呼叫時，這個熔斷功能就顯得非常重要了，比如A呼叫B，A再呼叫C，A再呼叫D，而在這個並行呼叫過程中，當B出現問題時，後面的C，D將不會執行，而預設情況下A會等到B達到超時後才會做出響應，而影響A呼叫其它服務，從而導致A這個介面整體變慢；而有了熔斷之後，當請求B介面出現問題時，你可以有很多能策略，如重試機制，快速返回等。

hystrix的基本配置，主要是對請求超時時間的配置

hystrix:
  command:
    default:
      execution:
        timeout:
          enabled: true
      isolation:
        strategy: SEMAPHORE #hystrix策略為thread時，threadlocal為空
        thread:
          #目前有兩個容器例項，單個請求超時5s,+重試>10s，超15s則熔斷
          timeoutInMilliseconds: 15000

鏈路跟蹤

當一個服務A呼叫服務B時，服務B也可能會呼叫服務C，這就形成了一個連結串列，在響應時的順序是相反的，所以這是一個雙向的連結串列，在這個連結串列裡，我們希望對它進行跟蹤，因為在一個請求出現問題時，你很難找到問題出現在哪個環節，所以我們的請求需要有一個traceId在各個服務連結串列間進行傳遞，這就是鏈路跟蹤的原理。

下面是鏈路跟蹤元件sleuth和日誌收集分析工具zipkin的配置

spring:
  application:
    name: user
  sleuth:
    web:
      client:
        enabled: true
    sampler:
      probability: 1.0 # 將取樣比例設定為 1.0，也就是全部都需要。預設是 0.1
    zipkin:
      base-url: http://localhost:9411/ # 指定了 Zipkin 伺服器的地址

下次有時間再說一下剩下的內容

  • 授權與鑑權
  • 服務間的通訊-同步feign
  • 服務間的通訊-非同步訊息
  • 日誌收集

相關文章