軟件行業中架構概念引爭論，需梳理多組相似概念！文末有驚喜？
更新時間：2025-07-28 11:57:17作者：佚名
一. 什么是架構和架構本質（文末有驚喜）
在軟件領域，關于架構的定義存在諸多爭議，每個人對此都有自己的見解。這位所說的架構可能與那位所理解的架構并不相同。鑒于此，在展開架構的討論之前，我們首先需明確架構的定義。概念作為認識世界的基礎，同時也是交流的工具。若對架構概念的理解存在差異，那么在溝通時自然會感到不順暢。
Linux體系結構存在，MySQL同樣擁有架構，JVM亦不例外。在這樣的背景下，以Java進行開發、以MySQL進行數據存儲、運行在Linux環境中的業務系統，它們同樣具備架構。那么，我們究竟應該關注哪一個架構呢？要解答這一問題，我們需要對一系列相互關聯且性質相近的概念進行梳理：系統及其子系統、模塊與組件、框架與架構。
1.1. 系統與子系統
系統，通常指的是由眾多相互關聯的個體所構成，它們遵循特定的規則協同運作，并具備單個元件無法單獨實現的功能的集體。
子系統，它是由眾多相互關聯的個體所構成的，通常情況下，它是隸屬于一個更大系統中的一個組成部分。
1.2. 模塊與組件
這些均為系統的構成要素，不過是將系統從不同維度進行劃分罷了。模塊代表的是邏輯上的獨立單元，而組件則指的是物理上的獨立部分。
模塊化是將系統在邏輯層面進行拆分，也就是采取分解的策略，從而將復雜的問題簡化。模塊的規模可以靈活調整，它可以是整個系統，或是若干個子系統，亦或是某個具體的服務、函數、類、方法、功能單元等。
該系統所涉及的組件涵蓋了應用服務、數據庫管理系統、網絡設施，以及物理服務器等，此外，亦包括消息隊列、容器技術、Nginx等多樣化的技術元素。
1.3. 框架與架構
框架是組件遵循的標準，諸如MVC、MVP、MVVM等，它們是具備基礎功能的產品。比如，開源框架Ruby on Rails、Spring、Laravel、Django等，這些框架既可直接應用，也可在此基礎上進行進一步的開發。
框架是規范，架構是結構。
我在這重新定義架構：軟件架構指軟件系統的頂層結構。
經過周密思考與利弊分析，架構是在現有資源限制下做出的最優化選擇，它最終確定了系統的基本框架：涵蓋子系統、模塊、組件及其相互間的協作機制、約束規則和指導方針。這一框架還指導著團隊成員在思想上的統一。該架構涉及以下四個方面：
系統性的合理決策至關重要，涉及諸如技術選擇與解決方案的確定。構建清晰的系統架構，明確指出系統的各個組成部分。同時，關注系統各部分之間的協作機制，以確保它們能夠協同完成業務需求。此外，還需制定約束規范和指導原則，以確保系統的有序、高效與穩定運行。
因此，架構師需具備以下能力：深入理解業務需求，全面掌控項目全局，挑選恰當的技術方案，有效解決核心難題，并指導研發團隊將方案成功實施。
架構的核心在于對系統進行有序的重組，以適應現有業務的進步，同時具備迅速擴展的能力。
要考慮進行架構設計的系統，其技術并非無端產生或自發演進，其架構的演進與需求的形成，均源自于業務的發展推動。
架構設計完全是為了業務，
需求較為復雜，非功能性的需求在系統中扮演著關鍵角色。系統擁有較長的生命周期，并需滿足擴展性的要求。此外，系統設計需考慮基于組件或集成的方式，以及業務流程的重新設計。因此，在架構設計上，需要考慮分層和分類。
架構體系可以進一步劃分為業務層面、應用層面、技術層面，以及代碼層面和部署層面。
業務架構代表著戰略方向，應用架構則體現為具體實施策略，而技術架構則是實現這些策略的工具。在三者中，應用架構扮演著至關重要的角色，它不僅肩負著將業務架構轉化為實際操作的重任，同時也在技術選型上發揮著決定性的作用。
對業務內容深入了解，構建起業務體系架構英語的英文，依據該體系，制定對應的應用體系，最終將技術體系實際應用到實踐中。
在當前需求背景下，開發者尤其是架構師必須深思熟慮，如何挑選恰當的應用架構，以及如何確保架構在未來能夠實現平穩過渡。
2.1. 業務架構（俯視架構）：
涵蓋業務規劃、模塊劃分以及流程梳理，對系統整體業務進行細致拆解，同時設計領域模型，將實際業務內容轉化為理論上的抽象實體。
沒有絕對的完美設計，只有最適合的設計方案，所有系統構建的核心理念都應聚焦于解決實際業務難題，若技術構建脫離了業務實際，容易導致系統陷入困境，而那些完全不考慮業務需求，隨意發揮的架構設計，實則是無理取鬧的行為。
我們需要明確所有問題的基礎在于了解目前所面對的業務規模及其增長趨勢，同時，處理高并發問題必然是一個逐步推進的漸進過程。一個合理的架構設計應能預見到未來1至2年的業務發展，通過這樣的設計，我們可以在付出相對合理的成本后，真正實現技術對業務成長的引領作用。
看看京東業務架構（網上分享圖）：
2.2. 應用架構（剖面架構，也叫邏輯架構圖）：
硬件至應用層面的抽象涵蓋抽象層與編程接口兩個層面。應用架構與業務架構之間存在著相互促進的緊密聯系。在業務架構的各個組成部分中，均融入了應用架構的元素。
類似：
應用架構將獨立可部署的單元應用于系統，從而為系統劃定了清晰的界限，并在系統功能組織、代碼開發、部署及運維等多個方面產生了深遠影響。該架構明確了系統包含哪些應用，以及這些應用之間如何進行分工與協作。在此語境中，“應用”指的是各個邏輯模塊或子系統。
應用架構圖關鍵有2點：
①. 職責劃分: 明確應用（各個邏輯模塊或者子系統）邊界
②. 職責之間的協作：
應用分層有兩種方式：
應用之間的協作模式展現了它們如何共同處理復雜的業務場景，這一過程主要表現在它們之間的通信方式和數據交換格式上。通信方式包括同步調用、異步消息傳遞以及共享數據庫訪問等，而數據交換格式則涵蓋了文本、XML、JSON以及二進制等多種形式。
應用的方向側重于業務領域，映射出業務體系結構；而應用的融合則傾向于技術層面貝語網校，作用于技術架構。分應用有助于簡化業務復雜性，使系統運行更加有序；相對地，融合應用則提升了技術復雜性，導致系統運行更加混亂。
應用架構的核心在于對系統進行拆分處理，旨在協調業務與技術的復雜度，確保整體系統既保持分散的結構，又維持內在的統一性。
系統所采納的應用架構選擇，受多方面因素制約，如企業所處的成長階段及其業務特性；此外，技術層面的復雜性亦不容忽視，這涉及IT技術的進步階段及內部技術人員的專業能力。業務規模的擴大不可避免地會引發技術層面的復雜性，而應用架構的設計宗旨在于在解決業務復雜性的同時，力求技術不至過于復雜架構英語的英文，從而保障業務架構的有效實施。
2.3. 數據架構
數據架構對數據庫的構建起著指導作用，這不僅僅意味著要關注開發過程中涉及的數據庫和實體模型，還要求我們充分考慮物理架構層面上的數據存儲設計。
2.4. 代碼架構（也叫開發架構）：
子系統代碼架構為開發者提供了切實可行的指導原則，若架構設計存在缺陷，則可能對整體架構設計產生不利影響。例如，若公司內部不同開發團隊采用各異的技術棧或組件，可能導致公司整體架構設計陷入混亂。
代碼架構主要定義：
①. 代碼單元:
②. 代碼單元組織：
2.5. 技術架構
技術架構方面，需明確應用系統所依賴的具體運行模塊，如負載均衡器、反向代理服務器、應用服務器以及PHP進程管理器等；同時，還需界定這些模塊間的相互聯系，并制定它們在硬件設備上的部署策略。
技術架構設計主要側重于系統非功能性方面的考量，確保系統在可用性、性能、可擴展性、安全性、伸縮性和簡潔性等方面達到系統整體層面的要求。
系統架構的構建需要架構師對軟件與硬件的功能及性能有扎實的掌握，而這正是架構設計過程中最具挑戰性的環節之一。
2.6. 部署拓撲架構圖（實際物理架構圖）：
拓撲結構涵蓋了節點部署情況、節點間的相互聯系、服務器的高可靠性、網絡接口與協議等因素，這些因素共同決定了應用的運行方式、性能表現、維護便利性以及擴展能力，構成了架構的根本。此圖是運維工程師重點關注的內容。
物理架構設計需重點考慮硬件設備的選擇以及網絡布局，同時關注軟件與硬件之間的映射關系，以及它們之間的相互作用。
三. 架構級別（文末有驚喜）
我們使用金字塔的架構級別來說明,上層級別包含下層：
戰略設計與戰術設計
依托于架構金字塔的框架，我們實現了系統架構在戰略層面與戰術層面的完美融合。
四. 應用架構演進
業務架構構成了生產力，應用架構則代表了生產關系，而技術架構則是生產過程中不可或缺的工具。業務架構對應用架構具有決定性作用，應用架構必須與業務架構相匹配，并隨著業務架構的發展而持續演變。與此同時，應用架構的實現離不開技術架構的支持，最終得以落地實施。
架構演進路程：單體應用→分布式應用服務化→微服務
4.1. 單體應用
企業初期業務相對單一，主要針對某一特定場景，只需實現數據的基本增刪改查功能以及簡單的邏輯處理，單個應用便能充分滿足需求。
該系統采用了一種典型的三級結構設計，包括前端部分（無論是Web端還是移動端）、負責處理業務邏輯的中間層以及存儲數據的數據庫層。這種設計模式常見于Java Spring MVC或Python Django等框架的應用場景。具體的架構圖，請參考下文展示。
針對單體應用，非功能性需求的做法：
性能提升需借助緩存技術，并發需求可通過集群方案解決；讀寫分離則需采用數據庫層面的策略，反向代理與CDN可助力加速，分布式文件系統與數據庫技術亦不可或缺。
單體架構的實施較為簡便，易于部署和檢驗，尤其在項目啟動階段，單個應用能夠高效運作。不過，伴隨著需求量的持續上升，開發團隊的規模不斷擴大，代碼庫也迅速擴張。隨著時間的推移，單體應用逐漸顯得龐大，其可維護性和靈活性逐步減弱，維護費用亦隨之攀升。以下列舉了單體架構應用存在的一些不足之處：
4.2. 分布式
隨著業務不斷拓展，所需的產品功能日益豐富，各個業務模塊的運作邏輯也日益繁復，業務涉及的深度與廣度同步提升，導致單一應用系統逐漸顯得龐大，其可維護性和靈活性逐步下降，新增功能的開發周期不斷延長，維護成本也隨之攀升。
此時，需對系統進行業務功能模塊的劃分，并將各模塊實現服務化，構建為一個分布式架構。這些業務模塊將分別部署于不同的服務器之中，而它們之間則通過接口實現數據的互通與交流。
與單體架構相較，本架構具備負載均衡功能，顯著增強了系統的承載能力，有效滿足了網站面對高并發情況的需求。此外，它還具有以下幾項特性：
4.3. 微服務
隨著業務模式日漸繁復，訂單、商品、庫存、價格等多個環節都涉及到了深層次的運作。例如，價格策略會根據會員等級、訪問渠道（如app或PC端）以及銷售方式（如團購或普通銷售）進行區分，同時伴隨眾多價格促銷活動。這些規則錯綜復雜，往往容易產生沖突。因此，有必要將分散在各個業務中的價格邏輯進行集中管理，并以基礎價格服務的形式，透明地向上層應用提供，進而構建成一個以微服務為核心的輕量級服務架構。
微服務的特點：
微服務架構雖然具備諸多誘人的優勢，然而，它并非毫無成本，采用這一架構同樣需要付出相應的代價。在使用微服務架構的過程中，我們將會遭遇一系列的挑戰。
五. 衡量架構的合理性
構建的框架應當服務于業務需求，不存在絕對的最優設計，唯有契合需求的才是最佳選擇。架構設計始終以實現高效、穩定、安全為標準，以此來評估其合理性。
合理的架構設計：
5.1. 業務需求角度
5.2. 非業務需求角度
①. 穩定性。指標：
②. 高效指標：
③. 安全指標
六. 常見架構誤區（文末有驚喜）
開高走落不到實處
常見誤區
七. 架構知識體系
7.1. 架構演進
7.2. 架構模式
分層：橫向分層：應用層，服務層，數據層
分割：縱向分割：拆分功能和服務
分布式
集群：提高并發和可用性
緩存：優化系統性能
異步：降低系統的耦合性
冗余：冷備和熱備，保證系統的可用性
自動化：發布，測試，部署，監控，報警，失效轉移，故障恢復
安全：
7.3. 架構核心要素
高性能：網站的靈魂
可用性：保證服務器不宕機，一般通過冗余部署備份服務器來完成
集群的伸縮性體現在，它能否迅速適應流量的劇增，以及是否便于新增設備。
集群
在考慮可擴展性時，我們應著重于滿足功能需求，以便于應對業務范圍的拓展。同時，要能夠迅速適應業務上的變動。這涉及到是否遵循了開閉原則，以及系統內部各組件之間的耦合和依賴關系。
網站的安全性涉及諸多方面，包括是否有效堵住了各類攻擊途徑和漏洞，其架構是否具備限流功能，以及能否有效抵御ddos攻擊。
彩蛋時刻
相關文章
為您推薦
加載中...