各種體系架構圖收藏

該技術架構圖是本人根據多年企業技術架構經驗而制定，是企業技術的總架構圖，希望對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架構特色

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架構面臨的大部分技術問題，讓開發者可以專注于業務邏輯和業務流程的開發，而無需關心純技術問題

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

下面是個人了解的做架構的幾個要點：

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。正在做細節調整，接下來的時間會逐漸完成相關文檔和示範程式。下面是主架構圖：

• 首頁
• 部落格
• 學院
• 下載下傳
• 圖文課
• 論壇
• APP
• 問答
• 商城
• VIP會員
• 活動
• 招聘
• ITeye
• GitChat

• 寫部落格

  快來寫部落格吧 ヽ(✿ﾟ▽ﾟ)ノ

• 

  賺零錢

• 

  消息

• 

原

想要做”架構師“，一定要會畫設計圖

2018年03月05日 16:46:07 互扯程式 閱讀數：9752

版權聲明：本文為部落客原創文章，主要是為了交流學習，轉載請注明出處。 https://blog.csdn.net/mxw2552261/article/details/79447798

什麼是系統架構師？ 

系統架構師是一個既需要掌控整體又需要洞悉局部瓶頸并依據具體的業務場景給出解決方案的團隊上司型人物。一個架構師得需要足夠的想像力,能把各種目标需求進行不同次元的擴充，為目标客戶提供更為全面的需求清單。

架構師在軟體開發的整個過程中起着很重要的作用。

如何才能成為系統架構師？

1. 首先必須具有豐富的軟體設計與開發經驗，這有助于了解并解釋所進行的設計是如何映射到實作中去。

2. 其次要具有上司能力與團隊協作技能，軟體架構師必須是一個得到承認的技術上司，能在關鍵時候對技術的選擇作出及時、有效的決定。

3. 第三是具有很強的溝通能力，其實這一點好像什麼角色都最好具備，軟體架構師需要與各路人馬經常打交道，客戶、市場人員、開發人員、測試人員、項目經理、網絡管理者、資料庫工程師等等，而且在很多角色之間還要起溝通者的作用。 

而設計圖，它不是簡單的供你欣賞，他其實是架構師，産品經理，開發工程師，測試工程師等各種角色之間進行溝通的語言，溝通的一個橋梁，讓整個團隊更能有效的協調工作。

設計圖不單單是架構師要掌握的，在一個産品的開發過程中，任何一個環節，任何一個角色都可以通過掌握不同的設計圖來完成溝通的。

流程圖

流程是一系列的邏輯關系（包含因果關系、時間先後、必要條件、輸入輸出）産品經理做需求前一定要先把這些邏輯關系理清楚，如果非要用一句話概括的話“流程就是在特定的情境下滿足使用者特定需要的總結”。

圖就是将你頭腦中的邏輯關系以圖形化的形式呈現出來，具有圖形化、可視化的特點，因為是圖，你可以像你的版本疊代一樣，當你的邏輯需要修改的時候拿出來疊代一下，同時因為有圖，你還可以更好的給項目成員進行宣講。

産品中設計的流程圖主要有三種，業務流程圖、任務流程圖、頁面流程圖，下面我們來一一介紹。

業務流程圖

業務流程圖又稱為泳道圖，就是描述那些個體在什麼條件下做了什麼事情，他們之間有何關聯。主要分三個方面：

1. 涉及到哪些主體？

2. 每個主體都有哪些任務？

3. 各個主體之間怎麼聯系的？一般涉及到多個主體，每個主體之間有聯系。

 任務流程圖 

泳道圖一般是從戰略上分析整個業務流程，讓你對公司所做的業務有個大概的了解，而任務流程圖就是在你的産品操作上，使用者通過什麼樣的操作來完成它的目标，比如你去銀行ATM機器上取錢，你是如何一步步操作把錢取出來的。

頁面流程圖

如果說業務流程圖幫助你梳理戰略，任務流程圖幫助你梳理使用者操作行為（主要給程式員看）、頁面跳轉流程在幫助你梳理各個頁面之間的跳轉關系（主要給UI和前端程式員看）這是一個逐漸從整體到局部，從後端到前端的過程。

所有的産品都是由頁面組成的，不論是APP、PC、H5都是由一個個頁面組成的，頁面流程圖描述完成一個任務需要經過哪些步驟，你在畫圖的時候隻需要清晰的表現出使用者點選頁面的什麼地方，然後跳轉到那個頁面。主要由頁面、行動點、連接配接線組成。

UI設計圖示注

對于APP的頁面，UI設計師會給出UI設計标注圖，這樣APP用戶端開發人員，直接按照标注圖進行頁面的開發了。

産品設計完成後，架構師需要對産品進行軟體的架構設計。包括技術的選型，子產品的劃分，開發人員的任務配置設定，工作量的評估等等.....

系統架構設計圖

構架将在一次又一次疊代中不斷演化、改進、精煉。

序列圖

架構師一般在做詳細設計的時候，會把程式子產品之間的每一步調用過程很詳細的畫出來，這樣開發人員拿到設計文檔，就能直接開發。

類圖

設計圖有很多種，還包括用例圖，狀态圖，活動圖...... 不再一一介紹。畫什麼樣的設計圖，不是絕對的，不同公司，不同項目，需要畫的設計圖也是不同的，有些項目需要畫原型圖，有些項目隻是對外提供服務，沒有頁面也就不需要畫原型圖。另外還要根據項目的工期，預算等等因素考慮。如果一個項目的工期也就一個月甚至更短，那基本上就是怎麼簡單怎麼快就怎麼做。

畫圖工具

‘工欲善其事,必先利其器’，下面就為大家介紹幾款常用設計圖繪制工具。以下軟體都可以在微信公衆号，回複“設計”，擷取破解版本。

Visio

是微軟推出的一款流程圖繪制工具，它有很多元件庫，可以友善快捷的完成流程圖、泳道圖、結構圖的繪制，但是不支援mac電腦。

OmniGraffle

Mac下沒有Visio很多人就用這個，這個一般流程圖都能繪制，但是效率感覺沒有Visio高，優點就是畫出來的圖形比較美，同時支援外部插件，缺點就是沒有比較好的泳道流程圖插件，畫起泳道圖來不是太友善，但也可以畫，可以自己組裝泳道。

另外一個缺點是收費的，隻能免費試用15天，不過我已經為大家準備好了一個最新的破解版本。 

ProcessOn

是一款網頁版的線上作圖工具，優點是無需下載下傳安裝、破解這些破事，同時支援線上協作，可以多人同時對一個檔案協作編輯，而且上手比較容易，它提供很多流程圖模版，可以友善的畫出流程圖、思維導圖、原型圖、UML圖，缺點就是在繪制泳道圖需要增加泳道的時候，隻能在最後一列加入，不能在中間加入這一點有點麻煩，還有要吐槽的就是由于是線上的，有時候導出圖檔，導出來的并不太好，流程圖畫的大的時候也無法截圖。

線上位址：https://www.processon.com

Axure RP

這是一款産品經理經常用來畫原型的工具，它可以在頁面裡定義各種按鈕點選事件，進行頁面的跳轉，模拟送出的過程，是以非常友善使用。畫人物流程圖的時候也可以用，但是要畫泳道圖、UML圖的時候，沒有對應的模版，需要自己畫，效率不高，如果你覺得畫原型，制作文檔都在Axure裡，不想來回切換軟體的畫，可以在裡面自己制作一個元件，下次直接調用。

Axure RP是可以畫出這樣效果的原型圖

PxCook

一款還不錯的标注工具.

優點：

1. 成熟：跨平台——支援Windows和Mac

2. 成熟2：支援PS和Sketch。

3. 互動特别智能，也友善，一拖一放就标注完了。

4. 相當需要說的一點：對于PSD檔案或者Sketch進行了修改之後，PxCook裡的标注會自動進行更新，免除了手動操作的過程。這是後面很多軟體沒有的。

5. 支援移動裝置的多機關切換。

缺點：

1. 不能支援多個檔案同時進行标注。

2. 對于圖層樣式等資訊，不能進行詳細檢視。 

​

iThoughtsX

一款優秀的思維導圖工具

OmniPlan

最NB的項目管理流程軟體，OmniPlan旨在幫助您可視化，維護和簡化您的項目。分解任務，優化所需的資源，控制成本，并監控您的整個計劃，都一目了然。協作與您的同僚和分享每一個細節，更新月曆與你的天關，或混搭。接受和拒絕一次過改變一個接一個或所有。

 OmniPlan提供了像甘特圖，時間表，摘要，裡程碑和關鍵路徑的功能突出顯示，讓您管理您的所有活動。從自定義的視圖來快速輸入資料， OmniPlan幫助您管理，因為你需要他們，簡單或複雜的項目是 - 不需要複雜。

系統架構圖的通用設計方案：

系統采用四層架構設計

一、展現層

1. Web前端 基于HTML/HTML5/Vue/CSS3開發web前端頁面，相容主流浏覽器。展現層和資料層完全分離，通過跨域實作前後端資料通信。
2. APP android，ios 基于原生開發。在app端實作https鍊路請求優化，做防盜鍊和DNS劫持處理。
3. 微信公衆号/微信小程式 更新業務需要，将部分資料以微信公衆号+H5的方式展現；涉及硬體裝置控制功能的系統部分子產品采用微信小程式，增加使用者操作體驗和通路便捷性。
4. Restful接口 基于特定業務，采用Restful标準接口，對外提供資料服務。

二、通訊層

1. 基于阿裡雲CDN實作靜态資料加速；
2. 基于阿裡雲SLB，實作伺服器負載均衡；
3. 基于TCP/HTTP/HTTPS 三種通信方式，實作前後端資料通信。其中，TCP基于Netty實作；

三、服務層

核心業務基于Spring Cloud 架構實作微服務化。

Spring Cloud是一個基于Spring Boot實作的雲應用開發工具，它為基于JVM的雲應用開發中的配置管理、服務發現、斷路器、智能路由、微代理、控制總線、全局鎖、決策競選、分布式會話和叢集狀态管理等操作提供了一種簡單的開發方式。

微服務是可以獨立部署、水準擴充、獨立通路（或者有獨立的資料庫）的服務單元，springcloud就是這些微服務的大管家，采用了微服務這種架構之後，項目的數量會非常多，springcloud做為大管家需要管理好這些微服務。

相關的元件包括如下：

1、Netflix Eureka：

服務中心，雲端服務發現，一個基于 REST 的服務，用于定位服務，以實作雲端中間層服務發現和故障轉移

2、Netflix Hystrix：

熔斷器，容錯管理工具，旨在通過熔斷機制控制服務和第三方庫的節點,進而對延遲和故障提供更強大的容錯能力。

3、Netflix Zuul：

是在雲平台上提供動态路由,監控,彈性,安全等邊緣服務的架構。Zuul 相當于是裝置和 Netflix 流應用的 Web 網站後端所有請求的前門，具有攔截和路由功能。

4、Netflix Archaius：

配置管理API，包含一系列配置管理API，提供動态類型化屬性、線程安全配置操作、輪詢架構、回調機制等功能。可以實作動态擷取配置，原理是每隔60s（預設，可配置）從配置源讀取一次内容，這樣修改了配置檔案後不需要重新開機服務就可以使修改後的内容生效，前提使用archaius的API來讀取。

5、Spring Cloud Config：

俗稱的配置中心，配置管理工具包，讓你可以把配置放到遠端伺服器，集中化管理叢集配置，目前支援本地存儲、Git以及Subversion。

6、Spring Cloud Bus：

事件、消息總線，用于在叢集（例如，配置變化事件）中傳播狀态變化，可與Spring Cloud Config聯合實作熱部署。

7、Spring Cloud Sleuth：

日志收集工具包，封裝了Dapper和log-based追蹤以及Zipkin和HTrace操作，為SpringCloud應用實作了一種分布式追蹤解決方案。

8、Spring Cloud Task：

主要解決短命微服務的任務管理，任務排程的工作，比如說某些定時任務晚上就跑一次，或者某項資料分析臨時就跑幾次。

四、資料層

1. mongodb：存儲非結構化、關聯性弱的業務資料。如，控制器下發的指令資料，監測裝置收集的傳感器資料，
2. mysql：存儲事務性資料，以及關聯性将強的資料。如，訂單、資金、交易資料；
3. HDSF：存儲監控裝置上傳的圖檔和視訊，以及報表檔案；
4. ElasticSearch：實作ELK，存儲日志資料；

其他：

1、認證系統：

采用雙token的方式完成jwt。其中accessToken 用于使用者身份認證。refreshToken用于當accessToken失效時重新生成。

使用者登入：

token認證通路（accessToken有效）

token認證通路（accessToken失效，refreshToken有效）：

accessToken和refreshToken 都失效

2、日志系統：

日志集中化管理，采用ELK解決方案。

Elasticsearch：是個開源分布式搜尋引擎，提供搜集、分析、存儲資料三大功能。它的特點有：分布式，零配置，自動發現，索引自動分片，索引副本機制，restful風格接口，多資料源，自動搜尋負載等。

Logstash ：主要是用來日志的搜集、分析、過濾日志的工具，支援大量的資料擷取方式。一般工作方式為c/s架構，client端安裝在需要收集日志的主機上，server端負責将收到的各節點日志進行過濾、修改等操作在一并發往elasticsearch上去。

Kibana ：也是一個開源和免費的工具，Kibana可以為 Logstash 和 ElasticSearch 提供的日志分析友好的 Web 界面，可以幫助彙總、分析和搜尋重要資料日志。

3、會話治理

此處的會話是指Netty 會話管理。實作Channel自定義會話管理，如會話監控、會話逾時、會話重建等。

4、DNS劫持處理

移動端産品在實際使用者環境下會面臨 DNS 劫持、耗時波動等問題，這些 DNS 環節的不穩定因素，導緻後續網絡請求被劫持或是直接失敗, 對産品的使用者體驗産生不好的影響。

DNS 有 LocalDNS VS HTTP DNS之分

在長期的實踐中，網際網路公司發現 LocalDNS 會存在如下幾個問題：

• 域名緩存: 營運商 DNS 緩存域名解析結果，将使用者導向網内緩存伺服器;
• 解析轉發 & 出口 NAT: 營運商 DNS 轉發查詢請求或是出口 NAT 導緻流量排程政策失效;

為了解決 LocalDNS 的這些問題，業内也催生了 HTTP DNS 的概念，它的基本原理如下:

原本使用者進行 DNS 解析是向營運商的 DNS 伺服器發起 UDP 封包進行查詢，而在 HTTP DNS 下，我們修改為使用者帶上待查詢的域名和本機 IP 位址直接向 HTTP WEB 伺服器發起 HTTP 請求，這個 HTTP WEB 将傳回域名解析後的 IP 位址。

比如 DNSPod 的實作原理如下:

相比 LocalDNS, HTTP DNS 會具備如下優勢:

• 根治域名解析異常: 繞過營運商的 DNS，向具備 DNS 解析功能的 HTTP WEB 伺服器發起查詢;
• 排程精準: HTTP DNS 能夠直接擷取到使用者的 IP 位址，進而實作準确導流;
• 擴充性強: 本身基于 HTTP 協定，可以實作更強大的功能擴充;