Java 應用架構並非一成不変的藍圖，而是隨著業務量級、團隊規模與技術棧的變化持續演進。本文系統梳理從「不同系統互通」到「單一產品演進」，再到「產品線架構」的三大核心維度，並結合實戰經驗總結架構設計的核心原則。
所謂 Web Service，本質上是基於 HTTP 協議實現異構系統通訊的工具。早期主流為基於 XML 的 SOAP 協議（常用 Apache CXF 實現），但隨著微服務興起，RESTful 風格因輕量、易用、天然支持 JSON 成為主流選擇。Spring MVC 等框架原生支持 REST 開發，極大降低了接入門檻。
狹義上，「Web Service」常指十年前 IBM 主導的 SOAP/WSDL 技術棧，現多見於傳統企業級集成；廣義上，一切基於網絡的服務調用皆屬 Web Service 範疇，「一切皆服務」已成共識。
當雙端均為 Java 等同語言系統，且無需對外開放時，RPC（遠程過程調用）或 RMI（遠程方法調用）是首選。RPC 以「像調用本地方法一樣調用遠程方法」的透明化體驗，配合 Dubbo、Thrift、gRPC 等高性能框架，在序列化效能、網絡開銷上顯著優於 REST，是構建高並發內部服務網格的基石。
參考《大型網站技術架構》經典模型，單一產品從初創到成熟通常經歷以下階段：
特徵：應用、數據庫、文件全在一台機器。
適用：初期流量低、功能簡單，追求開發部署極致簡單。
痛點：單機資源（CPU、內存、磁盤 I/O）觸頂。
策略：拆分應用服務器與數據庫服務器，並發處理能力與存儲空間雙提升。
核心：80% 請求集中訪問 20% 熱點數據。
分類：本地緩存（Guava/Caffeine，延遲極低但容量受限、一致性難）vs 分布式緩存。
關鍵：緩存穿透、擊穿、雪崩預案必備。
觸發：單機 Web 容器（如 Tomcat）連接數、線程池耗盡。
手段：Nginx/LVS/F5 做負載均衡，水平擴展 Stateless 應用節點，Session 共享。
本質：以冗余換取吞吐與可用性。
痛點：寫操作鎖競爭導致讀查詢阻塞。
架構：一主多從，主庫負責寫，從庫負責讀，中間件路由。
挑戰：主從同步延遲導致的數據不一致業務容忍度評估。
原理：就近緩存靜態資源（圖片、JS、CSS、視頻），降低回源壓力，改善弱網/跨地域體驗。
層級：瀏覽器緩存 → CDN 邊緣節點 → 反向代理 → 應用集群。
分庫：按業務域垂直拆分（用戶庫、訂單庫、商品庫），物理隔離故障域。
分表：單表超千萬行時水平拆分，路由演算法決定數據分布。
分布式文件：HDFS、Ceph、MinIO 解決海量非結構化數據存儲。
動機：關係型數據庫難以支撐高寫入、非結構化、全文檢索、複雜聚合等場景。
組合：Redis（緩存/計數器）、MongoDB（文檔）、Elasticsearch（搜索/日誌分析）、HBase（寬表）。
統一訪問層：屏蔽底層數據源差異，簡化業務邏輯。
縱向拆分：大應用 → 多個獨立 Web 應用，通過超鏈接或消息隊列協作。
橫向拆分：提取公共業務（用戶、商品、訂單）為獨立服務，新業務組合調用。
難點：分布式事務、服務發現、鏈路追蹤、治理體系建設。
核心痛點：
1. 服務爆炸 → 配置管理難、負載均衡單點壓力大
2. 依賴糾結 → 啟動順序不明、架構圖無法維護
3. 容量規劃 → 何時擴容、多少機器靠經驗猜
4. 溝通成本 → 接口文檔、負責人、SLA 缺失
5. 多租戶質量 → 熔斷、降級、限流、隔離機制缺失
解決方案：註冊中心、配置中心、網關、服務網格、可觀測性三大支柱。
當業務線增多，提煉「數據層 + 通用業務邏輯層 + 多端應用層」的平台化架構勢在必行：
Java 應用架構演進是業務複雜度與技術能力的博弈史。沒有銀彈，只有在特定業務階段、團隊狀態、技術成熟度下的最佳權衡。願每位架構師都能「知其然，更知其所以然」，在演進中構建穩健、可演進的系統。
