
FS ( FunctionServer ),功能服務器,處理并且僅處理所有的功能性請求,不參與用戶管理、狀態保持等,提供最純粹的功能服務。
AS ( ApplicationServer ),應用服務器,轉發所有的功能請求給 FS ,并處理所有的非功能請求,并管理終端用戶、進行狀態保持、日志記錄等。
上圖中的功能服務器 FS 的個數可能是 0 到 N ( N>0 )個。在某種意義上可以認為,每個功能服務器 FS 是可以互換的。
將服務器拆分為功能服務器和應用服務器有兩個顯而易見的好處:
(1) 功能服務器 FS 的完全可復用。由于功能服務器采用“框架+插件”的結構,所以整個功能服務器是完全可復用的,從一個具體應用轉換到另一個具體應用,只需要替換功能插件即可, FS 不需重新編譯。
(2) 由于 FS 僅提供最純粹的功能服務,不需要進行用戶管理、狀態保持,這種功能服務器在運行時的無狀態性,使得功能服務器很容易實現負載均衡集群(后文中會講到,這種動態負載均衡是如何實現的)。
如果 ESFramework 僅僅做到這一步,就沒有必要拿出來和大家分享了, ESFramework 不僅對這種 4 層架構給予了充分完整的支持, ESFramework 更進了一步,它可以支持“類似地域分布式”的體系結構。讀者可能已經了解到,上面的 4 層架構已經是一種分布式架構了,那么這里說的“類似地域分布式”又是什么意思?
可以這么說,
4
層架構是一種“縱向”的架構,“類似地域分布式”則側重于“橫向”,在“類似地域分布式”體系結構中,每一個具體的“
4
層架構的實現”只是其中的一個組成元素。我舉個例子,現在我們的一個應用需要為全國范圍內的所有大城市的手機用戶提供某種基于
C/S
的手機增值服務。我們的經驗是,為每個城市配置一個應用服務器
AS
,由于大量的計算在該
AS
對應的
FS
上,所以可能需要多個
FS
為這個
AS
服務。而每個城市的
AS
之間可能需要相互通信(比如處理漫游用戶),這就需要將
AS
也管理起來,管理
AS
的服務器是
IRAS
(跨區域服務器)。如此一來,我可以畫出下圖作為例子:
圖中的
FunAddin
是
功能插件
,這再前文已介紹過了。整個體系中,終端請求的服務主要分為兩大類,一是向應用服務器
AS
請求功能服務,另一類是終端與終端之間的非功能通信。所有的功能服務由功能插件(
FunAddin
)進行處理,所有的非功能通信由應用服務器處理或中轉。如果,終端請求的功能服務位于外部系統,則功能插件會自動定位外部系統的地址,然后通過
WebService
等方式向外部系統提交請求。
好了,讀者已經了解了
ESFramework
中的
4
層結構和“類似地域分布式”結構是怎么回事了,下面我簡單概述一下
ESFramework
對
4
層結構和“類似地域分布式”結構提供了哪些強有力的特性支持:
1.
基于構件
除了所有的功能插件是構件外,整個
ESF
平臺也是由構件組裝而成。其好處是:
(1)
快速搭建系統
(2)
促進構件復用,如
AS/IRAS/FS/IRFS
可以使用同一個通信組件來完成通信層工作。
(3)
實現功能插件的“熱插拔”,可以在運行時動態的添加
/
移除功能服務
2.
高度可擴展
由于
ESF
服務平臺體系需要隨時隨地的應付各種突如其來的變化,其一定要具備高度的可擴展性:
(1)
功能插件的“熱插拔”
(2)
外部服務的動態接入(通常是通過
WebService
)
(3)
應用服務器
AS
的動態添加
/
移除,比如,新開通針對大連城市的服務。
(4)
功能服務器
FS
的動態添加
/
移除,實現功能服務器的動態負載均衡集群。
3.
高度可伸縮
隨著我們提供的服務日漸深入人心,我們的用戶的數量會急劇增加,所以
ESF
服務平臺體系必須具備高度可伸縮性來提高系統的最大負載和吞吐量。
(1)
由于功能服務器需要進行大量的功能運算,所以平臺的瓶頸通常位于功能服務器,這可以通過功能服務器的動態集群來解決。集群中的各個功能服務器之間的負載均衡由對應的應用服務器
AS
來調度。
(2)
當單個區域的常在線用戶數量突破
5000
~
10000
時,我們需要添加
AS
進行區域級的負載均衡,這可以通過具有端口映射功能分硬件來解決。
4.
高度可復用
ESF
服務平臺體系并非只是適用于我們的
LBS
服務,其實,
ESF
服務平臺體系是一個高度可復用的體系,也就是說
ESF
服務平臺可以作為任何、任意的服務的基本平臺,只要其所提供的服務是終端和服務器之間通過
Tcp
進行基于連接的通信。
5.
分布式
除了外部系統的接入通過分布式服務進行外,各應用服務器之間、功能服務器與應用服務器之間、應用服務器和跨區域的應用服務器之間都是采用分布式通信。跨區域的應用服務器通過類似于
remoting
的方式在各個應用服務器之間進行調度。
6.
簡單部署、自動升級
由于
ESF
服務平臺體系服務的區域可能非常多,比如各個大城市可能都需要部署應用服務器和功能服務器,所以如果通過人工進行部署和升級是非常低效的,
ESF
服務平臺提供了自動升級、加載、運行的功能。
(1)
服務平臺安裝后,僅僅需要修改配置文件中的幾個參數即可正常運行。
(2)
當功能插件擁有新版本的時候,可以在不停止服務的情況下,自動升級到新版本。
(3)
當各服務器系統(
AS/IRAS/FS/IRFS
)有新版本時,會在該系統重啟的時候自動升級到新版本。為了在升級的時候不終止服務,服務器系統可以使用逐步升級的方式。
7.
通信保證機制
當遇到網絡突然斷開或某服務器重啟的情況,在網絡恢復或服務器重啟完成后,需要一種能自動的立即恢復通信(比如AS和FS的通信,各AS與IRAS之間的通信)的機制,
ESF
服務平臺提供了這種保證,其采用的策略主要基于:
(1)
定時論詢
(2)
Tcp
連接池自動重連
(3)
連接動態反轉
8.
漫游支持、跨區域功能請求支持
在
ESF
服務平臺體系中,漫游是指某一區域的用戶登錄到另外一區域的應用服務器
AS
上,對于此
AS
來說,該用戶是漫游用戶。如果用戶登錄到某
AS
卻請求其它區域的功能服務,則是跨區域的功能請求。
ESF
服務平臺對這兩種情況都給予了充分的支持。
9.
終端與終端之間的通信支持
有時,終端需要和終端(可能是同區域的、也可能是其它區域的)之間進行通信,并且這種通信可以基于連接和基于非連接。基于連接的通信像實時視頻聊天、實時監控,基于非連接的像發送一張圖片給不在線的用戶。所有這些,
ESF
服務平臺都提供了支持。
10
.支持二次開發
在基于
ESF
服務平臺高度可復用和可擴展的基礎上,
ESF
平臺可以非常容易的支持二次開發,只要遵循相同的接口和通信協議,就可在
ESF
平臺進行二次開發。
11
.客戶端框架
如果應用的客戶端也可以使用
.NET
開發,則
ESFramework
也提供了完善的支持,在
ESFramework
的支持下,開發客戶端僅僅需要開發業務插件就可以了,而整個網絡通信、多線程、升級部署等,都由框架完成了。后面的文章中我會介紹如何在
AgileIM
中開發自定義的業務插件。
上面的所有特性將會在“
基于
C/S
的
4
層架構
”部分分節介紹,感謝關注!
如果你的應用不需要這么復雜的結構,比如僅僅一個簡單的3層架構,那么ESFramework仍然可以幫助你快速構建,ESFramework是個輕量級的應用框架,你不會為那些ESFramework提供了的而你不需要的功能/特性付出任何代價。
(注意,ESFramework不太適合處理遺留系統(就像你很難使用MFC去處理基于VCL構建的UI應用一樣),ESFramework雖然與應用無關,但是為了能將更多的任務從應用中抽象到框架中來,必須對應用做一些假設,幸運的是,ESFramework僅僅對應用的通信協議做了最少的假設,這個假設包含在
NetMessage
中。如果你不是處理遺留系統,而是構建一個全新的C/S應用,那么ESFramework可以為你節省大量的架構設計時間、軟件開發時間、調試和維護時間。)
(最后做個廣告,如果你新接手的項目非常適合采用上面介紹的
4
層架構或“類似地域分布式”體系結構,希望我們有合作的機會:)通過
agilesoft@163.com
聯系我)
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索:z360901061

微信掃一掃加我為好友
QQ號聯系: 360901061
您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。
【本文對您有幫助就好】元
