接口API技術
- 接口是在面向服務架構(SOA)和微服務的背景下RPC遠端調用産生的,目的是為了解耦
- 接口分類:
- 開放接口
- 在外網進行通路
- 通過appid+appsecret, 生成accessToken進行通訊
- 目的是為了授權接口權限,OAuth2.0協定
- 内部接口
- 一般隻能在區域網路中進行通路
- 服務與服務之間的調用關系都在同一個微服務系統中
- 目的是為了保證安全
如何設計一套API接口
- 接口權限: 開放接口,内部接口
- 接口幂等性
- 接口安全性
- 為了防止篡改資料,要驗證簽名
- 使用網關攔截接口,實作黑名單和白名單
- 接口使用RESTful風格:http協定+json格式,目的是為了跨平台
- 考慮到高并發的情況,對接口服務實作保護功能:服務降級,服務熔斷,服務保護
- 最後使用統一的API管理平台:api swagger
網關(API Gateway)
- 用戶端請求先統一請求到網關伺服器上,再由網關伺服器進行轉發到實際的服務位址
- 網關作用:
- 網關與過濾器的差別:
- 網關是攔截整個微服務的請求
- 過濾器是對單個Tomcat伺服器進行攔截請求
- 網關分為内網網關和外網網關
- Zuul和Nginx的異同:
- 相同點:
- Zuul和Nginx都可以實作負載均衡,反向代理,過濾請求,實作網關效果
- 不同點:
- 開發語言不同: Zuul采用Java語言寫的,Nginx采用C語言寫的
- 負載均衡實作不同: Zuul中采用Ribbon+Eureka實作用戶端負載均衡,Nginx實作的伺服器端負載均衡
- Nginx比Zuul功能更強大,因為Nginx整合了腳本語言(Nginx+Lua),更适合伺服器端負載均衡
- Zuul更适合Java語言微服務中的網關的實作
- 可以使用Nginx+Zuul作為網關實作:Nginx用于實作反向代理(隐藏服務真實IP位址),Zuul對微服務的實作網關攔截請求
搭建Zuul網關
1.引入Zuul依賴spring-cloud-starter-netflix-zuul
2.配置檔案:
eureka.client.serviceUrl.defaultZoo=http://localhost:8100/eureka #服務注冊url位址
server.port=80 # 網關端口号
spring.application.name=service-zuul # 網關名稱
zuul.routes.api-a.path=/api-ticket/** #當用戶端發送請求127.0.0.1:80/api-ticket/開頭的,都會被發送到app-ticket服務中
zuul.routes.api-a.serviceId=app-ticket # ticket服務别名,zuul整合ribbon預設自動實作負載均衡效果
zuul.routes.app-b.path=/api-user/** # 當用戶端發送請求127.0.0.1/api-user/開頭的,都會被發送到app-user服務中
zuul.routes.app-b.serviceId=app-user # app-b定義轉發規則
3.在類上标注@EnableZuulProxy注解開啟網關代理
搭建ZuulFilter過濾器
1.建立過濾器類繼承ZuulFilter
2.擷取上下文
3.擷取Request對象
4.從請求頭中擷取token
5.建立過濾器執行邏輯
6.實作ZuulFilter中的方法:
過濾類型:filterType() pre-表示在請求之前執行.
過濾器執行順序:filterOrder() 當一個請求在同一階段存在多個過濾器的時候,規定多個過濾器的執行順序
判斷過濾器是否生效:shouldFilter()
搭建動态Zuul網關路由轉發
搭建Nginx+Zuul網關叢集
- 如何實作叢集: 保證每台服務資料一緻,使用Nginx實作反向代理和負載均衡
- Zuul搭建網關:
- 使用Nginx+Zuul
- 遵循一主一備或者輪詢的原則
- 網關是多個
- 網關叢集原理: 用戶端發送請求,所有請求統一到Nginx上,在Nginx中實作反向代理和負載均衡,再使用輪詢機制轉發到網關上
1.在host中配置域名
2.在Nginx配置檔案中配置上遊伺服器(upstream),預設實作負載均衡
3.在過濾器中調用網關接口
- Nginx和Zuul差別:
- 微服務網關是針對整個微服務實作統一請求攔截,是以網關都采用相關語言(Java)開發