個系統走向微服務架構
公司系統比較多,耦合度比較大,將這些模組進行拆分,各個負責自己的模組,減少相互之間的直接依賴,版本迭代互不影響,做到最小粒度的部署,這就是微服務,也是未來軟體架構與設計的乙個趨勢!
我們系統的流程圖
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閘道器對每個客戶端限流是相互獨立的
服務註冊與發現server:
port: $
management:
port: $
name: $
spring:
profiles:
active: dev
---eureka:
profile: dev
instance:
perferipaddress: true #基於ip位址註冊
client:
registerwitheureka: false #false表示不向註冊中心註冊自己。
fetchregistry: false #false表示自己端就是註冊中心,我的職責就是維護服務例項,並不需要去檢索服務
serviceurl:
defaultzone: $:$/eureka/}
eureka客戶端註冊到服務端
http://$:$/eureka/配置中心
配置中心使用了加密演算法儲存了配置檔案中的敏感資訊
server.port: $
management.port: $
spring:
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.,等於
使用公鑰進行加密,需要私鑰進行解密。因此,原則上您只能在伺服器中配置公鑰,如果您只想進行加密(並準備使用私鑰本地解密值)。實際上,您可能不想這樣做,因為它圍繞所有客戶端傳播金鑰管理流程,而不是將其集中在伺服器中。另一方面,如果您的配置伺服器真的相對不安全,並且只有少數客戶端需要加密的屬性,這是乙個有用的選項。
建立用於測試的金鑰庫
要建立乙個金鑰庫進行測試,您可以執行以下操作:
$ 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
encrypt:
keystore:
location: classpath:/server.jks
password: letmein
alias: mytestkey
secret: changeme
使用端的yml檔案
foo:
bar: `...`
熔斷器
熔斷在微服務中表現非常突出,在多個服務進行並行式呼叫時,這個熔斷功能就顯得非常重要了,比如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 red
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:
name: user
sleuth:
web:
client:
enabled: true
sampler:
probability: 1.0 # 將取樣比例設定為 1.0,也就是全部都需要。預設是 0.1
zipkin:
base-url: http://localhost:9411/ # 指定了 zipkin 伺服器的位址
下次有時間再說一下剩下的內容 微服務架構Day13 SpringBoot之安全
授權 authorization 1.引入spring boot starter security依賴 2.編寫springsecurity配置類 2.1 定製請求的授權規則 2.2 開啟自動配置的登入功能 login來到登入頁 重慶向到 login?error表示登入失敗 2.3 開啟自動配置的登...
微服務的那些事
服務提供者如何發布乙個服務,服務消費者如何引用這個服務。具體來說,就是這個服務的介面名是什麼?呼叫這個服務需要傳遞哪些引數?介面的返回值是什麼型別?以及一些其他介面描述資訊 最常見的服務發布和引用的方式有三種 restful api 一般對外 xml配置 對內 idl檔案 跨語言,thrift,gr...
微服務架構的疑問
建立乙個自定義列表 如何建立乙個註腳 注釋也是必不可少的 katex數學公式 新的甘特圖功能,豐富你的文章 uml 圖表 flowchart流程圖 匯出與匯入 你好!這是你第一次使用markdown編輯器所展示的歡迎頁。如果你想學習如何使用markdown編輯器,可以仔細閱讀這篇文章,了解一下mar...