微服務架構是將一個大型應用程序拆分為一組小型、獨立部署的服務,每個服務運行在自己獨立的進程中,并通過輕量級通信機制(如HTTP REST API)進行通信。
與單體架構的區別:
- 部署方式:單體應用整體部署,微服務可獨立部署
- 技術棧:單體通常采用統一技術棧,微服務支持多語言技術棧
- 數據管理:單體使用共享數據庫,微服務每個服務有自己的數據庫
- 可擴展性:單體只能整體擴展,微服務可按需擴展特定服務
- 容錯性:單體一個模塊故障影響整個系統,微服務故障隔離更好
Eureka:服務注冊與發現組件
- 服務提供者啟動時向Eureka注冊自己的信息
- 服務消費者從Eureka獲取服務提供者地址列表
- 支持服務健康檢查和服務剔除機制
Ribbon:客戶端負載均衡器
- 基于服務列表實現客戶端負載均衡
- 支持輪詢、隨機、權重等多種負載策略
- 可與Eureka無縫集成
Feign:聲明式服務調用組件
- 基于接口注解的REST服務調用
- 集成Ribbon實現負載均衡
- 簡化服務間調用代碼編寫
Hystrix:服務熔斷與降級
- 防止服務雪崩效應
- 實現服務熔斷、降級、限流
- 提供監控儀表盤
Zuul/Gateway:API網關
- 統一入口,路由轉發
- 身份認證與安全控制
- 請求監控與限流
Config:分布式配置中心
- 集中管理所有環境的配置
- 支持配置動態刷新
- 與Git等版本控制系統集成
服務熔斷:
- 當服務調用失敗率達到閾值時,斷路器打開
- 在斷路器打開期間,直接返回失敗,不再調用實際服務
- 經過一段時間后進入半開狀態,嘗試恢復調用
服務降級:
- 在系統高負載時,暫時關閉非核心服務
- 提供默認返回值或緩存數據
- 保證核心服務的可用性
2PC(兩階段提交):
- 準備階段:協調者詢問所有參與者是否可以提交
- 提交階段:如果所有參與者都同意,則提交事務
- 缺點:同步阻塞、單點故障、數據不一致風險
TCC(Try-Confirm-Cancel):
- Try階段:資源檢查和預留
- Confirm階段:確認執行,要求冪等
- Cancel階段:回滾操作,要求冪等
Saga模式:
- 長事務拆分為多個本地事務
- 每個本地事務都有對應的補償事務
- 執行失敗時按逆序執行補償事務
消息隊列最終一致性:
- 通過消息隊列實現異步處理
- 保證消息可靠投遞
- 結合本地消息表或事務消息
路由轉發:
- 根據請求路徑將請求轉發到對應微服務
- 支持動態路由配置
- 負載均衡策略
認證鑒權:
- JWT令牌驗證
- OAuth2.0授權
- API訪問權限控制
流量控制:
- 限流:令牌桶、漏桶算法
- 熔斷:服務異常時的快速失敗
- 降級:非核心服務暫時關閉
監控日志:
- 請求鏈路追蹤
- 訪問日志記錄
- 性能指標監控
安全防護:
- SQL注入防護
- XSS攻擊防護
- DDoS攻擊防護
Istio架構:
- 數據平面:Envoy代理,處理服務間通信
- 控制平面:Pilot、Mixer、Citadel
- 提供服務發現、負載均衡、故障恢復等功能
核心功能:
- 流量管理:路由規則、故障注入
- 安全通信:mTLS加密、身份認證
- 可觀測性:指標收集、分布式追蹤
容器化部署:
- Docker容器封裝應用
- Kubernetes容器編排
- 服務自動伸縮
DevOps集成:
- CI/CD流水線
- 自動化測試部署
- 基礎設施即代碼
服務治理:
- 服務注冊發現
- 配置中心管理
- 監控告警體系
通過深入理解這些微服務核心概念和互聯網接入服務,求職者能夠在面試中展現出扎實的技術功底和實戰經驗,為成功獲得心儀職位奠定堅實基礎。
如若轉載,請注明出處:http://www.pikua.cn/product/44.html
更新時間:2026-02-28 03:58:20
PRODUCT