企業級N Tier體系結構解決方案討論(二)

2019-11-18 22:05:45

字體：大中小

來源：轉載

供稿：網友

企業級N Tier體系結構解決方案討論
--NT+SQL Server plantform篇
Writen by pepper_dog999
    關于企業級的數據庫結合前臺應用程序的解決方案現在成為了整個網絡應用的熱點問題。很多企業在選擇解決的方案時常會考慮的問題可以歸結為三個h，即High performance、High security、High transaction solution。我的這篇文章意在比較業界流行的幾種解決方案之間的優缺點和可行性，本篇討論的是微軟的解決方案。首先我們在這里不去討論常規的Server/Client模式，也就是2-Tier模式，雖然這種模式的應用最為廣泛，但由于對于企業級的需求來說，這種模式的performance和security都不能達到要求，所以我們主要討論的是N>=3 的情況，也就是Database Server/application Server/Client的模式。至于Distribution Transaction的情況我們暫時不做討論。在這里我首先提出我的一個看法，那就是現在大部分的方案開發者都走入了一個誤區，那就是將工作的重點和大部分的精力放在了3-tier體系結構中的第二層，也就是App Server上，由于整個業界不斷的推出新的中間層解決方案，從perl到asp到php到isapi到現在的jsp，所以開發者的大部分時間和精力都用來熟悉新的解決方案和對比各種方案的優缺點上。誠然，好的中間層解決方案能夠提供更高的性能和安全性，也就是前面三h中的前兩個。但是這是在小量數據的時候(tiny data)，那么當大量或者是海量數據出現的時候呢？這里我想借用硬件中常用的一個術語--瓶(bottle neck)，大家都知道瓶頸是制約整個體系的最慢的部分，當海量數據出現時，整個3 Tier體系中的瓶頸就成了該體系中的第一層，即
database Server，而在企業級應用中，我想可能以第二種情況為多。大概二者性能影響的比例應該為4：1吧，而且數據量越大這個比例也就越大了，這也是數據庫產品的售價遠高于應用程序的原因吧（笑）。現在較高級的數據庫產品如SQL Server、Oracle等都將Autentication、Performance、Transaction緊密的結合在了它們的產品中，那我們的開發重點是否也應該相應的放在database Server端呢？而在app Server端只是幾個簡單的調用過程和參數的傳遞過程，那么app Server端用哪一種方案就不再是一個很重要的問題了。我覺得是越簡單越好，為什么不呢？非要去用isapi嗎？這樣的話開發的重點不就本末倒置了嗎？如果從開發成本/性能效益的角度來分析的話，那就大大的不值得了。所以我覺得與其將大量的精力放在前臺的app Server上，不如將更多的工作重點放在后臺數據庫的設計、開發上，將核心的處理過程都轉移到database Server上。將精力用在數據庫的合理設計，數據庫中實體之間的關系，索引的合理配給等方面。例如2NF、3NF的實現哪，表中仄余column的分析上啊。我的幾位同學都在做這樣的項目，他們的程序不能說不好，所用的技術也是日新月異，可他們數據庫的設計可就實在不怎么樣了。各個表之間的關系混亂、大量的仄余column，我想這可能是因為他們沒有從一個總體的角度去考慮問題吧，而且一個整體的解決方案需要對各個層次都有所了解，這也是不太容易達到的了。周星弛在大話西游中說"斗雞眼其實與常人沒什么不同，只是看事物的方法不同罷了，是將視線和注意力放在事物的某一點罷了。"但我們在項目的總體開發上卻不能這樣，要不然對項目的可行性分析和總體的考慮還有什么意義呢？前面我說的我的那幾位同
學他們的后臺數據庫也多是SQL Server和Oracle。但他們并沒有去發揮這些產品的特性。比如說他們在SQL Server上建立了一個員工的信息數據庫，其中有一個表(member_info)用于保存員工的信息。為了獲得該表的數據他們在app Server端寫了如下的語句：
conn.ConnectionString="Driver={SQL Server};Server=sev1;uid=user_name;
                           pwd=passWord;database=member_database"
conn.open
rs.ActiveConnection=conn
strSQL="select member_ID,address,fri_name,lsr_name…… from member_info
            where……";
rs.open strSQL,conn,,,adCmdText
好了，目的是達到了，但重要的信息也都泄露了。用戶名(user_name)、密碼（password）、連接的數據庫服務器(sev1)、
數據庫名(member_database)、該數據庫下的表名(member_info)、甚至該表的各個Column名都知道了，是的，asp是不允許
看到原代碼的。但asp的漏洞大家都知道的。若它用了SSL還好，否則就是整裸體一個了。也許你會說："我可以只給
user_name用戶Grant一個最小的權限，那它就不能為所欲為了，是的，但一個Select權限總得有吧。若該表上有很多的敏
感信息，而你只想讓用戶看到部分的Column那怎么辦呢？那你就一個Column一個Column的去賦予權限好了。但現在很多的
開發者對數據庫的設計并不在行，有些又將開發的工作分給了不同的人做，那么在思想的統一上又出現了問題。所以根本
不會考慮很多的問題。我還見過有人在uid字段填個sa，在pwd字段填個""(NULL)，哈，開發真的方便了，那我看你還是將
你的數據庫設為"dbo use only "吧！·那我們用SQL Server和Oracle上都有的Stored PRocedure來做呢？
Create Procedure usp_show_info
@memberID int
……
As
select member_ID,address,fri_name,lsr_name……
from member_info where……
我們僅給db_user一個Execute該Procedure的權限，那么它就只能執行該Procedure，對于表的權限它什么也沒有。而且
Procedure是放在database端上的預編譯過程，該用戶連表名都不知道了，他怎么直接操作表呢？只要不發生權限的斷鏈就
一點問題都沒有了。至于性能和可重用性大家也都看得明白拉。前臺的調用過程就幾句：
comm.CommandType=cmdStoredProcedure
comm..CommandText="usp_show_info"
如果我們在App Server端再加個SSL的話，那就有兩層的安全保障了。再不放心，用JSP將原代碼編譯得了。至于只想顯示
一部分的表項，那更好辦，SQL Server和Oracle中都有View的概念，然后將Procedure操作于view上，我們看看它的關系鏈
table->view->procedure->database Server->app Server->SSL->client，如果還有人能解開這個鏈的話，我，我想你還
是把他聘請得了（這樣的性價比絕對最高）。

上一篇：數組數據排序的程序例子

下一篇：企業級N Tier體系結構解決方案討論(一)