我的那些年(13)~主推微服務架構 整個系統走向微服務架構 網關 服務註冊與發現 配置中心 熔斷器 鏈路跟蹤 授權與鑒權 服務間的通訊 同步feign 服務間的通訊 非同步消息 日誌收集 個系統走向微服務架構 公司系統比較多,耦合度比較大,將這些模塊進行拆分,各個負責自己的模塊,減少相互之間的直接依賴 ...
我的那些年(13)~主推微服務架構
- 整個系統走向微服務架構
- 網關
- 服務註冊與發現
- 配置中心
- 熔斷器
- 鏈路跟蹤
- 授權與鑒權
- 服務間的通訊-同步feign
- 服務間的通訊-非同步消息
- 日誌收集
個系統走向微服務架構
公司系統比較多,耦合度比較大,將這些模塊進行拆分,各個負責自己的模塊,減少相互之間的直接依賴,版本迭代互不影響,做到最小粒度的部署,這就是微服務,也是未來軟體架構與設計的一個趨勢!
我們系統的流程圖
graph TD classDef red fill:#f90,stroke:#555,stroke-width:4px; client-->gateway gateway-->gateway1 gateway-->gateway2 gateway1-->|用戶|user gateway1-->|產品|product gateway1-->|訂單|order gateway2-->|投票|devote gateway2-->|抽獎|lottery class gateway red; class gateway1 red; class user red; class product red; class order red;服務間的調用
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介面出現問題時,你可以有很多能策略,如重試機制,快速返回等。
graph TD classDef default fill:#f90,stroke:#555,stroke-width:4px; classDef red fill:#f99,stroke:#f00,stroke-width:1px; a-->b a-->c a-->|宕機|d class d redhystrix的基本配置,主要是對請求超時時間的配置
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
- 服務間的通訊-非同步消息
- 日誌收集