A. 技術架構都包括什麼
對於技術人員來說，「架構」是一個再常見不過的詞了：我們會給新員工介紹整個系統的架構，參加架構設計評審，學習業界開源系統（例如，MySQL、Hadoop）的架構，研究大公司的架構實現（例如，微信架構、淘寶架構）……雖然如此常見，但如果深究一下「架構」到底指什麼，大部分人不一定能夠准確地回答。例如：
Linux有架構，MySQL有架構，JVM也有架構，使用Java開發、MySQL存儲、跑在Linux上的業務系統也有架構，應該關注哪個架構呢？
微信有架構，微信的登錄系統也有架構，微信的支付系統也有架構，當我們談微信架構時，到底在談什麼架構？
要想准確地回答以上問題，關鍵在於梳理幾個有關系而又相似的概念，包括系統、子系統、模塊、組件、框架和架構。
1、軟體模塊（Mole）是一套一致且互相有緊密關聯的軟體組織，它包含程序和數據結構兩部分。現代軟體開發往往利用模塊作為合成的單位。
模塊的介面表達了由該模塊提供的功能和調用它時所需的元素。
模塊是可能分開被編寫的單位，這使得它們可再用，並允許開發人員同時協作、編寫及研究不同的模塊。
2、軟體框架（Software Framework）通常指的是為了實現某個業界標准或完成特定基本任務的軟體組件規范，也指為了實現某個軟體組件規范時，提供規范所要求之基礎功能的軟體產品。
3、軟體架構是指軟體系統的「基礎結構」，創造這些基礎結構的准則，以及對這些結構的描述。
單純從定義的角度來看，框架和架構的區別還是比較明顯的，框架關注的是「規范」，架構關注的是「結構」。框架的英文是Framework，架構的英文是Architecture。Spring MVC的英文文檔標題就是「Web MVC Framework」。
系統泛指由一群有關聯的個體組成，根據某種規則運作，能完成個別元件不能單獨完成的工作的群體。它的意思是「總體」「整體」或「聯盟」。
B. 系統架構 技術構架 應用構架 區別
系統架構、技術構架、應用構架區別為：目的不同、實現方式不同、特點不同。
一、目的不同
1、系統架構：系統架構是對已確定的需求的技術實現構架、作好規劃，運用成套、完整的工具，在規劃的步驟下去完成任務。
2、技術構架：技術構架是對整個或部分技術系統的可重用設計的構架。
3、應用構架：應用構架是描述了IT系統功能和技術實現內容的構架。
二、實現方式不同
1、系統架構：系統架構通過規劃程序的運行模式、層次結構、調用關系來具體實現架構。
2、技術構架：技術構架通過一組抽象構件及構件實例間交互的方法來具體實現架構。
3、應用構架：應用構架通過架構圖的方式來具體實現架構。
三、特點不同
1、系統架構：系統架構特點是確定一台計算機硬體和軟體之間的銜接。
2、技術構架：技術構架特點是可被技術開發者定製的應用骨架。
3、應用構架：應用構架特點是承接了企業戰略發展方向和業務模式，規劃和指導企業各個IT系統的定位和功能。
參考資料來源：
網路——系統構架
網路——技術框架
網路——應用架構
C. 業務架構，功能架構，系統架構，技術架構，應用架構都是什麼關系
業務架構說明的是商業組織和流程，主語是組織和人，句子都是做什麼業務，輸出什麼。
功能架構說明的是IT系統將流程裡面某些任務自動化，主語都是系統，比如系統前端呈現什麼，系統後台處理什麼，羅列了系統里的功能。
系統架構說明的是IT系統由什麼硬體軟體模塊來實現，比如有數據層，處理層，Web前端，微信前端等；有的系統架構也包含部署架構：比如資料庫跑在一台機子上。
技術架構的定義比較寬泛，按你的問題，往小裡面考慮，就是我這個應用到底用什麼「軟體」技術來實現，比如Java的SSH？還是SSO？
應用架構，按你的問題，也要往小里說，可以說你應用里用了寫了寫什麼組件。比如爬蟲系統+內容管理系統+用戶前端=商業情報系統。
D. 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)。這樣可降低耦合度。
現在我們談一下業務穩定存在理由對業務的影響。存在即是合理，在這里當然是正確的。業務因人而存在，所以問業務存在的理由即是問不同角色的需要這項業務的理由以及喜歡不喜歡當前業務用例的理由，所有這樣的角色都應該在系統里預留。《待續》
在架構設計中有幾個原則可以考慮：
用例盡量細分
用例盡量抽象
角色盡量獨立
項測量獨立原則
追求簡單性
這里未提供相關的例子，例子會在以後的更新時提供。
業務和模式之間的關系
業務中的一些用例之間的關系常常和一些常規的模式很相似。但隨著時間的演化，慢慢地和先前的模式有了分歧。這是個正常的現象。但這對系統架構卻要求非常高，要求系統架構能適應一些模式的更替。在這里我們盡可能早地注意到用例之間的相互角色變化，為架構更新做好准備.
E. 萬物互聯是三層技術架構以及關鍵技術是什麼
萬物互聯（IoE）定義為將人，流程，數據和事物結合一起使得網路連接變得更加相關，更有價值。萬物互聯將信息轉化為行動，給企業，個人和國家創造新的功能，並帶來更加豐富的體驗和前所未有的經濟發展機遇。
3個關鍵技術輕松助力物聯網實現萬物互聯
1、RFID技術(利用無線電訊號感知監測目標並進行數據的記錄）
2、WiFi技術是物聯網技術應用的基礎
3、感測網技術是物聯網技術的核心
F. 什麼是企業技術架構
建議初學者閱讀「編程規則」，資深者閱讀「軟體之道」 最近看了幾本關於架構的書籍，看來架構做為一個概念和體系還很年輕，還不是很清晰。 首先架構的概念太寬泛，各領域都有架構的概念，僅就軟體領域而言，也包括： 業務架構、應用架構、技術架構、數據架構等。 本文僅就技術架構而言，有認為架構只是過程而非結果的，有認為架構只是圖表的，有認為架構是路線和思想的。我認為這只是概念層的架構，實在的、落地的、具體的、科學的架構才是美麗的架構，否則只是「浮雲」啊。 因此我認為：架構是支持某種類型軟體運行的虛擬機和構建器。參考：「應用架構的特徵」、「平台之美」 架構不是面向具體功能的，而是面向全部需求的需求(元需求)，關注設計的設計（元設計），解決開發之共性，簡化開發之過程，提供應用之舞台，可謂應用之母也。 架構是體系化的，完備的，能夠滿足一類軟體全部元需求的運行平台和構建平台，具體功能運行於其上，可以做到一通百通。 我預言：未來二十年將是各類架構平台軟體誕生並逐步成熟的年代。它將逐步超過資料庫、中間件的軟體市場份額。 下面給出一個富客戶端企業技術架構的簡圖供參考： 一般架構為三層，即表示層，領域層和數據層，但真實的企業級軟體架構要求更細致，領域層會進一步分解為中台和後台，中台會實現諸多企業級應用系統的元需求，如：文件傳輸、消息發布、錄入復核、工作流轉、運行監控等非業務性需求。 虛擬AE層實現架構與具體技術的隔離，這是保障應用不受具體技術環境影響的重要設計。 參閱：軟體領域十大命題 有朋友希望推薦架構方面的書，我在這里回答一下，首先如果你搞開發不滿3年，建議你先不要研究架構，認真學習一下「代碼整潔之道」或「編程規則」（該文就借鑒了許多該書的觀點），這對你成長為架構師會有幫助，能夠寫出結構優美的代碼是成為架構是的第一步。 另外，架構師需要很綜合的能力，要了解軟體、硬體、網路、資料庫、中間件、工作流等的基本原理，欣賞繪畫、閱讀歷史、研究哲學，這樣你才能夠逐步具備進行企業級應用架構設計的能力，學習一下「系統架構設計師教程」也是不錯的選擇。 事實上，在許多國際水準的軟體企業，有10年開發經驗的，才有資格進入產品開發部，有15年經驗才允許做架構層面的設計，但在我國10年還在搞開發的人幾乎不存在了，10年如果還在搞開發會被很多人認為是沒出息的！這幾乎形成了一種文化，這應該給我們深刻的啟發和反省。 目前「架構」還很年輕，概念還比較亂，確切地說還沒有很好的書籍（有些書籍甚至會誤導你，書不是看的越多越好，一定要選擇，要看經典，「人月神話」、「人件」一定要看，不過「人件」讀起來比較澀，你可以參考我為此書寫的精簡版，你最好把它推薦給你的老闆，讓他明白軟體開發人員是智力工作者，不是「碼工」）。「架構之美」並沒有名字那麼美，尤其不要被前面幾位寫推薦序的忽悠了，該書1~30頁是值得認真閱讀的。
G. 什麼是框架技術啊
技術框架（technological Framework）是整個或部分技術系統的可重用設計，表現為一組抽象構件及構件實例間交互的方法;另一種定義認為，技術框架是可被技術開發者定製的應用骨架。前者是從應用方面而後者是從目的方面給出的定義。
計算機方面：
1、計算機框架體系結構（ComputerArchitecture）是程序員所看到的計算機的屬性，即概念性結構與功能特性。按照計算機系統的多級層次結構，不同級程序員所看到的計算機具有不同的屬性。
2、一般來說，低級機器的屬性對於高層機器程序員基本是透明的，通常所說的計算機體系結構主要指機器語言級機器的系統結構。經典的關於「計算機體系結構（computerarchitecture）」的定義是1964年C.M.Amdahl在介紹IBM360系統時提出的，其具體描述為「計算機體系結構是程序員所看到的計算機的屬性，即概念性結構與功能特性」 。
H. 技術框架的介紹
技術框架（technological Framework）是整個或部分技術系統的可重用設計，表現為一組抽象構件及構件實例間交互的方法;另一種定義認為，技術框架是可被技術開發者定製的應用骨架。前者是從應用方面而後者是從目的方面給出的定義。
I. Java的技術架構有哪些
服務分離
隨著系統的的上線，用戶量也會逐步上升，很明顯一台伺服器已經滿足不了系統的負載，這時候，我們就要在伺服器還沒有超載的時候，提前做好准備。
由於我們是單體架構，優化架構在短時間內是不現實的，增加機器是一個不錯的選擇。這時候，我們可能要把應用和資料庫服務單獨部署，如果有條件也可以把文件伺服器單獨部署。
反向代理
為了提升服務處理能力，我們在Tomcat容器前加一個代理伺服器，我一般使用Nginx，當然你如果更熟悉apache也未嘗不可。
用戶的請求發送給反向代理，然後反向代理把請求轉發到後端的伺服器。
嚴格意義上來說，Nginx是屬於web伺服器，一般處理靜態html、css、js請求，而Tomcat屬於web容器，專門處理JSP請求，當然Tomcat也是支持html的，只是效果沒Nginx好而已。
反向代理的優勢，如下：
隱藏真實後端服務
負載均衡集群
高可用集群
緩存靜態內容實現動靜分離
安全限流
靜態文件壓縮
解決多個服務跨域問題
合並靜態請求(HTTP/2.0後已經被弱化)
防火牆
SSL以及http2
服務發現——Netflix Eureka
客服端負載均衡——Netflix Ribbon
斷路器——Netflix Hystrix
服務網關——Netflix Zuul
分布式配置——Spring Cloud Config
同步通信和非同步通信
遠程調用RPC
REST
消息隊列
DNS負載均衡，一般域名注冊商的dns伺服器不支持，但博主用的阿里雲解析已經支持
四層負載均衡(F5、LVS)，工作在TCP協議下
七層負載均衡(Nginx、haproxy)，工作在Http協議下
基於資料庫的Session共享
基於resin/tomcat web容器本身的session復制機制
基於oscache/Redis/memcached 進行 session 共享。
基於cookie 進行session共享
Session Replication 方式管理 (即session復制)
簡介：將一台機器上的Session數據廣播復制到集群中其餘機器上
使用場景：機器較少，網路流量較小
優點：實現簡單、配置較少、當網路中有機器Down掉時不影響用戶訪問
缺點：廣播式復制到其餘機器有一定廷時，帶來一定網路開銷Session Sticky 方式管理
簡介：即粘性Session、當用戶訪問集群中某台機器後，強制指定後續所有請求均落到此機器上
使用場景：機器數適中、對穩定性要求不是非常苛刻
優點：實現簡單、配置方便、沒有額外網路開銷
缺點：網路中有機器Down掉時、用戶Session會丟失、容易造成單點故障緩存集中式管理
簡介：將Session存入分布式緩存集群中的某台機器上，當用戶訪問不同節點時先從緩存中拿Session信息
使用場景：集群中機器數多、網路環境復雜
優點：可靠性好
缺點：實現復雜、穩定性依賴於緩存的穩定性、Session信息放入緩存時要有合理的策略寫入
動靜分離
基於以上Nginx反向代理，我們還可以實現動靜分離，靜態請求如html、css、js等請求交給Nginx處理，動態請求分發給後端Tomcat處理。
Nginx 升級到1.9.5+可以開啟HTTP/2.0時代，加速網站訪問。
當然，如果公司不差錢，CDN也是一個不錯的選擇。
服務拆分
在這分布式微服務已經普遍流行的年代，其實我們沒必要踩過多的坑，就很容易進行拆分。市面上已經有相對比較成熟的技術，比如阿里開源的Dubbo(官方明確表示已經開始維護了)，spring家族的spring cloud，當然具體如何去實施，無論是技術還是業務方面都要有很好的把控。
Dubbo
SpringCloud
微服務與輕量級通信
持續集成部署
服務拆分以後，隨著而來的就是持續集成部署，你可能會用到以下工具。
Docker、Jenkins、Git、Maven
圖片源於網路，基本拓撲結構如下所示：
整個持續集成平台架構演進到如下圖所示：
服務集群
Linux集群主要分成三大類( 高可用集群， 負載均衡集群，科學計算集群)。其實，我們最常見的也是生產中最常接觸到的就是負載均衡集群。
負載均衡實現
分布式session
大家都知道，服務一般分為有狀態和無狀態，而分布式sessoion就是針對有狀態的服務。
分布式Session的幾種實現方式
分布式Session的幾種管理方式