軟件各類架構圖收集

發佈一企業技術架構圖，供你們參考。

 

 

該技術架構圖是本人根據多年企業技術架構經驗而制定，是企業技術的總架構圖，但願對CTO們有所借鑑。

 簡單說明：

1.中間件基礎運行環境是通過統一規劃的以WebLogic、JBOSS爲主的集羣環境                            

2.企業集成平臺是以基礎業務應用爲基礎服務於上層平臺和基礎業務應用的高度集成平臺         

3.數據中心是企業公共數據的集中管理好比用戶數據、企業編碼，能夠經過數據集成平臺或服務集成平臺分發給其餘應用     

 

項目作了很多,都沒畫過架構圖,此次被要求畫圖,畫的很醜,請你們看圖自己包含的系統架構信息

1、架構總體圖

　　

   一、核心是兩庫一線

　　1.1 接口總線

　　　　全部算法功能抽象成接口,其中大部分接口的方法都是泛型方法,是爲了解決某一大類問題的

　　1.2 代碼庫

　　　　代碼庫包含現接口總線中接口的各類實現

　　1.3 應用庫

　　　　提供用戶的界面或者提供給外部的服務

　　　　是經過容器配置調用算法庫中的代碼來實現的各類應用          

 

2、應用關係圖

       一、應用經過配置從應用庫中組裝出本身的應用系統

       二、應用自己以外的東西儘可能使用攔截器處理(受權訪問、權限數據推送、異常處理、緩存、日誌等)

       三、使用消息隊列作高併發應用支撐(秒殺相似應用)

       四、使用分佈式任務系統作週期做業、數據維護、數據計算等

 

 

ENode架構圖

 

什麼是ENode

ENode是一個.NET平臺下，純C#開發的，基於DDD,CQRS,ES,EDA,In-Memory架構風格的，能夠幫助開發者開發高併發、高吞吐、可伸縮、可擴展的應用程序的一個應用開發框架。

• 開源項目地址：https://github.com/tangxuehua/enode
• 做者博客地址：http://www.cnblogs.com/netfocus/category/496012.html
• QQ交流羣號：185916873
• 微信公衆號：ENode

ENode框架特點

1. 一個DDD開發框架，完美支持基於六邊形架構思想的開發
2. 實現CQRS架構思想，而且框架提供C端命令的處理結果的返回，支持同步返回和異步返回
3. 內置Event Sourcing（ES）架構模式，讓C端的數據持久化變得通用化
4. 聚合根常駐內存，in-memory domain model
5. 聚合根的處理基於Command Mailbox, Event Mailbox的思想，相似Actor Model, Actor Mailbox
6. 嚴格遵照聚合內強一致性、聚合之間最終一致性的原則
7. Group Commit Domain event
8. 基於聚合根ID+事件版本號的惟一索引，實現聚合根的樂觀併發控制
9. 框架保證Command的冪等處理
10. 經過聚合根ID對命令或事件進行路由，作到最小的併發衝突、最大的並行處理
11. 消息發送和接收基於分佈式消息隊列EQueue，支持分佈式部署
12. 基於事件驅動架構範式（EDA，Event-Driven Architecture）
13. 基於隊列的動態擴容/縮容
14. EventDB中由於存放的都是不可變的事件，因此水平擴展很是容易，框架可內置支持
15. 支持Process Manager（Saga），以支持一個用戶操做跨多個聚合根的業務場景，如訂單處理，從而避免分佈式事務的使用
16. ENode實現了CQRS架構面臨的大部分技術問題，讓開發者能夠專一於業務邏輯和業務流程的開發，而無需關心純技術問題

晚上把公司應用的架構結合以前研究的東西梳理了下，整理了一張架構規劃圖，貼在這裏備份

下面是我的理解的作架構的幾個要點：

一、系統安全

這是首要考慮的，以這張圖爲例，網絡劃分爲3個區：

a) DMZ區能夠直接公網訪問，也能夠 與App Core區互通，但不能直接與DB Core區互通 (一般這裏放置 反向代理Web服務器)

b) App Core區能與DMZ區、DB Core區互通，可是沒法直接從公網訪問 (一般這裏放置 應用服務器、中間件服務器之類)

c) DB Core區僅與App Core區互通 (一般這裏放置 核心數據庫)

二、儘可能消除單點故障

上圖中，除了「硬件負載均衡」節點外，其它節點均可以部署成集羣（DB有點特殊，傳統RDBMS要實現分佈式/集羣仍是比較困難的，要看具體採用的數據庫產品，並不是全部數據庫都能方便的作Sharding），Jboss自己能夠經過Domain模式+mod_cluster實現集羣、Redis經過Master/Slave以Sentinel方式能夠實現HA、IBM MQ自己就支持集羣、FTP Server配合底層儲存陣列也能夠作到HA、Nginx靜態資源服務器自沒必要說

三、成本

儘可能採用開源成熟產品，jboss、redis、nginx、apache、mysql、rabbit MQ都是很好的選擇。硬件負載均衡一般成本不低，可是效果明顯，若是實在沒錢，域名解析採用DNS輪詢策略，也能達到相似效果，只不過可靠性略差。

四、Database問題

常規企業應用中，傳統關係型數據仍然是主流，可是no-sql通過這幾年發展，技術也日漸成熟了，一些非關鍵數據能夠適當採用no-sql數據庫，好比：系統日誌、報文歷史記錄這類相對比較獨立，並且增加迅速的數據，能夠考慮存儲到no-sql db甚至HDFS、TFS等分佈式開源文件系統中。

若是系統數據量級達到單機RDBMS的上限，儘早考慮Sharding方案，目前mysql在這方面比較成熟，其它數據庫就很差說了。

五、性能

web server、app server這些通常均可以經過集羣實現橫向擴張，知足性能平常增加的需求。最大的障礙仍是DB，若是規模真達到了DB的上限，仍是考慮換分佈式DB或者遷移到「雲」上吧。

 

HBase 系統架構圖

　　

　　組成部件說明 　　Client：    　　使用HBase RPC機制與HMaster和HRegionServer進行通訊    　　Client與HMaster進行通訊進行管理類操做    　　Client與HRegionServer進行數據讀寫類操做    　　Zookeeper：    　　Zookeeper Quorum存儲-ROOT-表地址、HMaster地址    　　HRegionServer把本身以Ephedral方式註冊到Zookeeper中，HMaster隨時感知各個HRegionServer的健康情況    　　Zookeeper避免HMaster單點問題    　　HMaster：    　　HMaster沒有單點問題，HBase中能夠啓動多個HMaster，經過Zookeeper的Master Election機制保證總有一個Master在運行    　　主要負責Table和Region的管理工做：    　　1 管理用戶對錶的增刪改查操做    　　2 管理HRegionServer的負載均衡，調整Region分佈    　　3 Region Split後，負責新Region的分佈    　　4 在HRegionServer停機後，負責失效HRegionServer上Region遷移    　　HRegionServer：    　　HBase中最核心的模塊，主要負責響應用戶I/O請求，向HDFS文件系統中讀寫數據

　　

　　HRegionServer管理一些列HRegion對象；   　　每一個HRegion對應Table中一個Region，HRegion由多個HStore組成；  　　每一個HStore對應Table中一個Column Family的存儲；    　　Column Family就是一個集中的存儲單元，故將具備相同IO特性的Column放在一個Column Family會更高效

　　HStore：    　　HBase存儲的核心。由MemStore和StoreFile組成。    　　MemStore是Sorted Memory Buffer。用戶寫入數據的流程：

　　

　　Client寫入 -> 存入MemStore，一直到MemStore滿 -> Flush成一個StoreFile，直至增加到必定閾值 -> 觸發Compact合併操做 -> 多個StoreFile合併成一個StoreFile，同時進行版本合併和數據刪除 -> 當StoreFiles Compact後，逐步造成愈來愈大的StoreFile -> 單個StoreFile大小超過必定閾值後，觸發Split操做，把當前Region Split成2個Region，Region會下線，新Split出的2個孩子Region會被HMaster分配到相應的HRegionServer上，使得原先1個Region的壓力得以分流到2個Region上。 由此過程可知，HBase只是增長數據，有所得更新和刪除操做，都是在Compact階段作的，因此，用戶寫操做只須要進入到內存便可當即返回，從而保證I/O高性能。

　　HLog    　　引入HLog緣由：    　　在分佈式系統環境中，沒法避免系統出錯或者宕機，一旦HRegionServer意外退出，MemStore中的內存數據就會丟失，引入HLog就是防止這種狀況    　　工做機制：    　　每一個HRegionServer中都會有一個HLog對象，HLog是一個實現Write Ahead Log的類，每次用戶操做寫入Memstore的同時，也會寫一份數據到HLog文件，HLog文件按期會滾動出新，並刪除舊的文件(已持久化到StoreFile中的數據)。當HRegionServer意外終止後，HMaster會經過Zookeeper感知，HMaster首先處理遺留的HLog文件，將不一樣region的log數據拆分，分別放到相應region目錄下，而後再將失效的region從新分配，領取到這些region的HRegionServer在Load Region的過程當中，會發現有歷史HLog須要處理，所以會Replay HLog中的數據到MemStore中，而後flush到StoreFiles，完成數據恢復。

　　HBase存儲格式    　　HBase中的全部數據文件都存儲在Hadoop HDFS文件系統上，格式主要有兩種：    　　1 HFile HBase中KeyValue數據的存儲格式，HFile是Hadoop的二進制格式文件，實際上StoreFile就是對HFile作了輕量級包裝，即StoreFile底層就是HFile    　　2 HLog File，HBase中WAL（Write Ahead Log） 的存儲格式，物理上是Hadoop的Sequence File

　　HFile

　　

　　圖片解釋：   　　HFile文件不定長，長度固定的塊只有兩個：Trailer和FileInfo    　　Trailer中指針指向其餘數據塊的起始點    　　File Info中記錄了文件的一些Meta信息，例如：AVG_KEY_LEN, AVG_VALUE_LEN, LAST_KEY, COMPARATOR, MAX_SEQ_ID_KEY等    　　Data Index和Meta Index塊記錄了每一個Data塊和Meta塊的起始點    　　Data Block是HBase I/O的基本單元，爲了提升效率，HRegionServer中有基於LRU的Block Cache機制    　　每一個Data塊的大小能夠在建立一個Table的時候經過參數指定，大號的Block有利於順序Scan，小號Block利於隨機查詢    　　每一個Data塊除了開頭的Magic之外就是一個個KeyValue對拼接而成, Magic內容就是一些隨機數字，目的是防止數據損壞

　　HFile裏面的每一個KeyValue對就是一個簡單的byte數組。這個byte數組裏麪包含了不少項，而且有固定的結構。

　　

　　KeyLength和ValueLength：兩個固定的長度，分別表明Key和Value的長度   　　Key部分：Row Length是固定長度的數值，表示RowKey的長度，Row 就是RowKey    　　Column Family Length是固定長度的數值，表示Family的長度    　　接着就是Column Family，再接着是Qualifier，而後是兩個固定長度的數值，表示Time Stamp和Key Type（Put/Delete）    　　Value部分沒有這麼複雜的結構，就是純粹的二進制數據

　　HLog File

　　

　　HLog文件就是一個普通的Hadoop Sequence File，Sequence File 的Key是HLogKey對象，HLogKey中記錄了寫入數據的歸屬信息，除了table和region名字外，同時還包括 sequence number和timestamp，timestamp是「寫入時間」，sequence number的起始值爲0，或者是最近一次存入文件系統中sequence number。   　　HLog Sequece File的Value是HBase的KeyValue對象，即對應HFile中的KeyValue

　　

　　結束語：這篇文章是我專門在網上弄下來的，算是hbase部分的終極篇吧，個人服務端的源碼系列也要基於這個順序來開展。

 

 

一．三層架構圖

 

二．系統各層次職責
1.UI（User Interface）層的職責是數據的展示和採集，數據採集的結果一般以Entity object提交給BL層處理。Service Interface側層用於將業務或數據資源發佈爲服務（如WebServices）。
2.BL（Business Logic）層的職責是按預約的業務邏輯處理UI層提交的請求。
（1）Business Function 子層負責基本業務功能的實現。
（2）Business Flow 子層負責將Business Function子層提供的多個基本業務功能組織成一個完整的業務流。（Transaction只能在Business Flow 子層開啓。）
3．ResourceAccess層的職責是提供全面的資源訪問功能支持，並向上層屏蔽資源的來源。
（1）BEM（Business Entity Manager）子層採用DataAccess子層和ServiceAccess子層來提供業務須要的基礎數據/資源訪問能力。
（2）DataAccess子層負責從數據庫中存取資源，並向BEM子層屏蔽全部的SQL語句以及數據庫類型差別。
DB Adapter子層負責屏蔽數據庫類型的差別。
ORM子層負責提供對象－關係映射的功能。
Relation子層提供ORM沒法完成的基於關係（Relation）的數據訪問功能。
（3）ServiceAccess子層用於以SOA的方式從外部系統獲取資源。
注： Service Entrance用於簡化對Service的訪問，它至關於Service的代理，客戶直接使用Service Entrance就能夠訪問系統發佈的服務。Service     Entrance爲特定的平臺（如Java、.Net）提供強類型的接口，內部可能隱藏了複雜的參數類型轉換。
（4）ConfigAccess子層用於從配置文件中獲取配置object或將配置object保存倒配置文件。
4．Entity側層跨越UI/BEM/ResourceManager層，在這些層之間傳遞數據。Entity側層中包含三類Entity，以下圖所示：

 
三．Aspect
 Aspect貫穿於系統各層，是系統的橫切關注點。一般採用AOP技術來對橫切關注點進行建模和實現。
1．Securtiy Aspect：用於對整個系統的Security提供支持。
2．ErrorHandling Aspect：整個系統採用一致的錯誤/異常處理方式。
3．Log Aspect：用於系統異常、日誌記錄、業務操做記錄等。

四．規則
1．系統各層次及層內部子層次之間都不得跨層調用。
2．Entity object 在各個層之間傳遞數據。
3．須要在UI層綁定到列表的數據採用基於關係的DataSet傳遞，除此以外，應該使用Entity object傳遞數據。
4．對於每個數據庫表（Table）都有一個DB Entity class與之對應，針對每個Entity class都會有一個BEM Class與之對應。
5．有些跨數據庫或跨表的操做（如複雜的聯合查詢）也須要由相應的BEM Class來提供支持。
6．對於相對簡單的系統，能夠考慮將Business Function子層和Business Flow 子層合併爲一個。
7．UI層和BL層禁止出現任何SQL語句。

五．錯誤與異常
        異常能夠分爲系統異常（如網絡忽然斷開）和業務異常（如用戶的輸入值超出最大範圍），業務異常必須被轉化爲業務執行的結果。
1．DataAccess層不得向上層隱藏任何異常（該層拋出的異常幾乎都是系統異常）。
2．要明確區分業務執行的結果和系統異常。好比驗證用戶的合法性，若是對應的用戶ID不存在，不該該拋出異常，而是返回（或經過out參數）一個表示驗證結果的枚舉值，這屬於業務執行的結果。可是，若是在從數據庫中提取用戶信息時，數據庫鏈接忽然斷開，則應該拋出系統異常。
3．在有些狀況下，BL層應根據業務的須要捕獲某些系統異常，並將其轉化爲業務執行的結果。好比，某個業務要求試探指定的數據庫是否可鏈接，這時BL就須要將數據庫鏈接失敗的系統異常轉換爲業務執行的結果。
4．UI層(包括Service層)除了從調用BL層的API獲取的返回值來查看業務的執行結果外，還須要截獲全部的系統異常，並將其解釋爲友好的錯誤信息呈現給用戶。

六．項目組織目結構
 以BAS系統爲例。
1．主目錄結構：
 
2．命名空間命名：每一個dll的根命名空間便是該dll的名字，如EAS.BL.dll的根命名空間就是EAS.BL。每一個根命名空間下面能夠根據需求的分類而增長子命名空間，好比，EAS.BL的子空間EAS.BL.Order與EAS.BL.Permission分別處理不一樣的業務邏輯。
3.包含衆多子項目的龐大項目的物理組織：
 
核心子項目Core的位置：

 
Core子項目中包含一些公共的基礎設施，如錯誤處理、權限控制方面等。

七．發佈服務與服務回調
以EAS系統爲例。
 
1．同UI層的Page同樣，服務也不容許拋出任何異常，而是應該以返回錯誤碼(int型，1表示成功，其它值表示失敗)的形式來代表服務調用出現了錯誤，若是方法有返回值，則返回值以out參數提供。
2. 若是BAS系統提供了WebService（Remoting）服務，則BAS必須提供BAS.Entrance.dll。 BAS.Entrance.dll封裝了與BAS服務交換信息的通訊機制，客戶系統只要經過BAS.Entrance.dll就能夠很是簡便地訪問BAS 提供的服務。
3．若是BAS須要經過WebService（Remoting）回調客戶系統，則必須提供僅僅定義了接口的BAS.CallBack.dll，客戶系統將引用該dll，實現其中的接口，並將其發佈爲服務，供BAS回調。
4．當WebService的參數或返回值須要是複雜類型――即架構圖中的Service Entity，則Service Entity應該在對應的BAS.EntranceParaDef.dll或BAS.CallBackParaDef.dll中定義。 WebService定義的方法中的複雜類型應該使用Xml字符串代替（注意，Entrance和CallBack接口對應服務的方法的參數是強類型的），而Xml字符串和複雜類型對象之間的轉換應當在BAS.Entrance.dll或BAS.CallBack.dll中實現。

 

 

    從上圖中能夠看出，Android系統架構爲四層結構，從上層到下層分別是應用程序層、應用程序框架層、系統運行庫層以及Linux內核層，分別介紹以下：

    1）應用程序層

         Android平臺不只僅是操做系統，也包含了許多應用程序，諸如SMS短信客戶端程序、電話撥號程序、圖片瀏覽器、Web瀏覽器等應用程序。這些應用程序都是       用Java語言編寫的，而且這些應用程序都是能夠被開發人員開發的其餘應用程序所替換，這點不一樣於其餘手機操做系統固化在系統內部的系統軟件，更加靈活和個    性化。

    2）應用程序框架層

         應用程序框架層是咱們從事Android開發的基礎，不少核心應用程序也是經過這一層來實現其核心功能的，該層簡化了組件的重用，開發人員能夠直接使用其提    供的組件來進行快速的應用程序開發，也能夠經過繼承而實現個性化的拓展。

         a） Activity Manager（活動管理器）

              管理各個應用程序生命週期以及一般的導航回退功能

         b） Window Manager（窗口管理器）

              管理全部的窗口程序

         c）  Content Provider（內容提供器）

              使得不一樣應用程序之間存取或者分享數據

        d） View System（視圖系統）

              構建應用程序的基本組件

         e） Notification Manager(通告管理器)

              使得應用程序能夠在狀態欄中顯示自定義的提示信息

         f） Package Manager（包管理器） 

              Android系統內的程序管理

         g）Telephony Manager(電話管理器)

              管理全部的移動設備功能

         h）Resource Manager（資源管理器）

              提供應用程序使用的各類非代碼資源，如本地化字符串、圖片、佈局文件、顏色文件等

         i）Location Manager(位置管理器)

             提供位置服務

         j）XMPP Service（XMPP服務）

             提供Google Talk服務 

    3）系統運行庫層

         從圖中能夠看出，系統運行庫層能夠分紅兩部分，分別是系統庫和Android運行時，分別介紹以下：

         a）系統庫

              系統庫是應用程序框架的支撐，是鏈接應用程序框架層與Linux內核層的重要紐帶。其主要分爲以下幾個：

              Ø  Surface Manager：

                  執行多個應用程序時候，負責管理顯示與存取操做間的互動，另外也負責2D繪圖與3D繪圖進行顯示合成。 

     Ø  Media Framework： 

                  多媒體庫，基於PacketVideo OpenCore;支持多種經常使用的音頻、視頻格式錄製和回放，編碼格式包括MPEG四、MP三、H.26四、AAC、ARM。

              Ø  SQLite:

                  小型的關係型數據庫引擎 

              Ø  OpenGL|ES：

                 根據OpenGL ES 1.0API標準實現的3D繪圖函數庫 

              Ø  FreeType：

                  提供點陣字與向量字的描繪與顯示 

              Ø  WebKit：

                  一套網頁瀏覽器的軟件引擎

              Ø  SGL：

                  底層的2D圖形渲染引擎 

              Ø  SSL：

                  在Andorid上通訊過程當中實現握手 

              Ø  Libc：

             從BSD繼承來的標準C系統函數庫，專門爲基於embedded linux的設備定製

         b）Android運行時

             Android應用程序時採用Java語言編寫，程序在Android運行時中執行，其運行時分爲核心庫和Dalvik虛擬機兩部分。

             Ø  核心庫

                 核心庫提供了Java語言API中的大多數功能，同時也包含了Android的一些核心API,如android.os、android.net、android.media等等。

             Ø  Dalvik虛擬機

                 Android程序不一樣於J2me程序，每一個Android應用程序都有一個專有的進程，而且不是多個程序運行在一個虛擬機中，而是每一個Android程序都有一                個Dalivik虛擬機的實例，並在該實例中執行。Dalvik虛擬機是一種基於寄存器的Java虛擬機，而不是傳統的基於棧的虛擬機，並進行了內存資源使用的優化          以及支持多個虛擬機的特色。須要注意的是，不一樣於J2me,Android程序在虛擬機中執行的並不是編譯後的字節碼，而是經過轉換工具dx將Java字節碼轉成dex格          式的中間碼。

    4）Linux內核層 

        Android是基於Linux2.6內核，其核心繫統服務如安全性、內存管理、進程管理、網路協議以及驅動模型都依賴於Linux內核。

 

 

Entity Framework的全稱是ADO.NET Entity Framework，是微軟開發的基於ADO.NET的ORM(Object/Relational Mapping)框架。

Entity Framework的主要特色：

1. 支持多種數據庫（Microsoft SQL Server, Oracle, and DB2）；

2. 強勁的映射引擎，能很好地支持存儲過程；

3. 提供Visual Studio集成工具，進行可視化操做；

4. 可以與ASP.NET, WPF, WCF, WCF Data Services進行很好的集成。

架構圖一

架構圖2

 

 

 

　　剛剛來到一家新公司，首先會對項目進行一個大體瞭解，研究了兩天了，有了個整體的把握了，下面就是我這個小菜鳥畫的簡單系統架構圖！　　

　　有的時候架構龐大的嚇人，有的時候架構一眼看穿，但裏面卻暗藏殺機，真的須要咱們去認真學習，揣摩！

　　不久前在園子裏面看過一篇文章其中說道，設計架構無非就是一個字 → 「拆」，當時看到這個字，想起來還真的是這麼一回事，不過這裏面去包含了不少的東西，咱們如今就是不知道怎麼拆，這個也不是一時半會可以瞭解的，須要咱們認認真真的作，慢慢的積累，到時候就知道怎麼拆了，並且還拆的很到位，因此加油！

　　對於這個拆字園友們也給出了不少的理解，這是隻是我的見解！

 

 

 

Struts2 架構圖

Struts2架構圖 


        請求首先經過Filter chain，Filter主要包括ActionContextCleanUp，它主要清理當前線程的ActionContext和Dispatcher；FilterDispatcher主要經過AcionMapper來決定須要調用哪一個Action。 
        ActionMapper取得了ActionMapping後，在Dispatcher的serviceAction方法裏建立ActionProxy，ActionProxy建立ActionInvocation，而後ActionInvocation調用Interceptors，執行Action自己，建立Result並返回，固然，若是要在返回以前作些什麼，能夠實現PreResultListener。 


Struts2部分類介紹 
這部分從Struts2參考文檔中翻譯就能夠了。 
ActionMapper 
        ActionMapper實際上是HttpServletRequest和Action調用請求的一個映射，它屏蔽了Action對於Request等java Servlet類的依賴。Struts2中它的默認實現類是DefaultActionMapper，ActionMapper很大的用處能夠根據本身的須要來設計url格式，它本身也有Restful的實現，具體能夠參考文檔的docs\actionmapper.html。 
ActionProxy&ActionInvocation 
        Action的一個代理，由ActionProxyFactory建立，它自己不包括Action實例，默認實現DefaultActionProxy是由ActionInvocation持有Action實例。ActionProxy做用是如何取得Action，不管是本地仍是遠程。而ActionInvocation的做用是如何執行Action，攔截器的功能就是在ActionInvocation中實現的。 
ConfigurationProvider&Configuration 
        ConfigurationProvider就是Struts2中配置文件的解析器，Struts2中的配置文件主要是尤爲實現類XmlConfigurationProvider及其子類StrutsXmlConfigurationProvider來解析， 


Struts2請求流程 
一、客戶端發送請求 
二、請求先經過ActionContextCleanUp-->FilterDispatcher 
三、FilterDispatcher經過ActionMapper來決定這個Request須要調用哪一個Action 
四、若是ActionMapper決定調用某個Action，FilterDispatcher把請求的處理交給ActionProxy，這兒已經轉到它的Delegate--Dispatcher來執行 
五、ActionProxy根據ActionMapping和ConfigurationManager找到須要調用的Action類 
六、ActionProxy建立一個ActionInvocation的實例 
七、ActionInvocation調用真正的Action，固然這涉及到相關攔截器的調用 
八、Action執行完畢，ActionInvocation建立Result並返回，固然，若是要在返回以前作些什麼，能夠實現PreResultListener。添加PreResultListener能夠在Interceptor中實現，不知道其它還有什麼方式？ 

 

短鏈接聊天服務 ，每半分鐘刷新一次..

客戶端可切換3種渲染模式，全位圖blit傳輸：sprite區塊和MC

 

 

架構圖：

模塊與模塊之間的通訊也經過sendNotifcation發送消息。

 

神仙道尋路方法：

1. 2點是否能夠直接到達，能夠，則不走尋路，直接行進 2. 2點不能直接到達，進行尋路，找不到結果，尋找替代點 3. 正常尋路

關於flash共享庫:

若是a的庫裏的資源設置了共享資源並設置了一個url 把a發佈的swf放到設置的url的位置 b引入a的庫裏共享的資源..再發布b..這時b會自動從那個設置的url加載a

瀏覽器緩存地址：C:\Documents and Settings\Administrator\Local Settings\Temporary Internet Files

網頁遊戲的swf都加載到這裏了。

<深度排序>

那就不停的 遍歷 更具顯示對象的Y 設置它們再容器裏面的深度  不知道把同屏顯示對象的Y再數組裏面排序好 再設置深度 速度快  仍是變排序邊設置深度快 而且在數組裏面排序好 這種方法要速度很好

把圖層封裝成一個類。 和NPC和玩家都共同繼承一個接口 iworldObject 加一個屬性 depth. 建立的時候設置 這個屬性。而後sortOn("depth");

Array.Numberic 啊 默認都是 從小到大排序的 depth 是他的一個屬性 npc 也統一有這個屬性 而後就不用y軸排序了，看你的 y+height 挺糾結的 統一用 depth 這個屬性排序

這裏判斷這個 玩家的深度若是已經符合，就不要排序。 setChildIndex 消耗挺大的

 

 

詳解三層架構圖

 PS： 在看三層架構的時候，找的了一個我感受不錯的材料，裏面有以下一張圖，打算詳細的解釋一下這張圖，也總結一下三層的知識

  

1、系統各層次職責

     1.UI（User Interface）層的職責是數據的展示和採集，數據採集的結果一般以Entity object提交給BL層處理Service Interface側層用於將業務或數據資源發佈爲服務（如WebServices）。

    2.BL（Business Logic）層的職責是按預約的業務邏輯處理UI層提交的請求。

    （1）Business Function 子層負責基本業務功能的實現。

    （2）Business Flow 子層負責將Business Function子層提供的多個基本業務功能組織成一個完整的業務流（Transaction只能在Business Flow 子層開啓。）

    3．ResourceAccess層的職責是提供全面的資源訪問功能支持，並向上層屏蔽資源的來源。

  （1）BEM（Business Entity Manager）子層採用DataAccess子層和ServiceAccess子層來提供業務須要的基礎數據/資源訪問能力。

  （2）DataAccess子層負責從數據庫中存取資源，並向BEM子層屏蔽全部的SQL語句以及數據庫類型差別。

    DB Adapter子層負責屏蔽數據庫類型的差別。

    ORM子層負責提供對象－關係映射的功能。

    Relation子層提供ORM沒法完成的基於關係（Relation）的數據訪問功能。

  （3）ServiceAccess子層用於以SOA的方式從外部系統獲取資源。

         注：Service Entrance用於簡化對Service的訪問，它至關於Service的代理，客戶直接使用Service Entrance就能夠訪問系統發佈的服務。Service      Entrance爲特定的平臺（如Java、.Net）提供強類型的接口，內部可能隱藏了複雜的參數類型轉換。

  （4）ConfigAccess子層用於從配置文件中獲取配置object或將配置object保存倒配置文件。

    4．Entity側層跨越UI/BEM/ResourceManager層，在這些層之間傳遞數據。Entity側層中包含三類Entity，以下圖所示：

  

2、Aspect

    Aspect貫穿於系統各層，是系統的橫切關注點。一般採用AOP技術來對橫切關注點進行建模和實現。

    1．Securtiy Aspect：用於對整個系統的Security提供支持。

    2．ErrorHandling Aspect：整個系統採用一致的錯誤/異常處理方式。

    3．Log Aspect：用於系統異常、日誌記錄、業務操做記錄等。

 

3、規則

    1．系統各層次及層內部子層次之間都不得跨層調用。

    2．Entity object 在各個層之間傳遞數據。

    3．須要在UI層綁定到列表的數據採用基於關係的DataSet傳遞，除此以外，應該使用Entity object傳遞數據。

    4．對於每個數據庫表（Table）都有一個DB Entity class與之對應，針對每個Entity class都會有一個BEM Class與之對應。

    5．有些跨數據庫或跨表的操做（如複雜的聯合查詢）也須要由相應的BEM Class來提供支持。

    6．對於相對簡單的系統，能夠考慮將Business Function子層和Business Flow 子層合併爲一個。

    7．UI層和BL層禁止出現任何SQL語句。

 

4、錯誤與異常

         異常能夠分爲系統異常（如網絡忽然斷開）和業務異常（如用戶的輸入值超出最大範圍），業務異常必須被轉化爲業務執行的結果。

    1．DataAccess層不得向上層隱藏任何異常（該層拋出的異常幾乎都是系統異常）。

    2．要明確區分業務執行的結果和系統異常。好比驗證用戶的合法性，若是對應的用戶ID不存在，不該該拋出異常，而是返回（或經過out參數）一個表示驗證 結果的枚舉值，這屬於業務執行的結果。可是，若是在從數據庫中提取用戶信息時，數據庫鏈接忽然斷開，則應該拋出系統異常。

    3．在有些狀況下，BL層應根據業務的須要捕獲某些系統異常，並將其轉化爲業務執行的結果。好比，某個業務要求試探指定的數據庫是否可鏈接，這時BL就須要將數據庫鏈接失敗的系統異常轉換爲業務執行的結果。

    4．UI層(包括Service層)除了從調用BL層的API獲取的返回值來查看業務的執行結果外，還須要截獲全部的系統異常，並將其解釋爲友好的錯誤信息呈現給用戶。

 

5、項目組織目結構

    以BAS系統爲例。

     1．主目錄結構：

 

     2．命名空間命名：每一個dll的根命名空間便是該dll的名字，如EAS.BL.dll的根命名空間就是EAS.BL。每一個根命名空間下面能夠根據需求的 分類而增長子命名空間，好比，EAS.BL的子空間EAS.BL.Order與EAS.BL.Permission分別處理不一樣的業務邏輯。

    3.包含衆多子項目的龐大項目的物理組織：

 

核心子項目Core的位置：

 

 

Core子項目中包含一些公共的基礎設施，如錯誤處理、權限控制方面等。

6、發佈服務與服務回調

以EAS系統爲例。

 

     1．同UI層的Page同樣，服務也不容許拋出任何異常，而是應該以返回錯誤碼(int型，1表示成功，其它值表示失敗)的形式來代表服務調用出現了錯誤，若是方法有返回值，則返回值以out參數提供。

     2.若是BAS系統提供了WebService（Remoting）服務，則BAS必須提供BAS.Entrance.dll。 BAS.Entrance.dll封裝了與BAS服務交換信息的通訊機制，客戶系統只要經過BAS.Entrance.dll就能夠很是簡便地訪問BAS 提供的服務。

     3．若是BAS須要經過WebService（Remoting）回調客戶系統，則必須提供僅僅定義了接口的BAS.CallBack.dll，客戶系統將引用該dll，實現其中的接口，並將其發佈爲服務，供BAS回調。

     4．當WebService的參數或返回值須要是複雜類型――即架構圖中的Service Entity，則Service Entity應該在對應的BAS.EntranceParaDef.dll或BAS.CallBackParaDef.dll中定義。 WebService定義的方法中的複雜類型應該使用Xml字符串代替（注意，Entrance和CallBack接口對應服務的方法的參數是強類型 的），而Xml字符串和複雜類型對象之間的轉換應當在BAS.Entrance.dll或BAS.CallBack.dll中實現。

 

 

 

　　以前用一張圖分析了Google給出的MVP架構，可是在Google給出的全部案例裏面除了基本的MVP架構還有其它幾種架構，今天就來分析其中的Clean架構。一樣的，網上介紹Clean架構的文章不少，我也就不用文字過多敘述了，仍是用一張類圖來分析一下Clean架構的這個案例吧。好了，先直接上圖！

 

　　

 

　　上完圖，再說一說我對Clean架構的一個理解吧。對比前一篇文章的MVP架構圖能夠看出，clean在必定程度上繼承了mvp的設計思想，可是其抽象程度比mvp更高。初次看這個demo的時候，確實被震撼了一下——原來用Java能夠這樣寫代碼！！！跟以前用的一些項目框架和我本身平時寫的一些代碼對比一下，只能感嘆clean的這種設計思想真不是通常的程序員能夠想出來的。它對接口、抽象類和實現類之間的實現、繼承、調用關係發揮到了一個比較高的層次，它並非像咱們平時寫代碼那樣很直白地寫下來，而是充分利用了面向對象的封裝性、繼承性和多態性，是對面向對象思想的一個高度理解。其實，要說clean複雜，它確實有些難理解，但是若是你真的理解了面向對象思想，那麼又會以爲這樣的設計徹底在情理之中。

 

 

      最近幾個月都沒有整理Blog，都忙着整理總結以前一段時間作的項目和學習的內容，而後想到把這些東西融合在一塊兒，設計一個開發框架。

這個框架用到了一些.NET社區比較前沿的技術，好比ORM, IOC容器, AOP攔截等，在.NET 2.0的基礎上構建了一個.NET Remoting的分佈式開發框架。

項目開發最關注的就是開發效率，其次是項目的可管理可控性，最後是架構的可擴展性。我但願在個人框架設計中可以將這三者很好的整合在一塊兒。

大體的思路是：

一、可擴展性：經過IOC容器的使用下降項目中各個模塊之間的依賴性；用領域模式來設計業務核心層，下降業務層對數據層和界面層的耦合度；分佈式選擇Remoting爲主，能夠再包裝爲WebService或者直接發佈爲WebService。

二、將敏捷的項目管理思路引入到框架中，框架充分支持TDD測試驅動和運行日誌驅動，爲敏捷管理提供技術支持。

三、初步經過AOP技術減小和核心業務無關的系統級代碼：如事務處理、異常處理、日誌記錄等；並在未來爲架構提供可視化的代碼配置生成工具，以最快的速度構建項目的主體結構，並儘量大的增大靈活性。

      目前框架的主體已經完成，也從新整理VSS上的項目結構，並從新命名爲LightningFramework。正在作細節調整，接下來的時間會逐步完成相關文檔和演示程序。下面是主架構圖：