最近因為工作的關係,從新思考3層式架構的問題,因為當初使用3層來開發應用 程式,但是因為中間層不穩定,以致最後回到2層,很穩定,不過使用者數越來越多 最近到了500~600,IBM AIX主機資源越來越吃緊,讓我想起可能的解決方案,其中 3層式架構似乎是可行的,但是經過一番搜查資料,也看過訊光EEP,我有一個重大 發現~~~~純用Delphi來開發多層式架構,有一個致命缺點,~~~~就是大家拿ap server沒折,頂多重新開機,要查裡面的連線狀態,使用者資訊,資源耗用,在管理 面上可說是空白一片,大家只能盯著Socket Server畫面乾著急,最後使出一項法 寶--重新開機,這對MIS人員是多大的壓力,是軟體公司很難體會的,公司越大使用 者越多,壓力就呈級數增加,以我們公司的標準來說,伺服器主機頂多1年只能重開 機2次,多了就已經是很大條的事了,從這樣看,我只能說,Borland的Socket server祇能算是玩具而已,所以我又對Borland能否有所謂企業級的Application Server支援查資料,但目前好像只支援JBuilder,Delphi好像沒有支援,然後又看 到一則不幸的馬路消息,Borland在Application Server市場上搶不贏,所以把精 力花在系統整合開發,所以有ECO,together等東西~~所以唉,3層式架構前途不太 光明,眾程式設計大師,就Delphi上的Application Server管理不知有何解答呢?

Socket Server 本身的确只是个玩具。 中间层，如果对效率要求高，最好自己用DELPHI来写COM 元件来作为中间层。 也可以直接把中间层写成CGI/ISAPI的WEB SERVICES 写成ISAPI的话，效率会比较高，但比较考验功力，写得不好的话，容易出问题。 写成CGI的话，需要注意的地方比较少。

pcplayer99謝謝你的回應,不過,我想表達的是,如果中間層由自己來寫的話,我也 曾經想過,但是那也是玩具,比Borland這種大公司寫的Socket Server更可笑,李 維大師在他的書中,也提過如何提昇中間層的效能,如Pooling,Load Balance等等 ,的確沒錯,範本抄抄改改可組成一個似乎像樣的程式,但是我的重點是,我們有可 能寫一個管理機制,像UNIX可以下指令,或是Shell,或是AWK等工具來管理我們的 Application Server嗎?答案很肯定是不可能的,不然,IBM是混飯吃的嗎?我想我 要的就是類似UNIX強大又穩定的Application Server使整個系統架構在真正穩定 的環境,且可讓我們有充分的工具做故障排除機制,並有完整的資訊可供查詢記 錄,這豈不是每一位MIS人員所期望的嗎?希望有經驗的諸位大大提供意見謝謝

你的希望就是 borland 做不到的。^_^ 除了標準元件以外。它所擴充的元件，有幾個是像樣的？ 可是用了它，你又會發現很難跟 SDK 並用。 不怎麼好整合。 所以。我當年就把很多程式移到 FreeBSD 上去了。 利用 CGI, socket 這些東西來處理。 開發會慢一點。 使用上還不會出什麼問題。

一般我們在做系統專案開發的時候,往往會決定要採用何種架構, 二層/三層架構,決定架構的因素有很多種,絕大多數會採用新的架構模式(例如三層式架構)對於每一架構的優勢與劣勢開發人員是否有真正去做評估. 我們先分成幾方面來探討: 1.系統穩定度:不論是二層或三層架構,決定穩定度的最大關鍵是在於系統的設計,以及程式的品管是否確實.一般都會認為三階比二階不穩定,最大因素是在於程式開發者根本不懂開發應用伺服器,只是拿個元件隨便剪剪貼貼或者把書上的範例抄一抄改一改,也根本不知到自己在做啥,在使用者很少時感覺上還好,人一多問題就來了;二層架構(C/S架構)本身不需AP Server去處理講白一點就是把AP Server放在每個User的電腦,當出現問題時也不過是當掉該User的電腦. 2.負載平衡力:Borland 號稱具備有負載平衡能力做法,我們可以從任何書上或者網路上找到資料實際上應該沒有人會真正去檢驗她的副載平衡是否真的如書上所講.我們所需副載平衡的評定標準為何,主機的處理能力,記憶體空間,網路寬.... 3.了解系統的極限:我們寫程式的人是否能了解自己寫的程式她的極限在哪,如在程式高用量的時候記憶體會佔多少,釋放時記憶體是否完全釋放;Socket Server的極限可以連接多少Connect,這又會牽扯TCP/IP協定,那是否有人真正去了解... 4.錯誤處理機制:當我們採用三階架構時,在設計AP Server是否有規劃錯誤處理機制,絕大部分是不會去設計的.在二階架構中這個錯誤處理機制是由資料庫引擎或者由資料庫幫我們處理這些已經行之許多年,當然錯誤就少;我們自己設計的根本沒有經過市場的鍛鍊所以有需多地方是沒有考慮的. 其實要設計一個好的AP Server並不困難,困難的是程式開發員是否願意花時間去充實自己底層的知識,而不是一昧靠元件或者是更新版的開發工具(如Delphi 7,Delphi 2005,Delphi xxx ....)來解決問題,那些只能治標而不是真正解決問題之道.

呵呵,ccl大說的沒錯,我們都知道系統實做前的分析功課,是很重要的,但是我們又知道有誰在一大堆案子的壓力下,有那種美國時間去try,每一個所謂不錯的系 統都是經過一堆可憐的白老鼠企業try出來的,其實我對EEP的了解,應該也是這樣 出來的只是我覺得Delphi的確是一個好工具,只可惜微軟的COM+/DCOM是濫東西, 做不出真正的分散式系統,當一個好工具架構在濫基礎上,我覺得這就是訊光工程 師的無力感~~~~ 不知諸位大大有何看法~~~ 發表人 -

做 COM 元件，有一大堆讲究。如果真吃透了，也能做出好东西来的。 如果实在不想做COM/COM ，还可以用DataSnap的方式，做其它的中间层。比如我现在就经常把中间层做成WebService的方式，根本不用COM 。 用COM 的好处是可以利用到一些Pool机制，可以让系统的效率高一些。 其实在规划系统的时候，必须考虑几个问题，然后才能选择开发方式。 1. 系统的大小。是通常只有几十个人访问，还是会有成千上万的人访问； 2. 系统的开发费用。在系统规模小的时候关系不大。系统规模大的话，系统的成本肯定会很高。通过在软件开发上的努力，可以提供效率，降低硬件成本，说穿了，就是增加软件开发成本。另一种可能，是降低软件开发成本，提高硬件成本，买更贵的机器，同样可以达到目的。 比如，我抛开COM，直接把中间层写成Web Service，向客户端传递Variant形态的Data。为稳定性好，我就写成CGI。为效率高，我就写成ISAPI。但ISAPI就需要更多的时间去调整，需要更深的功力。也就是说，要效率高，就要投入更多的成本。

各位都好像把Application Server三層架構看做了雞肋無用之物。 事實上，我認為 Application Server 僅提供給我們一個基礎。 就這個基礎下，建設屬於自己的 APP SERVER。 就目前三層機制下，建議要有。 1. APP Server 所允許最大執行緒的數量。 2. 排隊等候機制。(當使用者已超過數量）執行緒不再只單單服務一個用戶，更允許多人平均分配使用。 3. 異常處理機制。 定期自我檢查該用戶是否無回應，若無回應！ 釋放其佔用記憶體與所佔執行緒。 眾所皆知，Delphi 的三層架構很大的毛病就出在，不會正確的釋放資源與執行緒。導致執行緒卡死在那裡。最後拖垮整個系統，所以常常要定期設定重新開機。 我之前寫過Casino APP-Server (後來做的)就是用這樣寫的。 我覺得 3-Tier 架構只是一種理念，並非就等於 Delphi 的APP Server 的機制。我幾乎都將 Delphi Socket server及Midas部分源碼重新寫過。 感覺還OK。多人使用也不會因為建立太多的Thread 而當機。 若只單單使用Delphi 所提供預設的方法，這將會死得很悽慘。 另外您也可以寫一個屬於自己的三層架構，不過這將是很大的工程。 參考 ～～～～～～～～～～～ 難得聰明，常常糊塗。 ～～～～～～～～～～～

Dear All ,
關於 Multi-Tiers 的東西, 不管是用什麼技術 ,重點在於了解所使用的技術是否真的可以達到所要的需求 .
L.B. Fault T. DB-Connection Pool, Socket Connection Pool 這些東西是不是真的都了解 .
如果可以知道, 用起AP-Server , 還有跟AP-Server配合的DB , 跟呼叫AP-Server的Front-End 技術, 才不會心驚膽跳 .
太多的黑盒子存在現今市場所提供的 Multi Tires 的裡面, 而技術文件又不會太多的詳述裡面到底是在幹什麼 .
所以現在的工程師在壓力下 , 根本無力也無心去處理系統上的事情 , 只能不停追逐客戶所衍生的Business Request .

對於 Multi-Tier 這類東西 , 只是一個概念. 如果可行 ,就自己開發吧 .
要開發一個好的 multi-tier ..不只是AP server.
1. ApClient , Front End的那個呼叫東西 , 粉重要...
加密,壓縮...Protocol的可變化性與可讀性..Session建立, Authent處理
2.Ap server , 很需要知識 ,但是不煩 ....
Socket Pool , DB Pool , SesionControl , Authen 處理, 多語系資料的轉換...CodePage 處理.....
3.DB , Ap Server 如何與AP server 對口 , 需不需要埋一些東西到DB裡面去, 使得AP server 好控制
埋一些 動態的SQL處理. Authen Data 的 logging...

如果你有朋友是做金融線上即時交易軟體的 , 去問問他 ..他們會給你很多想不到的答案 ,

編輯記錄

^^...
其實我們公司也遇到相同問題...
請問一下有做金融線上即時交易軟體的大大願意分享一下經驗嗎?

前段时间我刚用socket apperver做了一个项目,做出来的效果还不错,其实做的时候就要注意以下几点:
1.不要使用delphi socket apperver的标准模式来做(即remotedatamodule->socketconnection->clientdataset)
2.用手工代码方式来调用数据,调用完后马上释放掉连接.
这样做了以后就不会有多余的连接了,我用了半年了内存使用还是只有几M,而且操作过程中断网也没问题,因为这是无连接状态的模式,

以前，我是用Midas方法，
现在，我堂试用RemoteObject方法，
（我的中间层是空壳，就放个ADOConnection ADOQuery DataSetProvider)
全是客户端ClientDataSet.CommandText来控制逻辑。

不知这种方法形不形？

至于中间层中,无法知道客户端有哪些人这个问题？ 我是采用多加一个IndyTCPServer,多加一个Port.来专门控制用户登录的情况

看设计目标吧。一个小的系统，比如几十个人使用，拖拖 delphi 的元件做出来的 N Tier 还是能用的。当然，那个有很多 bug 的 SocketConnection 还是不能用，要用的话得自己去修改它里面的 code 把 bug 去掉。

如果是非常多人使用的，比如10万人。那么，你就要仔细考虑你的架构了。不是简单的 3 层就可以的。你甚至要考虑同时有多台 APP SERVER 在支持，还要考虑多台APP SERVER 的动态切换，其中一台死掉也不会影响用户使用。这些，只要方案考虑好了，用 DELPHI 来做是没有问题的。当然，看个人的功力。

如果功力不足，拿现成的东西，那么，有第三方的基于 DELPHI 的类似 MIDAS 的东西，名字我忘记了，但据说非常稳定。不过那也是要钱的 --- 又好用又不费自己的力去写，当然也该付钱了。

多層的程式確實需要足夠的網際開發能力，只拖控件，很難讓人滿意