軟件各種架構圖收集
發布一企業技術架構圖，供大家參考。
該技術架構圖是本人根據多年企業技術架構經驗而制定，是企業技術的總架構圖，希望對CTO們有所借鑒。
簡單說明：
1.中間件基礎運行環境是經過統一規劃的以WebLogic、JBOSS為主的集群環境
2.企業集成平臺是以基礎業務應用為基礎服務於上層平臺和基礎業務應用的高度集成平臺
3.數據中心是企業公共數據的集中管理比如用戶數據、企業編碼，可以通過數據集成平臺或服務集成平臺分發給其他應用
項目做了不少,都沒畫過架構圖,這次被要求畫圖,畫的很醜,請大家看圖本身包含的系統架構信息
一、架構整體圖
1、核心是兩庫一線
1.1 接口總線
所有算法功能抽象成接口,其中大部分接口的方法都是泛型方法,是為了解決某一大類問題的
1.2 代碼庫
代碼庫包含現接口總線中接口的各種實現
1.3 應用庫
提供用戶的界面或者提供給外部的服務
是通過容器配置調用算法庫中的代碼來實現的各種應用
二、應用關系圖
1、應用通過配置從應用庫中組裝出自己的應用系統
2、應用本身之外的東西盡量使用攔截器處理(授權訪問、權限數據推送、異常處理、緩存、日誌等)
3、使用消息隊列做高並發應用支撐(秒殺類似應用)
4、使用分布式任務系統做周期作業、數據維護、數據計算等
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框架特色
- 一個DDD開發框架，完美支持基於六邊形架構思想的開發
- 實現CQRS架構思想，並且框架提供C端命令的處理結果的返回，支持同步返回和異步返回
- 內置Event Sourcing（ES）架構模式，讓C端的數據持久化變得通用化
- 聚合根常駐內存，in-memory domain model
- 聚合根的處理基於Command Mailbox, Event Mailbox的思想，類似Actor Model, Actor Mailbox
- 嚴格遵守聚合內強一致性、聚合之間最終一致性的原則
- Group Commit Domain event
- 基於聚合根ID+事件版本號的唯一索引，實現聚合根的樂觀並發控制
- 框架保證Command的冪等處理
- 通過聚合根ID對命令或事件進行路由，做到最小的並發沖突、最大的並行處理
- 消息發送和接收基於分布式消息隊列EQueue，支持分布式部署
- 基於事件驅動架構範式（EDA，Event-Driven Architecture）
- 基於隊列的動態擴容/縮容
- EventDB中因為存放的都是不可變的事件，所以水平擴展非常容易，框架可內置支持
- 支持Process Manager（Saga），以支持一個用戶操作跨多個聚合根的業務場景，如訂單處理，從而避免分布式事務的使用
- ENode實現了CQRS架構面臨的大部分技術問題，讓開發者可以專註於業務邏輯和業務流程的開發，而無需關心純技術問題
晚上把公司應用的架構結合之前研究的東西梳理了下，整理了一張架構規劃圖，貼在這裏備份
下面是個人理解的做架構的幾個要點：
1、系統安全
這是首要考慮的，以這張圖為例，網絡劃分為3個區：
a) DMZ區可以直接公網訪問，也可以 與App Core區互通，但不能直接與DB Core區互通 (通常這裏放置 反向代理Web服務器)
b) App Core區能與DMZ區、DB Core區互通，但是無法直接從公網訪問 (通常這裏放置 應用服務器、中間件服務器之類)
c) DB Core區僅與App Core區互通 (通常這裏放置 核心數據庫)
2、盡量消除單點故障
上圖中，除了“硬件負載均衡”節點外，其它節點都可以部署成集群（DB有點特殊，傳統RDBMS要實現分布式/集群還是比較困難的，要看具體采用的數據庫產品，並非所有數據庫都能方便的做Sharding），Jboss本身可以通過Domain模式+mod_cluster實現集群、Redis通過Master/Slave以Sentinel方式可以實現HA、IBM MQ本身就支持集群、FTP Server配合底層儲存陣列也可以做到HA、Nginx靜態資源服務器自不必說
3、成本
盡量采用開源成熟產品，jboss、redis、nginx、apache、mysql、rabbit MQ都是很好的選擇。硬件負載均衡通常成本不低，但是效果明顯，如果實在沒錢，域名解析采用DNS輪詢策略，也能達到類似效果，只不過可靠性略差。
4、Database問題
常規企業應用中，傳統關系型數據仍然是主流，但是no-sql經過這幾年發展，技術也日漸成熟了，一些非關鍵數據可以適當采用no-sql數據庫，比如：系統日誌、報文歷史記錄這類相對比較獨立，而且增長迅速的數據，可以考慮存儲到no-sql db甚至HDFS、TFS等分布式開源文件系統中。
如果系統數據量級達到單機RDBMS的上限，盡早考慮Sharding方案，目前mysql在這方面比較成熟，其它數據庫就不好說了。
5、性能
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;支持多種常用的音頻、視頻格式錄制和回放，編碼格式包括MPEG4、MP3、H.264、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請求流程
1、客戶端發送請求
2、請求先通過ActionContextCleanUp-->FilterDispatcher
3、FilterDispatcher通過ActionMapper來決定這個Request需要調用哪個Action
4、如果ActionMapper決定調用某個Action，FilterDispatcher把請求的處理交給ActionProxy，這兒已經轉到它的Delegate--Dispatcher來執行
5、ActionProxy根據ActionMapping和ConfigurationManager找到需要調用的Action類
6、ActionProxy創建一個ActionInvocation的實例
7、ActionInvocation調用真正的Action，當然這涉及到相關攔截器的調用
8、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.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中實現。
之前用一張圖分析了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的分布式開發框架。
項目開發最關註的就是開發效率，其次是項目的可管理可控性，最後是架構的可擴展性。我希望在我的框架設計中能夠將這三者很好的整合在一起。
大致的思路是：
1、可擴展性：通過IOC容器的使用降低項目中各個模塊之間的依賴性；用領域模式來設計業務核心層，降低業務層對數據層和界面層的耦合度；分布式選擇Remoting為主，可以再包裝為WebService或者直接發布為WebService。
2、將敏捷的項目管理思路引入到框架中，框架充分支持TDD測試驅動和運行日誌驅動，為敏捷管理提供技術支持。
3、初步通過AOP技術減少和核心業務無關的系統級代碼：如事務處理、異常處理、日誌記錄等；並在將來為架構提供可視化的代碼配置生成工具，以最快的速度構建項目的主體結構，並盡可能大的增大靈活性。
目前框架的主體已經完成，也重新整理VSS上的項目結構，並重新命名為LightningFramework。正在做細節調整，接下來的時間會逐步完成相關文檔和演示程序。下面是主架構圖：
軟件各種架構圖收集