1樓：尕小刀
根據自己的理解寫一點想法。
所謂架構，是對某個主體的構成要素及要素間關係的描述。以上幾個架構本質上是相同的，只是描述的主體不同。
1.軟體架構：是具體軟體的的設計草圖，切分解藕各功能模組，便於開發和維護。
2.系統架構：比如乙個具體的通訊系統、電力系統的架構
4.企業架構：企業是sos（system of system），也就是系統之系統，算是系統之上更高一層的主體，其組成要素是多個系統。
從這個角度來講企業架構也可以算是廣義的系統架構，而解決方案也可以算是企業架構。
在sos的構建過程中，可以向下分解為多個系統，然後再分解為具體的功能軟體，然後功能軟體經開發及測試後可集成為系統，系統經測試驗證後集成為sos，這就是複雜系統設計中常說的大v模型，左側逐層向下分解，右側逐層向上整合。
2樓：于海瀾
企業架構是最高端別的企業設計，包括業務架構和IT架構2個部分。
其它的幾個架構都是IT架構的範疇。
IT架構包括應用架構、資料架構、技術架構、基礎設施架構。
系統架構是某個單一系統的架構，但是要遵從整體的IT架構。
3樓：luoll
軟體架構、系統架構、解決方案架構、企業架構？這個問題我懷疑是國內某著名公司的員工問的，因為他們公司就在搞。
總的來說，一說到架構，如果你懂軟體，那麼你會了解為乙個軟體系統，這個軟體設計的組成結構，如哪些是基礎支援元件，哪些是完成A業務，哪些完成B業務。。。但說道企業架構的時候，就會問，該企業架構的幾個架構如業務架構、資料架構、業務架構、技術架構，以及他們如何鏈結在一起。我倒覺得，乙個企業確實需要這樣的架構，但不要神話它，最主要的是業務如何最終體現到軟體中和流程中。
而採取分離式設計時，最容易的錯誤就是各自為政，整合困難。那麼以資料為中心的架構設計，會自然提供整合的基礎。我提到過，企業最重要的資產是資料，甚至不是資訊，是資料。
企業的業務流程會變，IT系統會變，所需要的資訊與知識會變，唯有資料能夠積澱下來。這有點象自然演進，考古那種，啥都會消失，唐朝可以無比先進，但都會變，我們唯有找到反映當時情況的資料，才可以把握當思的面貌。
4樓：小馬甲
架構就是藍圖，是方向，是約束，規定了你應該朝什麼方向走，可以做什麼，不可以做什麼。架構這個詞本身就有很多種定義，並沒有乙個非常統
一、一致的定義。像你說的軟體架構、系統架構、產品架構、解決方案架構、企業架構要說區別的話我認為是面向的物件和範圍不同，簡單一點來說，軟體架構描述的是軟體的組成部分及其相互之間的關係，系統架構的關鍵是系統這個詞的定義，哪些東西組成了系統，這些東西之間的相互關係如何，是如何作用的，這些描述就定義了系統架構；解決方案架構不過是指乙個解決方案的組成部分及其相互之間的關係罷了；企業架構這個我倒覺得是個非常重要的東西，按照TOGAF裡的劃分的話它還可以分為業務架構、技術架構和IT架構（大致是這樣，具體不是記得很清楚了）等，我覺得它對乙個組織的資訊化建設是非常有用的東西，起著指導性作用，許多組織的資訊化重複建設就是由於缺乏企業架構理論的支撐而造成的。總而言之，架構我認為是綱領性的東西，是所謂的1000 feet bird's eye-view，描述了多個組成部分及其相互之間的關係和相互作用，這些組成部分又根據你的檢視角度或者層次的不同而不同。
在軟體開發中，經常說系統的架構，所謂搭架構的目的僅僅是為了系統的擴充套件性，對效能有多大幫忙？
犧牲效能來換取可維護性的前提是你得有足夠的效能，現在的架構放到二十多年前的機器上，絕對完蛋。我們現在說架構是開發效率和執行效率的權衡，那是因為計算資源不是那麼吃緊。要是在早期，權衡個蛋，能跑起來的程式那都是最好的。你可能不知道，最早的程式都是使用goto跳來跳去，後來才有了設計模式 vm等拯救開發者...
看軟體架構方面的書，看不懂，怎麼破？
Alex Zhao 這個問題一般最常見的原因是你沒有理解書裡講述的內容所想要解決的問題。每一項技術都有自己特定的目標，如果你不理解目標，即便你把這個技術相關的資料全部背下來，你也很難說自己掌握了這項技術。具體以常見的應用程式級的framework為例 如果你沒有進行過大中型軟體的開發，你就很難對大量...
分布式 微服務架構怎麼解決不同版本之間的問題？
swxlion 帶版本號是一種方法，更常見的是更換接入網域名稱。比如舊版訪問的是 http api.example.com，新版就改為 http apiv1.example.com。第三種就是雙介面。新版服務為了相容舊版，同時提供舊版的介面。這種方式比帶版本號更常見一點。但帶來的是雙倍介面，雙倍工作...