https://blog.csdn.net/nnsword/article/details/62228503.面試
邏輯架構：關注功能。不只包括用戶可見的功能，也包括一些基礎模塊以及輔助模塊。數據庫
開發架構：關注程序包，不只包括要編寫的程序，還包括能夠直接使用的第三方SDK或者現成的框架、類庫以及開發的系統將運行於其上的系統軟件或者中間件。設計模式
運行架構：關注進程、線程、對象等運行時概念，以及相關的併發、同步、通訊等問題。
物理架構：關注‘目標程序及其依賴的運行庫和系統軟件’最終如何安裝或部署到物理機器，以及如何部署機器和網絡來配合軟件系統的可靠性、可伸縮性等要求。
數據架構：關注持久化數據的存儲方案，不只包括實體及其實體關係的數據存儲格式，還包括數據傳遞、數據複製和數據同步等策略。
運行架構和開發架構的關係：開發架構通常偏重於程序包在編譯時期的靜態依賴關係，而這些程序運行起來後會表現爲對象、線程、進程，運行架構比較關注這些運行時單元的交互問題。
物理結構和運行架構的關係：運行架構特別關注目標程序的動態執行狀況，而物理架構重視目標程序的靜態位置問題；物理架構還要考慮軟件系統和包括硬件在內的整個IT系統之間是如何相互影響的。安全
數據架構和物理架構的關係：對於不少集成系統，數據須要在不一樣系統之間的傳遞、複製和暫存，這每每要涉及到不一樣的物理機器。服務器
五種架構視圖的關注點各有側重。邏輯架構側重功能需求；開發架構側重開發期間質量屬性；運行架構側重運行期質量屬性；物理架構側重安裝和部署需求；數據架構側重數據需求。網絡
兩個問題：
多個架構視圖之間的同步問題
不一樣的軟件架構視圖之間不是獨立的，它們分別從不一樣的角度反映了一個軟件系統的特性，因此之友它們合在一塊兒時，纔是一個完整的軟件系統，因此須要保持各個視圖之間是相互解釋的，而不是相互矛盾的。架構
架構視圖的數量問題
忌諱爲了架構而架構，不是全部類型的軟件系統都須要全部的5個視圖。例如對於不涉及到數據存儲的系統，那麼是不須要數據架構的；對於單機版的系統，不涉及到分佈式的需求，那麼物理架構相對來講也比較簡單。
--------------------- 併發
==框架
軟件架構設計-五視圖方法論
https://blog.csdn.net/nnsword/article/details/78109126分佈式
在實際工做中，咱們常常聽到「架構」和「架構師」這樣的名詞，並不新鮮，可是總讓不少剛入門的人感受很神祕，甚至是高深莫測。不多有人對「架構」有全面的瞭解和認識能並說清楚架構是什麼，更談不上掌握了。事實上，也只有極少數人能成爲或者被冠以「架構師」這樣的title。爲此，筆者總結了對架構的一些理解，但願可以補充不少初入門的人在這方面認識上的不足，糾正一些誤解。高手和老鳥就直接跳過吧。
架構的分類
對於「架構」來說，理論上劃分了5種架構視圖，分別是：邏輯架構、開發架構、運行架構、物理架構、數據架構。根據名字，你們均可能大概能猜到其側重點和含義。這裏先用通俗的文字簡單介紹下，便於你們理解，你們能夠沒必要糾結概念和這些理論。
邏輯架構：邏輯架構關注的是功能，包含用戶直接可見的功能，還有系統中隱含的功能。或者更加通俗來描述，邏輯架構更偏向咱們平常所理解的「分層」，把一個項目分爲「表示層、業務邏輯層、數據訪問層」這樣經典的「三層架構」。
開發架構：開發架構則更關注程序包，不只僅是咱們本身寫的程序，還包括應用程序依賴的SDK、第三方類庫、中間價等。尤爲是像目前主流的Java、.NET等依靠虛擬機的語言和平臺，以及主流的基於數據庫的應用，都會比較關注。和邏輯架構有緊密的關聯。
運行架構：顧名思義，更關注的是應用程序運行中可能出現的一些問題。例如併發帶來的問題，比較常見的「線程同步」問題、死鎖問題、對象建立和銷燬（生命週期管理）問題等等。開發架構，更關注的是飛機起飛以前的一些準備工做，在靜止狀態下就能規劃好作好的，而運行架構，更多考慮的是飛機起飛以後可能發生的一些問題。
物理架構：物理架構，更關注的系統、網絡、服務器等基礎設施。例如：如何經過服務器部署和配置網絡環境，來實現應用程序的「可伸縮性、高可用性」。或者舉一個實際的例子，如何經過設計基礎設施的架構，來保障網站能支持同時10W人在線、7*24小時提供服務，當超過10W人或者低於10W人在線時，能夠很方便的調整部署架構來支撐。
數據架構：數據架構，更關注的是數據持久化和存儲層面的問題，也可能會包括數據的分佈、複製、同步等問題。更貼切來說，如何選擇須要的關係型數據庫、流行的NOSQL，如何保障數據存儲層面的性能、高可用性、災備等等。不少時候，和物理架構是有緊密聯繫的，但它更關注數據存儲層面的，物理架構更關注整個基礎設施部署層面。
上面講了那麼多，相信國內不多有公司是嚴格按照這五種視圖去分工和設計的。其實在筆者眼中，架構大體分爲兩種：軟件架構、系統架構。前三種視圖，能夠概括爲軟件架構，然後兩種架構，則歸爲系統架構。這也比較符合國內大部分中小型互聯網公司的現狀。
根據應用特性的不一樣，關注側重點可能不一樣。例如，某些門戶類的互聯網應用，讀多寫少並且業務相對比較簡單，則更加關注「高性能、可伸縮性、可用性」等方面。對於更加複雜的應用，例如電商類大規模交易型的應用，對每一個層面和每一個環節都會比較關注。對於業務型的系統，例如一些生產型企業使用的ERP，或者僅供企業內部使用的一些MIS、OA應用，一般更關注功能和複雜的業務和實現和擴展，而對性能等方面又可能不要過高，這類應用則更關注純軟件架構層面。這裏，不展開作具體討論。因此不少時候，架構師也須要是一個團隊，而不是一我的「全棧」。
架構設計究竟是什麼
在長期的技術招聘面試中，我發如今不少人眼中，架構就是分層，架構設計就是「三層架構」（或者四層、五層…反正分層越多就說明項目越複雜並且架構就越牛），或許是受到諸如PetShop之類的示例項目的影響，這裏暫時不去追究緣由了。
以前已經糾正過不少人的誤解-架構不僅是軟件架構。說一下通俗點的理解：
軟件架構就是實用並且優雅的設計，它不在於分多少層，或者應用了多少種設計模式/架構模式等。它應該是以知足實現用戶需求爲前提，以開發人員廣泛可接受爲根本的，並且要符合系統特性和業務發展須要的，從軟件設計的角度，可以達到層次清晰、可維護、可重用、可擴展…就很是優秀了，無需刻意去糾結分了多少層，是否使用了什麼模式，有多麼抽象等。以面向對象設計爲例，基本目標是「高內聚、低耦合」，爲此咱們可能會遵循一些常見的設計原則（例如經典的SOLID設計原則）。最後糾正一點，一般咱們所說的模式，其實又分爲不少種，並非僅僅指的是「設計模式」（設計模式也有千千萬，並非只有常見的GOF 23種設計模式）。一般包括：企業架構模式、設計模式、SOA模式、企業集成模式等等。
強調一下，架構要講求「實用」，並且開發人員廣泛可接受，要符合現狀的。不然，再「優雅」的設計，都會淪爲高成本的「花架子」，生搬硬套和過分設計只會讓項目「流產」。
因爲角色和分工不一樣,軟件架構是一個複雜的總體，軟件架構工程師不可能在一個視角、一會兒講清楚，而利用多重軟件架構視圖的方法，能夠一次只圍繞少數概念和技術展開，分別着重研究軟件架構的不一樣方面，使問題得以清晰公和簡化，利於軟件架構工程師完成架構設計工做。
所以軟件架構的每一個視圖分別關注不一樣的方面，針對不一樣的目標和用途。目前經常使用架構設計五視圖方法進行軟件架構描述。它們分別是邏輯架構、開發架構、運行架構、物理架構和數據架構。
邏輯架構的設計着重考慮功能需求，系統應當向用戶提供什麼樣的服務，關注點主要是行爲或職責的劃分。邏輯架構關注的功能，不只包括用戶可見的功能，還應當包括爲實現用戶功能而必須提供的輔助功能。邏輯架構的靜態方面是抽象職責的劃分，動態方面是承擔不一樣職責的邏輯單元之間的交互與協做。
開發架構的設計着重考慮開發期質量屬性，關注點是在軟件開發環境中軟件模塊（包）的實際組織方式，具體涉及源程序文件、配置文件、源程序包、編譯打包後的目標文件、直接使用的第三方SDK/框架/類庫、以及開發的系統將運行於其上的系統軟件或中間件。
運行架構的設計着重考慮運行期質量屬性，關注點是系統的併發、同步、通訊等問題，這勢必涉及到進程、線程、對象等運行時概念，以及相關的併發、同步、通訊等。運行架構的靜態方面關注軟件系統運行時的單元結構，動態方面關注運行時單元之間的交互機制。
物理架構的設計着重考慮安裝和部署需求，關注點是目標程序及其依賴的運行庫和系統軟件最終如何安裝或部署到物理機器，以及如何部署機器和網絡來配合軟件系統的可靠性、可伸縮性、持續可用性、性能和安全性等要求。
數據架構的設計着重考慮數據需求，關注點是持久化數據的存儲方案，不只包括實體及實體關係數據存儲格式，還可能包括數據傳遞、數據複製、數據同步等策略。
在運用五視圖方法進行架構設計時須要注意兩個方面的問題：一是多個架構視圖間的同步問題，也就是必須保證不一樣視圖之間是互相解釋而不是相互矛盾的；另外一個是架構視圖的數量問題，原則上是軟件系統不涉及某方面的要求時就不須要該方面的視圖，嚴格控制架構視圖的數量，但若是有須要，能夠引入新的架構視圖，從而更加突出和明確地制定和表達特定方面的架構決策，如安全性。
構成每一個架構設計視圖的元素不一樣，這些不一樣的元素撐起不一樣的思惟空間，從而使每一個架構視圖重點覆蓋不一樣種類的需求，最終全部架構設計視圖所表達的語義綜合左右一塊兒，就構成了軟件架構設計方案。
---------------------