各種軟體系統架構圖解析
釋出一企業技術架構圖，供大家參考。
該技術架構圖是本人根據多年企業技術架構經驗而制定，是企業技術的總架構圖，希望對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架構圖
請求首先通過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。正在做細節調整，接下來的時間會逐步完成相關文件和演示程式。下面是主架構圖：