該技術架構圖是本人根據多年企業技術架構經驗而制定，是企業技術的總架構圖，希望對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。正在做細節調整，接下來的時間會逐漸完成相關文檔和示範程式。下面是主架構圖：