第一篇：關于大型asp.net應用系統的架構

關于大型asp.net應用系統的架構

前言

最近幾年在.net方面的工作經歷，讓我長久以來(有幾年了)想寫關于大型asp.net應用系統架構文章的念頭。之前和同事們聊天的時候說的都是一些思維片段，其中的想法不盡完善，聊完天再仔細想想，一些主意就逐漸清晰了。現在終于付諸行動了，將一些想到的主意與大家一起探討，也算是對過去幾年在ASP.NET方面的一個總結。這對我來說也是一個學習過程。

博客園有不少同仁在寫系統架構或者企業應用架構方面的文章，我看過其中一些。就我看過的這些文章，我發現他們當中相當多的人寫的是分層架構。從我的看法來說，分層是不錯。但是如果是我自己寫的話，我會從架構的選擇來說起。那么應用程序的架構就有可能不選擇分層的架構，而選擇其他架構。另外我會從整個系統的角度來寫，即從硬件和軟件兩個角度來思考一個系統。

這些都是我的一些建議，希望對您有所幫助。

簡介

大型asp.net應用要考慮如何服務眾多的訪問者，同時還要保證每個訪問者都獲得高質量的服務。需要面對不同語言的用戶；需要保證安全性；應用系統的伸縮性也是很強的，當服務器集群有點不足以擔負壓力時，可以向服務器集群中加入更多的服務器來增加整個應用系統的服務能力。服務器的可用性也會要求很高，一年的下線時間是很少的。服務器的災難備份也是很好的，即使現在的機房遭受毀滅性打擊，也有災難備份可以恢復服務。服務器上跑的asp.net應用是可擴展的，具有很好的可擴展性，同時具有良好的可維護性。本系列文章將談談大型asp.net應用系統架構的諸多方面。本篇將談到架構的選擇。

架構的選擇

架構的選擇與應用程序的類型有關。這里說的是asp.net應用，那么Client-Server的架構就很顯然排除了。剩下： 基于組件的架構

應用可以按組件劃分，不用組件實現不同功能和邏輯，組件之間的接口規范有很好的定義。某些組件可以重用。

分層Layered的架構

應用被劃分成了堆疊在一起的若干層，每一層完成特定的服務和功能，與其上下層接口，各層之間是調用被調用的關系。在最上面的層只有調用下面的一層，在中間的層則兼有調用和被調用。在最下面的層則是僅供上面的層調用。通常劃分成UI層，商務邏輯層，數據層等，并且通常多個層都部署在同一臺服務器上。

消息總線型的架構

應用程序按照預定義的格式來收發消息。有一個消息隊列和消息存儲，分發處理的任務。相關消息的事件被程序處理。支持不同的系統平臺。消息總線里面有若干定義好的消息流，消息總線同各系統平臺交換數據，支持不同的格式。將消息交由不同的處理程序處理。

Model, View, Controller(MVC)架構 用戶交互的處理與UI顯示分離 用戶交互的處理和UI顯示與數據分離

3Tier/N Tier的架構

Tier可以譯成排。以與Layer(層)有所區別。將應用程序劃分成一系列的服務，包括UI, Business(商業邏輯), 數據等服務。各Tier可部署在不同的服務器上。類似于分層(layer)的架構。通常分層(layer)不跨機器的邊界，也即所有層(layer)都部署在一臺服務器上。Tier是要跨機器的邊界。各Tier之間用預定義的通信協議來通信，如WCF, Web service, 或者TCP/IP等。分層(layer)的各層(layer)之間的通信都是通過該編程語言的引用和調用來實現的。所以是有區別的。

面向對象的架構

應用可以劃分成自給自足的可重用的對象集合，對象包含了數據和行為。各對象之間有消息交互。面向服務的架構

應用使用一個功能是通過調用一個服務。在服務提供者和調用者之間有通信合同和消息，通信合同定義了消息的格式和通信的方式。消息則包含通信的內容。面向服務的架構是“請求-響應”的工作模式。應用程序是以一種服務提供的，調用者需要向服務發送預定義好的請求消息，服務才做出響應。

這些架構類型都可以用來開發asp.net應用。我們可以從其中選擇架構類型的組合來，比如：分層Layered的架構 + 面向服務的架構。MVC架構 + 消息總線型架構。具體的選則，取決于應用程序的要求。現在說一下如何選架構： 如果

有若干現成組件，比如以前系統的ActiveX組件或者.net的組件

應用程序足夠簡單而不需要分層的架構，通過調用這些組件就可完成大部分工作

不同語言開發的組件需要結合在一起，如ASP.net需要調用VB寫的COM+的組件

應用程序需要支持插件技術，可以動態切換組件，例如用.net反射技術實現的插件技術

那么我們可以選擇基于組件的架構。如果

應用程序比較復雜，不同的功能需要不同的層來各司其職，如數據訪問，商務邏輯，表現等。

有比較復雜的商務邏輯和流程。

那么我們可以選擇分層的架構。如果

有若干已有系統并且這些系統之間有特定的交互

需要讓一個系統與外部的其他系統交互

不同平臺上的系統相互之間進行交互

那么我們可以選擇消息總線型的架構 如果

要獲得分離的UI視圖和處理邏輯

要UI視圖和處理邏輯與數據存儲分離

那么我們可以選擇Model,View,Controller(MVC)架構 如果

應用全部在內部網里

應用在互聯網上，同時商務邏輯需要暴露給公眾使用

商務邏輯足夠復雜，需要專門的服務器來提供商務邏輯服務。

應用程序比較復雜，不同的功能分布在不同的服務器上，每一種功能，都可能是由一組服務器來提供。

那么我們可以選擇3 Tier/N Tier架構 如果

相關商業領域有足夠多的現實對象(這些對象通常是相關商務人員口中的名詞)，并且這些對象之間有交互

應用比較復雜，需要更多的抽象

對象的數據和行為都需要封裝以利重用

有足夠的資源來做深入的面向對象分析，如時間，人力等。

那么我們可以選擇面向對象的架構。如果

應用需要支持平臺無關性

多個應用程序的功能放進一個單一的界面來提供

采用請求-響應模式運行

需要開發軟件加服務(Software plus service)，軟件即服務(Software as a service)類型的應用，或者基于云計算的應用

那么我們可以選擇面向服務的架構。

針對目前的場景：大型ASP.NET應用，那么它最基本的需求可能是這樣的：

同時訪問的用戶將會是相當多的，比如幾千個，上萬個。7x24小時都有大量用戶訪問

某些地方需要用戶登錄以獲取一些需要授權才能獲得的信息

我們可能選擇的架構組合可能是這樣的： 3Tier/N Tier的架構

Model, View, Controller(MVC)架構結合3Tier/N Tier的架構 3Tier/N Tier的架構結合面向服務的架構 3Tier/N Tier的架構結合面向對象的架構 當然也有可能是其他的組合。

分層Layered的架構不適合大型的ASP.NET應用。分層Layered的架構通常將UI層，商務邏輯，數據訪問層都部署在同一臺服務器上，首先一臺服務器不能負擔眾多的用戶，還有復雜的商務邏輯不是一臺服務器能全部擔負的。所以分層Layered的架構不適合大型的ASP.NET應用。小型的ASP.NET應用才適合分層Layered的架構。

基于組件的架構也不適合大型ASP.NET應用。通常來說大型的ASP.NET應用都是相當復雜的，它的UI界面，商務邏輯，數據都是復雜的。不會簡單到調用幾個控件就完成了大部分的工作，大型的ASP.NET應用的每一個Tier排，都需要眾多的服務器來分擔壓力，基于組件的架構的分布式能力有限，所以基于組件的架構是通常不會在大型ASP.NET應用里考慮的，除非是有若干個重要的控件，并且要考慮集成多個編程語言的控件時，才會考慮基于組件的架構。而且是在某個局部使用，即需要與其他架構一起結合起來用。

消息總線型架構可以在某些場景下參與大型ASP.NET應用的開發。通常是需要將多個系統平臺整合在一起的時候。消息總線型的架構需要結合其他的架構來共同構造ASP.NET應用。

MVC架構關注的更多的是UI，用戶交互的控制以及數據存取的分離。通常不能單獨去構造一個大型的ASP.NET架構。需要結合3Tier/N Tier架構來共同構造大型ASP.NET的架構。MVC架構在UI還有用戶交互上有固定的模式，所以可以在UI這一塊應用MVC的架構，當涉及到MVC中的模型Model時，就可以擴展到3 Tier/N Tier的架構。即在訪問模型Model時，就去訪問另外一個服務器上的商務邏輯和數據存儲。這個可以用下圖來表示：

面向對象的架構是更多地關注應用里面的面向對象分析，設計等過程產生出來的結果。這個結果體現了現實世界中的對象之間的交互作用。面向對象的架構需要結合其他架構如3 Tier/N Tier架構來共同構造ASP.NET應用程序的架構。

面向服務的架構是在特定場景下需要的。即上面所說的，多個功能作為一項服務，提供一個統一的UI給外界用戶。大型ASP.NET應用中通常需要將商務邏輯提供給公眾訪問。這時就可以采用面向服務的架構。面向服務的架構也需結合其他架構如3 Tier/N Tier架構來共同構造ASP.NET應用程序的架構。

Tier/N Tier架構對于大型ASP.NET應用來說是必須的。它的每一Tier排都由若干服務器組成。只有這樣才可以服務眾多的用戶。如上面的圖所示，UI調用商務邏輯時得跨越機器的邊界，調用另外一臺服務器上的商務邏輯服務接口。

結束語

架構的選擇需要根據不同架構的特點和應用程序的需求來進行選擇，有時候需要用多個架構的組合才足以滿足一個復雜應用的需求。設計者需要根據實際情況來決定合適的架構選擇。

接下來將展開談談3 Tier/N Tier架構......

第二篇：asp.net系統時間-ASP.NET校友錄系統.

asp.net 系統時間-ASP.NET校友錄系統

前言

Internet已經成為人們生活、工作、學習越來越離不開的平臺腳丫論文網Web技術已經不在局限于單純地提供信息服務，代寫論文而是日益成為1個操作平臺，為用戶提供強大的服務功能。例如網上電子商務、社會信息數據庫等。網絡實現了遠程通訊，人們能夠通過計算機網絡進行電子郵件的發送，召開網絡會議，網上購物，甚至坐在家里就可以上大學（網上教育）。網絡有巨大的潛力待我們去開發與探索。因此，基于B/S體系架構創建這個校友網站，緊跟行業發展，滿足人們生活、學習的需要。

校友錄名為“校友錄”或者“同學錄”，其實不只是局限于同學這個圈子，朋友、同學、同事、老師與親人等等都可以。它的目標受眾是組織，只要是1個社會組織或者群體，不管大小都可以在網上申請1個校友錄。用戶人群的范圍擴大到學生、同事、企業、家庭、軍隊、企事業單位的部門等等。因為每1個人都從屬于1定的組織或團體，所以每1位網民都有成為校友錄用戶的可能。這就為在校或已畢業的廣大校友們提供1份交流思想的場所，通過提供完善的校友錄服務和規范校友錄的管理，建立起校友間的溝通渠道，以達到增進校友之間、校友與母校之間的感情，方便校友聯系的目的，從而增強學校的凝聚力。

只要加入了班級或者某1團體的校友錄，且你已經被批準成為這個校友錄團體中的1員，你就可以享受著傳者和受者的基本等同待遇。在校友錄內部，傳者和受者是沒有界限的，在信息交流的過程中，傳者和受者的角色是互換的，用戶既是傳者又是受者，在信息發布和接受方面是對等的，都可以自由地發表言論、上傳圖片、班級聊天等等交流活動。也可以通過此網站與朋友聯系，并且還能夠創建學校和班級等功能。系統中班級管理為必不可少的模塊項，主要是為了安全有效地存儲和管理登錄網站的用戶的信息，賦予管理員特定的權限，可以對用戶進行分類，添加，刪除，修改等，方便網站的管理與維護。

第三篇：系統架構設計師崗位職責

1.負責相關產品的架構設計工作，以及產品間的接口設計及管理。

2.負責指導產品的高層設計，參與重要或高風險模塊的設計，控制高層設計的質量。

3.負責或參與公司外部和內部技術規范的制定。

4.負責向相關組織提供關鍵技術支持。

5.負責在公司內部進行組織領域內的技術知識傳遞。

6.負責或參與各項研發過程的技術評審工作。

7.與其他部門進行協調、溝通，保證開發與設計相符。

8.負責相關請求的技術分析；負責制訂相關的技術解決方案。

9.組織實施技術可行性驗證及技術選型工作。

第四篇：系統架構設計師考試心得

系統架構設計師http://

系統架構設計師考試心得

去年參加了系統架構設計師的考試，考試還算比較順利，順利通過了國家分數線，獲得了資格證書。除去考試不說，在準備考試的這段時間里了解了一下架構設計的主要工作，和做架構設計的理論知識和一些成熟的架構方案，對自己以后的實際工作有很大的幫助。下面總結一下我的備考經驗。

【前期準備】

花了一個月的時間基本就是學習基礎知識，其實好多大學的課程都已經學習過了，無奈畢業以后就基本不怎么看書了，忘了很多，不過比起從頭來學還是輕松了很多，O(∩_∩)O哈哈~。

參考書籍：

《系統架構設計師考試全程指導》和《系統架構設計師教程》這兩本書基礎知識基本上涵蓋齊全了，后一本書可以粗略看一次，了解一下架構設計師需要的主要背景理論知識，前一本書推薦看兩次，第一次算是過一下主要的理論知識點，能記住多少算多少，第二次順便做一下課后的習題，實際上題目也沒幾道，每個章節也才不到20道題目，便于加深理解，同時重點記憶一些關鍵的知識點。

【中期準備】

10月份到11月份這一個月基本上就是熟悉考試的題型，了解一下考試題目是什么樣子的，主要考什么，哪些是重點，案例分析題目怎么解答等等。

參考書籍：

《系統架構設計師考試考點突破、案例分析、試題實戰一本通》和《系統架構設計師考試歷年試題分析與解答》可以看一下歷年的考題，相信大家考試也都不少了，最具有參考價值的題目仍舊是歷年的真題，雖說系統架構師自從09年

系統架構設計師http://

才開始，但是通過本書試著做一些題目，了解一下歷年考過的知識，和簡答題目的方法，尤其是下午的案例分析題，難度相對比較高，可以重點學習一下回答這類題目的方法。

【后期準備】

11月份，考試前夕，這段時間主要是知識總結和準備論文方面的工作。架構知識涉及面太廣，不可能面面俱到，所有的知識都非常熟悉，必要的背景知識相信通過前段時間的學習，基本也就OK了，現在重點是論文設計了。一來，論文的字數比較多，2個小時的考試時間，寫3000字的論文，還要扣除包括審題，概要什么的時間花費，練習練習動手寫作能力還是非常重要的。如果提前能練練手的話，相信語言的組織了，字跡的工整程度了，都能提高不少。二來，選擇自己在近兩年時間內做過的印象最深的一個項目，從項目的整體角度考慮，需求分析了，架構設計了，軟件測試了，認為能夠以宏觀角度概括的，都可以整理一下，這都是用來寫作的素材。三來，就是細化自己在項目中所做的工作，不要泛泛而談，舉實例出來，提出解決方案，這就是論文的論據。

其實論文這塊，題目本身比較靈活，結合自己的實際項目經驗來寫，相對來說容易許多，內容也不會顯得太空洞。同時可以網上參考一下歷年的優秀論文，了解一下開頭怎么寫，中間內容怎么寫，結尾怎么寫，使文章讀起來整體有一氣呵成的感覺，免得寫的不著邊際，跑題了。

【總結】

總的來說，基礎知識還是要花大工夫的，畢竟涉及的知識面比較廣泛，操作系統了，網絡了，數據庫了，信息系統了，軟件架構設計了，知識產權了等等。有些是了解的，有些是要重點掌握的，在復習基礎知識的時候可以歸類記憶。

系統架構設計師http://

再者，要多了解一下當前互聯網產業的熱門技術，畢竟做架構設計工作也是與時俱進的，現在都有好多的成熟架構解決方案，平時多了解和積累一些。

最后，也最重要，在實際的項目中把所積累的知識運用一下，不僅對自己做設計工作有好處，同時對考試來說，案例分析和論文設計也就比較容易上手了，不然的話，那就真是紙上談兵了。考試的時候無從下手，不容易答題。

這算是自己考架構設計師的一點心得體會，難免有不足之處，相信大家只要認真準備了，考試還是比較容易過的，重要的是自己在工作中做架構設計的時候也能得心應手，靈活做設計，最后也預祝大家都能考個好成績！！

第五篇：系統架構設計師的主要職責

系統架構設計師的主要職責

職責：

1)

業務需求系統分析，提出技術研究及可行性報告;

2)

結合需求設計高擴展性、高性能、安全、穩定、可靠的應用系統

;

3)

可以通過配置實現業務需求的變化，跟蹤并研究___并應用于產品

;

4)

指導研發工程師的產品開發和技術研究工作，解決各類技術疑難問題，形成良好的研發氛圍，提升團隊整體技術水平。

5)

管理與指導研發團隊，負責產品研發計劃制定與執行;

任職要求：

1)

___年以上Java開發經驗，___年以上架構設計經驗;

2)

能對分布式常用技術進行合理應用，解決問題;

3)

精通網絡編程，熟悉HTTP，TCP/IP協議;

4)

對數據庫的基本理論和內部實現機制有深刻的理解，能夠熟練應用MySQL/NoSQL數據庫，有實際大數據量的數據庫設計經驗;

5)

熟悉緩存技術，網站優化，服務器優化，集群技術處理、網站負載均衡、系統性能調優等軟件編程高級技術;

6)

良好的邏輯思維能力，熟悉業務抽象和數據模型設計，具有很強的分析問題和解決問題的能力。

7)

有大型互聯網項目(作為技術總負責或核心領域負責人)的架構設計和技術管理的成功經驗。在相關公司擔任過___人以上開發團隊技術主管者優先。

系統架構設計師的主要職責2

職責：

1、負責公司產品數據庫的規劃、建模、設計和管理，數據庫相關模塊的設計研發工作;

2、按進度計劃要求準時完成開發任務，及時編制程序開發文檔，制定數據庫監控策略,備份策略,容災策略;

3、數據庫日常監控、維護、備份和恢復;探查系統潛在的問題和可能的性能瓶頸,并進行優化;

4、制定數據庫技術方案，分庫分表策略，數據遷移方案，SQL優化

;

任職資格：

1、計算機、電子工程、機械、通信等理工科相關專業;

2、大專以上學歷，條件優秀者可以適當放寬;

3、對從事軟件開發等相關工作具有濃厚興趣;

4、善于溝通和協調，具有高度團隊合作精神;主動學習新知識的能力;具有高度的敬業精神、創新精神和開拓意識;精力充沛，能夠承受較大的工作壓力;

系統架構設計師的主要職責3

職責：

1、負責質量管控系統后臺架構開發、優化、重構

2、參與各分站檢測軟件開發、設計、優化及升級

3、參與項目管理、進行業務需求分析、需求細化、功能落實、系統架構、模塊建模、數據庫設計

4、與部門人員進行必要的技術分享、統一目前公司軟件開發架構

要求：

1、三年以上及具有大數據設計、系統架構相關經驗

2、精通C#，熟悉

MVC

或

ASP.NET

進行Web開發

3、精通SQL

數據庫

系統架構設計師的主要職責4

職責：

1、負責公司產品設計、研發、實施、管理;

2、負責公司產品關鍵技術架構的制定和相關新技術的研究工作;

3、負責帶領團隊實現產品目標，保障公司產品開發、上線、維護及其他項目高質量順利執行;

4、負責團隊的管理，重大技術決策和技術方案的制定，并培養提升整個團隊的質量技能;

5、負責整體產品技術隊伍建設，做好人員配置與協調，有效地監控項目進展，對員工進行考核、培訓;

6、緊密配合公司的業務發展，組織團隊完成技術任務;

7、帶領團隊進行技術語言和技術難點攻關。

任職要求：

1、大專以上學歷，計算機相關專業;

2、三年以上知名互聯網行業工作經驗(ERP或管理軟件)領域，___年以上工作經驗，帶領研發團隊;

3、有大型產品的設計和開發經驗，具備優秀的編程能力、管理能力，對計算機語言有十分深入的了解;

4、精通智慧警務業務系統的架構設計、系統分析、軟件實現、性能優化及系統安全;

5、對AI技術有深刻理解和實現能力，有豐富的項目管理經驗、產品研發經驗;

6、具備敏銳準確的洞察力和縝密的邏輯思維、能夠把握行業業務發展動向和關鍵技術發展趨勢;

7、具備良好合作態度及團隊精神，富有工作激情、創造力和責任感;

系統架構設計師的主要職責5

職責：

1.作為大數據平臺架構師，負責規劃設計大數據基礎平臺及研究相關技術;

2.負責海量數據采集、處理及存儲、應用方案的技術選型及架構實現;

3.負責海量數據分析/查詢、分布式存儲、流式/實時計算等應用層架構搭建及核心代碼實現;

4.負責大數據技術應用的技術難點攻關、技術發展研究。

任職要求：

___本科及以上學歷，數學或計算機相關專業畢業，具有扎實的計算機基礎理論知識;

2.計算機領域五年以上工作經驗，___年以上hadoop項目設計及研發經驗;

3.熟悉hive、hbase、storm、mahout、flume、ElasticSearch、Spark、Kafka等，具備實際項目設計或開發經驗;

4.熟悉大規模數據挖掘、機器學習、自然語言處理、分布式計算中一項或多項技術，并具備多年的實際工作經驗;

5.熟悉主流關系型數據庫(Oracle、MySql)、NoSql數據庫，熟悉pl/sql編程;

___對技術充滿熱情且具有鉆研精神，對新技術以及行業動向保持敏感性;

7.具有較強的執行力，高度的責任感、很強的學習、溝通能力，能夠在高壓下高效工作;

8.有物流、快遞、電子商務行業經驗者優先。