1998年幫花X銀行建立他的call center。
當時作架構分析的時候,幹了件豬頭事。
建議客戶用MSSQL 7。
豬頭在哪呢? 豬頭在客戶的使用者端作業系統,當時他們的作業系統標準是 NT 3.51。
MSSQL 7的client 必須要使用WinSock 2,而NT 3.51只支援到WinSock 1.1。
就這樣開始了漫長的中介軟體之旅!
首先,這套系統是用Delphi開發的,理所當然的,我第一個想到的就是MIDAS,而它的文件也寫了,它支援WinSock 1.1,所以我就買了6套還是8套,來支援整個call center的客戶端。
然後,實際測試結果,文件是騙人的,MIDAS也是要WinSock 2,所以白花花的銀子就這樣飛了。
最後,當然就是倒楣的Architect兼工程師,我,手工打造一個database proxy。
就這樣,客戶端環境不斷地升級,後端資料庫也不斷的升級,這個小工具,還是站在那裡。
在一台P3,RAM 1G的機器乖乖的服務所有的使用者(全盛時期,快500個concurrent user)。
這個小工具,當然也一直還在被使用中,但是他有幾個限制。
只能用DELPHI連,只有一個中介伺服器可以連。
一個更好的database proxy,最好就是能提供ODBC/JDBC介面,讓前面的系統能夠使用。
當然,還應該要能容錯,可以多台伺服器並行使用。
英國有一套軟體叫做OpenLink就是作這檔事的,那幹麼不用? 不是因為貴,是因為重。
我理想中的資料庫中介,第一要快、第二要穩、第三要小,之後才是通用性。
OpenLink作到了通用性第一,穩定性第二,自此無它。
我的小工具作到了,快、穩、小,但不通用。
所以,要改版啦,在WINDOWS可以借用MSMQ,但是要通用,要免錢,在Unix環境下,就要另尋出路了。
目標:
1. 借用通用的Queue達成分散式的目標
2. ODBC介面
3. 跨平台
完畢