一、微服務核心面試題詳解

1. 什么是微服務架構？它與單體架構有何區別？

微服務架構是將一個大型應用程序拆分為一組小型、獨立部署的服務，每個服務運行在自己獨立的進程中，并通過輕量級通信機制（如HTTP REST API）進行通信。

與單體架構的區別：
- 部署方式：單體應用整體部署，微服務可獨立部署
- 技術棧：單體通常采用統一技術棧，微服務支持多語言技術棧
- 數據管理：單體使用共享數據庫，微服務每個服務有自己的數據庫
- 可擴展性：單體只能整體擴展，微服務可按需擴展特定服務
- 容錯性：單體一個模塊故障影響整個系統，微服務故障隔離更好

2. Spring Cloud的核心組件及其作用

Eureka：服務注冊與發現組件
- 服務提供者啟動時向Eureka注冊自己的信息
- 服務消費者從Eureka獲取服務提供者地址列表
- 支持服務健康檢查和服務剔除機制

Ribbon：客戶端負載均衡器
- 基于服務列表實現客戶端負載均衡
- 支持輪詢、隨機、權重等多種負載策略
- 可與Eureka無縫集成

Feign：聲明式服務調用組件
- 基于接口注解的REST服務調用
- 集成Ribbon實現負載均衡
- 簡化服務間調用代碼編寫

Hystrix：服務熔斷與降級
- 防止服務雪崩效應
- 實現服務熔斷、降級、限流
- 提供監控儀表盤

Zuul/Gateway：API網關
- 統一入口，路由轉發
- 身份認證與安全控制
- 請求監控與限流

Config：分布式配置中心
- 集中管理所有環境的配置
- 支持配置動態刷新
- 與Git等版本控制系統集成

3. 服務熔斷與服務降級的區別

服務熔斷：
- 當服務調用失敗率達到閾值時，斷路器打開
- 在斷路器打開期間，直接返回失敗，不再調用實際服務
- 經過一段時間后進入半開狀態，嘗試恢復調用

服務降級：
- 在系統高負載時，暫時關閉非核心服務
- 提供默認返回值或緩存數據
- 保證核心服務的可用性

4. 分布式事務解決方案

2PC（兩階段提交）：
- 準備階段：協調者詢問所有參與者是否可以提交
- 提交階段：如果所有參與者都同意，則提交事務
- 缺點：同步阻塞、單點故障、數據不一致風險

TCC（Try-Confirm-Cancel）：
- Try階段：資源檢查和預留
- Confirm階段：確認執行，要求冪等
- Cancel階段：回滾操作，要求冪等

Saga模式：
- 長事務拆分為多個本地事務
- 每個本地事務都有對應的補償事務
- 執行失敗時按逆序執行補償事務

消息隊列最終一致性：
- 通過消息隊列實現異步處理
- 保證消息可靠投遞
- 結合本地消息表或事務消息

二、互聯網接入及相關服務

1. API網關的核心功能

路由轉發：
- 根據請求路徑將請求轉發到對應微服務
- 支持動態路由配置
- 負載均衡策略

認證鑒權：
- JWT令牌驗證
- OAuth2.0授權
- API訪問權限控制

流量控制：
- 限流：令牌桶、漏桶算法
- 熔斷：服務異常時的快速失敗
- 降級：非核心服務暫時關閉

監控日志：
- 請求鏈路追蹤
- 訪問日志記錄
- 性能指標監控

安全防護：
- SQL注入防護
- XSS攻擊防護
- DDoS攻擊防護

2. 服務網格（Service Mesh）

Istio架構：
- 數據平面：Envoy代理，處理服務間通信
- 控制平面：Pilot、Mixer、Citadel
- 提供服務發現、負載均衡、故障恢復等功能

核心功能：
- 流量管理：路由規則、故障注入
- 安全通信：mTLS加密、身份認證
- 可觀測性：指標收集、分布式追蹤

3. 云原生微服務

容器化部署：
- Docker容器封裝應用
- Kubernetes容器編排
- 服務自動伸縮

DevOps集成：
- CI/CD流水線
- 自動化測試部署
- 基礎設施即代碼

服務治理：
- 服務注冊發現
- 配置中心管理
- 監控告警體系

三、實踐建議

1. 微服務拆分原則

• 單一職責原則
• 領域驅動設計
• 團隊自治邊界
• 數據獨立原則

2. 性能優化策略

• 緩存優化：Redis集群、本地緩存
• 數據庫優化：分庫分表、讀寫分離
• 異步處理：消息隊列、事件驅動
• 連接池優化：數據庫連接池、HTTP連接池

3. 監控體系建設

• 應用監控：QPS、響應時間、錯誤率
• 系統監控：CPU、內存、磁盤、網絡
• 業務監控：關鍵業務指標
• 日志收集：ELK/EFK日志平臺

通過深入理解這些微服務核心概念和互聯網接入服務，求職者能夠在面試中展現出扎實的技術功底和實戰經驗，為成功獲得心儀職位奠定堅實基礎。