什麼是技術架構

1. 業務架構，功能架構，系統架構，技術架構，應用架構都是什麼關系

• 架構

  是有關軟體整體結構與組件的抽象描述，用於指導大型軟體系統各個方面的設計。

• 系統架構

  是對已確定的需求的技術實現構架、作好規劃,運用成套、完整的工具,在規劃的步驟下去完成任務。

• 技術架構

  通過合理的完善的評估途徑對組織、網路、程序的組成框架、模型進行評價和分析,並對其進行完善。

• 應用架構

  以架構圖的方式描述系統的組成和框架，一般從系統功能和系統技術層次兩個架構視角進行設計。

2. 技術架構都包括什麼

對於技術人員來說，「架構」是一個再常見不過的詞了：我們會給新員工介紹整個系統的架構，參加架構設計評審，學習業界開源系統（例如，MySQL、Hadoop）的架構，研究大公司的架構實現（例如，微信架構、淘寶架構）……雖然如此常見，但如果深究一下「架構」到底指什麼，大部分人不一定能夠准確地回答。例如：
Linux有架構，MySQL有架構，JVM也有架構，使用Java開發、MySQL存儲、跑在Linux上的業務系統也有架構，應該關注哪個架構呢？

微信有架構，微信的登錄系統也有架構，微信的支付系統也有架構，當我們談微信架構時，到底在談什麼架構？

要想准確地回答以上問題，關鍵在於梳理幾個有關系而又相似的概念，包括系統、子系統、模塊、組件、框架和架構。

1、軟體模塊（Mole）是一套一致且互相有緊密關聯的軟體組織，它包含程序和數據結構兩部分。現代軟體開發往往利用模塊作為合成的單位。 

模塊的介面表達了由該模塊提供的功能和調用它時所需的元素。 

模塊是可能分開被編寫的單位，這使得它們可再用，並允許開發人員同時協作、編寫及研究不同的模塊。

2、軟體框架（Software Framework）通常指的是為了實現某個業界標准或完成特定基本任務的軟體組件規范，也指為了實現某個軟體組件規范時，提供規范所要求之基礎功能的軟體產品。

3、軟體架構是指軟體系統的「基礎結構」，創造這些基礎結構的准則，以及對這些結構的描述。
單純從定義的角度來看，框架和架構的區別還是比較明顯的，框架關注的是「規范」，架構關注的是「結構」。框架的英文是Framework，架構的英文是Architecture。Spring MVC的英文文檔標題就是「Web MVC Framework」。
系統泛指由一群有關聯的個體組成，根據某種規則運作，能完成個別元件不能單獨完成的工作的群體。它的意思是「總體」「整體」或「聯盟」。

3. Java的有幾種技術架構

Java架構：

軟體架構作為一個概念，體現在技術和業務兩個方面。
從技術角度來說：軟體架構隨著技術的革新不斷地更新其內容，軟體架構建立於當前技術和一些基本原則的基礎之上。
先說一些基本原則：
分層原則：分層是為了降低軟體深度復雜性而使用的關鍵思想，就像社會有了階級一樣，軟體有了層次結構。
模塊化原則：模塊化是化解軟體廣度復雜的必然手段，模塊化的目的就是讓軟體分工。
介面實現分離原則隨著軟體模塊化的不斷深入改進，面向介面編程而不是面向實現編程可以讓復雜度日趨增高的軟體降低模塊之間的耦合度，從而讓各模塊更輕松改進。從這個原則出發，軟體也從微觀進行了細致的規范化。
還有兩個比較小但很重要的原則：
細節隱藏原則很顯然把復雜問題簡化，把難看的細節隱去，能讓軟體結構更清晰。其實這個原則使用很普遍，java/c++語言中的封裝原則以及設計模式中的Facade（外觀）模式就很能體現這個原則的精神。
依賴倒置原則隨著軟體結構的進一步發展,層與層之間、模塊與模塊之間的依賴逐漸加深，而層、模塊的動態可插拔要求不端增大。依賴倒置原則可看視為介面實現分離原則的深化，根據此原則的精神，軟體進入了工具時代。這個原則有點類似於知名的好萊塢法則：Don't call us, we'll call you。

以上這些原則奠定了我們的軟體架構的價值指標。但軟體架構畢竟是建立在當前技術之上的。而每一代技術都有架構模式。過去的不再說了，讓我們現在就來看一下當前流行的技術，以及當前我們能採用的架構。

因為面向對象是當前最流行開發技術，且設計模式的大量使用使面向對象的走向成熟，而資料庫是當前最有效的存儲結構、web界面是當前最流行的用戶介面，所以當前最典型的三層次架構就架構在以上幾項技術的基礎之上，用資料庫作存儲層、用面向對象來實現業務層、用web來作為用戶介面層。我們從三層次架構談起：
因為面向對象技術和資料庫技術不適配，所以在標准三層次架構的基礎上，我們增加了數據持久層，來管理O-R雙向映射，但目前一直沒有最理想的實現技術。cmp和entity bean技術因為其實現復雜，功能前景有限，已接近被淘汰的邊緣。JDO及hibernate作為o-r映射的後期之秀，尤其是hibernate，功能相當完備。推薦作為持久層的首選
在業務層,因為當前業務日趨負載，且變動頻繁，所以我們必須有足夠敏捷的技術來保證我們的適應變化的能力，在標准j2ee系統中session bean負責業務處理，且有不錯的性能表現，但採用ejb系統對業務架構模式改變太大，且其復雜而昂貴，業務代碼移植性差。而spring 作為一個bean配置的輕量級架構，漂亮的IOC模式實現，對業務架構影響小，所以推薦作為中間層業務框架。
在用戶結構層,雖然servlet/jsp/jstl/javaBean 能夠實現MVC架構,但終究過於粗糙。struts對MVC架構的實現就比較完美，Taperstry也極好地實現MVC架構，且採用基於事件的方式，非常誘人，惜其不夠成熟，我們仍舊推薦struts作為用戶介面層基礎架構。
因為業務層是三層次架構中最有決定意義的，所以讓我們回到業務層細致地分析一下，在復雜的業務我們常常需要以下基礎服務的一種或幾種：事務一致性服務acid(tool:jta/jts)、並發加鎖服務concurrent&&lock、池化管理服務cache、訪問控制服務(tool:jaas)、流程式控制制服務workflow、動態實現服務IOC，串列化消息服務(tool:jms)、負載平衡服務blance等。如果我們不採用重量級應用伺服器(如weblogic,websphere,jboss等)及重量級組件(EJB)，我們必須自己實現其中一些服務。雖然我們大多情況下，不需要所有這些服務，但實現起來卻非易事。幸運的是我們有大量的開源實現代碼,但採用開源代碼卻常常是件不輕松的事。

隨著xml作為結構化信息傳輸和存儲地位日漸重要,一些xml文檔操作工具(DOM,Digester,SAX等)的使用愈發重要,而隨著xml schema的java binding工具(jaxb,xmlbean等)工具的成熟，採用xml schema來設計xml文檔格式,然後採用java binding來生成java bean 會成為主要編程模式,而這又進一步使數據中心向xml轉移,使在中小數據量上,愈發傾向於以xquery為查詢語言的xml資料庫。最近還有一個趨勢,microsoft,ibm等紛紛大量開發中間軟體如(microsoft office之infopath)，可以直接從xml schema 生成 錄入頁面等非常實用的功能。還有web service 的廣泛應用，都將對軟體的架構有非常重大的影響。至於面向服務架構(SOA)前景如何，三層次架構什麼時候走入歷史，現在還很難定論。

aop的發展也會對軟體架構有很深的影響，但在面向對象架構里，無論aspectJ還是jboss-aop抑是aspectWerks、nanning都有其自身的嚴重問題:維護性很差,所以說它將很難走遠。也許作為一個很好的思想，它將在web service里大展身手。

rdf,owl作為w3c語義模型的標志性的語言,也很難想像能在當前業務架構發揮太大影響。但如果真如它所聲稱那樣，廣泛地改變著信息的結構。那麼對軟體架構也會有深遠影響。

有關架構設計的一些忠告：
盡量建立完整的持久對象層.可獲得高回報
盡量將各功能分層,分塊,每一模塊均依賴假定的其它模塊的外觀
不能依賴靜態數據來實現IOC模式，應該依賴數據特徵介面，靜態數據僅是數據特徵介面實現方式之一
架構設計時xml是支持而不是依賴.但可以提供單一的xml版本的實現

從業務角度說：軟體架構應是深刻體現業務內部規則的業務架構，但因為業務變化頻紝，所以軟體架構很難保持恆定不變，但業務的頻繁變化不應是軟體架構大規模頻繁變化的原因，軟體架構應是基於變化的架構。
一種業務有其在一段時間內穩定存在的理由(暫且不談)，業務內部有許多用例，每一種用例都有固定的規則，每一規則都有一些可供判定的項，每一項從某一維度來觀察都是可測量的，我們的架構首先必須保證完美適應每一項每一種測量方式，很多失敗的架構都是因為很多項的測量方式都發生變更這種微觀變化中。

每個用例都有規則，我們在作業務用例分析，常常假定一些規則是先驗的，持久穩定的，然而後來的業務改變常常又證明這種看法是錯誤的，然而常常我們的架構已經為之付出了不可挽回的代價。大量事實證明：規則的變化常常用例變化的根本原因。所以我們的架構要盡可能適應規則的變化，盡可能建立規則模版。

每個用例都關系著不同的角色。每一個用例的產生都必然是因為角色的變更（注意：不是替換，而是增強或減弱），所以注意角色的各種可能情況，對架構的設計有舉足輕重的意義。在我們當前的三層架構里，角色完美地對應介面概念。

在一個系統里很多用例都相互關聯,考慮到每個用例均有可能有不同的特例，所以在架構設計中，盡量採用依賴倒置原則。如架構許可可採用消息通信模式(JMS)。這樣可降低耦合度。

現在我們談一下業務穩定存在理由對業務的影響。存在即是合理，在這里當然是正確的。業務因人而存在，所以問業務存在的理由即是問不同角色的需要這項業務的理由以及喜歡不喜歡當前業務用例的理由，所有這樣的角色都應該在系統里預留。《待續》
在架構設計中有幾個原則可以考慮：
用例盡量細分
用例盡量抽象
角色盡量獨立
項測量獨立原則
追求簡單性
這里未提供相關的例子，例子會在以後的更新時提供。

業務和模式之間的關系
業務中的一些用例之間的關系常常和一些常規的模式很相似。但隨著時間的演化，慢慢地和先前的模式有了分歧。這是個正常的現象。但這對系統架構卻要求非常高，要求系統架構能適應一些模式的更替。在這里我們盡可能早地注意到用例之間的相互角色變化，為架構更新做好准備.

4. 什麼是企業技術架構

建議初學者閱讀「編程規則」，資深者閱讀「軟體之道」 最近看了幾本關於架構的書籍，看來架構做為一個概念和體系還很年輕，還不是很清晰。 首先架構的概念太寬泛，各領域都有架構的概念，僅就軟體領域而言，也包括： 業務架構、應用架構、技術架構、數據架構等。 本文僅就技術架構而言，有認為架構只是過程而非結果的，有認為架構只是圖表的，有認為架構是路線和思想的。我認為這只是概念層的架構，實在的、落地的、具體的、科學的架構才是美麗的架構，否則只是「浮雲」啊。 因此我認為：架構是支持某種類型軟體運行的虛擬機和構建器。參考：「應用架構的特徵」、「平台之美」 架構不是面向具體功能的，而是面向全部需求的需求(元需求)，關注設計的設計（元設計），解決開發之共性，簡化開發之過程，提供應用之舞台，可謂應用之母也。 架構是體系化的，完備的，能夠滿足一類軟體全部元需求的運行平台和構建平台，具體功能運行於其上，可以做到一通百通。 我預言：未來二十年將是各類架構平台軟體誕生並逐步成熟的年代。它將逐步超過資料庫、中間件的軟體市場份額。 下面給出一個富客戶端企業技術架構的簡圖供參考： 一般架構為三層，即表示層，領域層和數據層，但真實的企業級軟體架構要求更細致，領域層會進一步分解為中台和後台，中台會實現諸多企業級應用系統的元需求，如：文件傳輸、消息發布、錄入復核、工作流轉、運行監控等非業務性需求。 虛擬AE層實現架構與具體技術的隔離，這是保障應用不受具體技術環境影響的重要設計。 參閱：軟體領域十大命題 有朋友希望推薦架構方面的書，我在這里回答一下，首先如果你搞開發不滿3年，建議你先不要研究架構，認真學習一下「代碼整潔之道」或「編程規則」（該文就借鑒了許多該書的觀點），這對你成長為架構師會有幫助，能夠寫出結構優美的代碼是成為架構是的第一步。 另外，架構師需要很綜合的能力，要了解軟體、硬體、網路、資料庫、中間件、工作流等的基本原理，欣賞繪畫、閱讀歷史、研究哲學，這樣你才能夠逐步具備進行企業級應用架構設計的能力，學習一下「系統架構設計師教程」也是不錯的選擇。 事實上，在許多國際水準的軟體企業，有10年開發經驗的，才有資格進入產品開發部，有15年經驗才允許做架構層面的設計，但在我國10年還在搞開發的人幾乎不存在了，10年如果還在搞開發會被很多人認為是沒出息的！這幾乎形成了一種文化，這應該給我們深刻的啟發和反省。 目前「架構」還很年輕，概念還比較亂，確切地說還沒有很好的書籍（有些書籍甚至會誤導你，書不是看的越多越好，一定要選擇，要看經典，「人月神話」、「人件」一定要看，不過「人件」讀起來比較澀，你可以參考我為此書寫的精簡版，你最好把它推薦給你的老闆，讓他明白軟體開發人員是智力工作者，不是「碼工」）。「架構之美」並沒有名字那麼美，尤其不要被前面幾位寫推薦序的忽悠了，該書1~30頁是值得認真閱讀的。

5. 智能體的技術架構是什麼

智能體包括四層架構——智能交互、智能聯接、智能中樞和智慧應用。
「智能交互」核心技術是邊雲協同操作系統IEF，可內置於華為各合作夥伴的設備中，讓這些設備成為華為雲的智能邊緣，從而實現智能按需部署。
「智能聯接」就是智能體的「軀干」，它通過5G、F5G、Wi-Fi6等物理聯接提供泛在千兆、確定性體驗和超自動化的網路，實現無縫覆蓋，萬物互聯，以及雲網協同、應用協同、數據協同和組織協同。
「智能中樞」相當於是智能體的「大腦和決策系統」，它基於雲基礎設施，賦能應用、使能數據、普惠AI，更好地支撐全場景智慧應用。
「智慧應用」則是智能體的價值呈現，華為通過與客戶、夥伴協同創新，加速ICT技術與行業知識的深度融合，重構體驗、優化流程、使能創新。

6. 技術架構和架構設計有什麼區別

目前國內對「架構」這個詞的使用很混亂。在很多方面、很多層次都可以用「架構」這個詞。

你最好弄清楚，這個圖是干什麼的，用來表現什麼意圖的內容，在來說這個事。

從字面上解釋，技術架構，就是實現某個信息系統所有使用技術的整體展現。架構設計就是干這個的。

7. OA是什麼技術架構

和IBM的隨需應變要表達的作用是一樣的，就是可以按照需求自己配置業務模塊，讓信息系統隨時滿足業務變化的需要。只是具體的應用不同。華天動力指在協同辦公系統上的變化，IBM好像概念更大一些，包括整體解決方案。

1、開放平台——魔方架構

華天動力OA採用J2EE+SOA+MVC+WebService技術，以框架+組件的體系構成一個「魔方架構」，為用戶提供了完全開放的應用平台：

1）多資料庫、多操作系統、多語言、多界面風格一鍵切換，無需代碼級操作；

2）用戶可以在平台上自己搭建各種新的業務模塊，無需代碼級操作；

3）可完美整合第三方業務系統，實現數據交換和共享，消除信息孤島；

4）可根據用戶需求實現敏捷開發和動態部署，最大限度的降低開發周期和費用；

5）使OA成為一個可生長的協同辦公平台，動態適應未來的升級和變化，保證企業的長期投資價值。

2、工作流引擎——隨需應變

華天動力的工作流並非只限於審批流程，而是BPM（流程管理），是一個開放的業務建模工具，意味著你可以用這個工作流引擎去搭建新的業務系統，做到隨需應變：

6）純瀏覽器圖形化流程設計，通過拖拉方式實現工作流的編輯；

7）人工節點和系統節點相結合，自由流程和固定流程相結合，可以設計出任何復雜的工作流；

8）可以按數值、時間、崗位、許可權等各種設置進行條件跳轉，分流或合流；

9）一張審批單可適用全單位，無需對不同部門重復設計多個表單的流程；

10）具有靈活的崗位和角色設置，支持一人多崗、固定崗位、相對崗位等，大大減少流程設置的數量；

11）靈活的工作流定義，輕松搭建基於工作流的業務管理系統，只需在界面進行設置，無需代碼級操作。

3、智能報表——決策支持

12）國內最強的報表系統，可以輕松自定義各種類型的表單和報表格式；

13）可以設置表單任何區域和欄位的讀寫許可權，使用更安全；

14）在建立表單的時候，可以自動生成一對一，一對多的明細表，實現對不同明細表的統計匯總；

15）隨意提取多個審批後表單的數據，進行各種形式的統計匯總，生成各種統計視圖，實現對流程單據內容分視圖查詢，可對審批單據做出各類報表；

16）可以自定義與第三方系統的數據整合，實現在OA平台上對其它業務數據的展示，為領導者提供決策支持。

8. 萬物互聯是三層技術架構以及關鍵技術是什麼

萬物互聯（IoE）定義為將人，流程，數據和事物結合一起使得網路連接變得更加相關，更有價值。萬物互聯將信息轉化為行動，給企業，個人和國家創造新的功能，並帶來更加豐富的體驗和前所未有的經濟發展機遇。

3個關鍵技術輕松助力物聯網實現萬物互聯

1、RFID技術(利用無線電訊號感知監測目標並進行數據的記錄）

2、WiFi技術是物聯網技術應用的基礎

3、感測網技術是物聯網技術的核心

9. 什麼是系統架構設計

簡單一點，系統架構設計就是一個系統的草圖，描述了構成系統的抽象組件，以及各個組件之間的是如何進行通訊的，這些組件在實現過程中可以被細化為實際的組件比如類或者對象。在面向對象領域中，組件之間的聯通通常面向於介面實現的。

是人們對一個結構內的元素及元素間關系的一種主觀映射的產物。架構設計是一系列相關的抽象模式，用於指導大型軟體系統各個方面的設計。

「架構」一詞最早來自建築學，原意為建築物設計和建造的藝術。但是在軟體工程領域，軟體架構不是一個新名詞，只是在早期的著作中人們將軟體架構稱為軟體體系架構。這就是架構的概念。所謂架構，就是人們對一個結構內的元素及元素間關系的一種主觀影射的產物。

無論何種系統架構應用領域，目的都是一樣的，即完整地、高一致性的、平衡各種利弊的、有技術和市場前瞻性的設計系統和實施系統。

(9)什麼是技術架構擴展閱讀

系統架構的主要任務是界定系統級的功能與非功能要求、規劃要設計的整體系統的特徵、規劃並設計實現系統級的各項要求的手段，同時利用各種學科技術完成子系統的結構構建。

在系統架構中，由於對軟體越來越深入的依賴，軟體架構的任務也體現出重要的作用。而且系統架構與軟體架構是緊密聯系和相互依賴的。

1997年，Eberhadrt Rechtin 與MarkW Maier 在其論著中，為計算機科學總結了系統架構方面的實踐成果，從而奠定了系統科學和系統架構在計算機科學中的基石。

10. 系統架構 技術構架 應用構架 區別

系統架構、技術構架、應用構架區別為：目的不同、實現方式不同、特點不同。

一、目的不同

1、系統架構：系統架構是對已確定的需求的技術實現構架、作好規劃，運用成套、完整的工具，在規劃的步驟下去完成任務。

2、技術構架：技術構架是對整個或部分技術系統的可重用設計的構架。

3、應用構架：應用構架是描述了IT系統功能和技術實現內容的構架。

二、實現方式不同

1、系統架構：系統架構通過規劃程序的運行模式、層次結構、調用關系來具體實現架構。

2、技術構架：技術構架通過一組抽象構件及構件實例間交互的方法來具體實現架構。

3、應用構架：應用構架通過架構圖的方式來具體實現架構。

三、特點不同

1、系統架構：系統架構特點是確定一台計算機硬體和軟體之間的銜接。

2、技術構架：技術構架特點是可被技術開發者定製的應用骨架。

3、應用構架：應用構架特點是承接了企業戰略發展方向和業務模式，規劃和指導企業各個IT系統的定位和功能。

參考資料來源：

網路——系統構架

網路——技術框架

網路——應用架構