把業(yè)務系統(tǒng)和產(chǎn)品系統(tǒng)分開，刪除數(shù)據(jù)庫系統(tǒng)中的產(chǎn)品智能?？紤]公司的內(nèi)部需求以及在產(chǎn)品內(nèi)或產(chǎn)品間傳翰數(shù)據(jù)的情況。從數(shù)據(jù)庫中刪除存儲過程，把它們放在應用邏輯中。不要在企業(yè)系統(tǒng)和產(chǎn)品系統(tǒng)之間進行同步調(diào)用。把應用邏輯放在數(shù)據(jù)庫中成本很高且難以擴展。把企業(yè)系統(tǒng)和產(chǎn)品系統(tǒng)綁定在一起，成本也很高，不僅難以擴展，可用性也令人擔憂。

由于許可和單一系統(tǒng)的特性，數(shù)據(jù)庫和內(nèi)部企業(yè)系統(tǒng)的擴展成本會很高。因此，我們希望它們能專注于執(zhí)行特定的任務。就數(shù)據(jù)庫而言，我們希望它們能夠?qū)Ｗ⒂谑聞斩皇钱a(chǎn)品智能。就后臺辦公系統(tǒng)(商業(yè)智能)而言，我們不希望產(chǎn)品與系統(tǒng)的擴展能力聯(lián)系在一起。對于業(yè)務系統(tǒng)的數(shù)據(jù)，采用異步傳輸模式。



我們常常告訴客戶，要避免在關系數(shù)據(jù)庫中使用存儲過程。他們的第一反應通常是:“你們?yōu)槭裁催@么討厭存儲過程呢?”其實我們并不討厭存儲過程，我們在很多情況下也在用它們。但問題在于，存儲過程經(jīng)常在解決方案中被過度使用，而這種過度使用有時會造成系統(tǒng)中的擴展瓶。既然這個原則強調(diào)的是數(shù)據(jù)庫方面的問題，那為什么不把這個原則放在數(shù)據(jù)庫那章中呢?事實上我們關注存儲過程的真正原因是，我們主張把商業(yè)智能和產(chǎn)品智能與事務處理區(qū)分開來。一般說來，這個主張可以進一步概括為“把相似的事務放在一起(或者說把不同的事務分開)以獲取最大的可用性和可擴展性以及最低的成本”。這樣的表述可能不太好理解，因此讓我們?nèi)砸源鎯^程和數(shù)據(jù)庫為例，說明為什么需要這種區(qū)分。

在你的架構中、數(shù)據(jù)庫可能是最貴的系統(tǒng)或服務之一。即使采用的是開源數(shù)據(jù)庫，這些系統(tǒng)所在的服務器也可能會連接到成本相對較高的存儲解決方案(相對于你其他的解決方案而言)，它們具有最快、最大數(shù)量的處理器以及最大數(shù)量的內(nèi)存。在成熟的環(huán)境中中，這些系統(tǒng)通常都被用于做一件事情、即執(zhí)行關系操作，并把事務盡可能快地提交給穩(wěn)定的存儲引。這些系統(tǒng)上的每個計算周期的成本都比架構中的其他解決方案或服務(如應用服務器或web服務器)要高。這些系統(tǒng)是某些服務的匯集點、也是泳道的定義點。在極端情況下，如在架構的初期，這些系統(tǒng)所占的比例可能更為巨大的，那么它們顯然是影響整個環(huán)境的擴展的決定性因素。

出于以上這些原因，把這種昂貴的計算資源用于業(yè)務邏輯幾乎是毫無意義的。這時每個事務所花的成本會增加，因為處理這些事務的系統(tǒng)的操作成本更為昂貴了。同日時這個系統(tǒng)本身也可能是影響我們擴展的決定性因素，那么為什么我們還要浪費生產(chǎn)力在它上面運行與事務處理不相關的操作呢?因此，我們應該讓這些系統(tǒng)只處理與數(shù)據(jù)庫(或相關的存儲或 NOSQL)相關的事務，以便讓它們做自己最擅長的事情。這樣我們不僅提高了可擴展性，還能減少擴展成本。

在數(shù)據(jù)庫這個例子中，我們把不相似的服各區(qū)分開可以應用到架構中的其他環(huán)節(jié)。我們很可能會有后臺辦公系統(tǒng)，諸如發(fā)送和接收電子郵件(與平臺無關)的系統(tǒng)、做總賬和其他會計事務的系統(tǒng)、市場細分的系統(tǒng)，以及支持客戶戶的運維系統(tǒng)，等等。我們很可能會把這些系統(tǒng)一股腦地放到我們的平臺上。我們可能希望電子商務系統(tǒng)中的一筆交易能立刻顯示在我們CFO的ERP系統(tǒng)中，或者我們想讓客戶支持代表能立刻看到它，以免這筆交易出問題。同樣地，如果我們運行的是一個廣告平臺，那么我們可能想實時分析數(shù)據(jù)倉庫中的數(shù)據(jù)，以便給出更好的廣告建議。有很多原因促使我們想把業(yè)務流程與產(chǎn)品平臺中的系統(tǒng)混在一起。但是，我們的建議很簡單:不要這樣做。

理想的情況是，讓這些系統(tǒng)都能根據(jù)自己的需要獨立地進行擴展。如果把這些系統(tǒng)綁定在一起，那么當一個系統(tǒng)需要擴展時，所有系統(tǒng)都要同時擴展。在某些情況下，如用數(shù)據(jù)庫執(zhí)行業(yè)務邏輯，系統(tǒng)的擴展成本會更高。許可證是與CPU相關聯(lián)的ERP系統(tǒng)就經(jīng)常會發(fā)生這種情況。如果每個事務都同步調(diào)用ERP系統(tǒng)，那么擴展成本一定會提高。此外，把系統(tǒng)以串聯(lián)方式加入平臺，也會降低產(chǎn)品的可用性，那么為什么我們還要如此做呢?

就像不應該把產(chǎn)品智能放在數(shù)據(jù)庫中一樣，商業(yè)智能也不應該綁定到產(chǎn)品事務上。在許多情況下，我們需要讓數(shù)據(jù)駐留在我們的產(chǎn)品中而且此時我們最好讓數(shù)據(jù)駐留在產(chǎn)品中。我們可以從其他系統(tǒng)中選擇數(shù)據(jù)集，在產(chǎn)品中正確地表示出來。通常，最好用一種新的或不同的方式表示這些數(shù)據(jù)，有時是采用不同的范式。我們經(jīng)常需要把數(shù)據(jù)從產(chǎn)品移到后臺的業(yè)務系統(tǒng)中，如客戶支持系統(tǒng)、市場營銷系統(tǒng)、數(shù)據(jù)倉庫和ERP系統(tǒng)。在這些情況下，我們也希望能夠用不同的方式總結(jié)或表示數(shù)據(jù)。此外，為了提高可用性，我們希望以異步方式在系統(tǒng)間傳輸這些數(shù)據(jù)。為此可以采用ETL(提取、轉(zhuǎn)換、加載)系統(tǒng)，甚至還有很多開源工具可以幫助你構建自己的ETL過程。

記住，網(wǎng)站制作模式并不意味著是“舊”數(shù)據(jù)。沒有理由選擇過期的數(shù)據(jù)元素在系統(tǒng)間進行傳輸。此外，還可以把數(shù)據(jù)發(fā)布到某種消息總線上，以供其他系統(tǒng)使用。成本最低的解決方案是批提取，不過如果時間有限不允許采用這種方法，那么消息總線絕對是個好選擇。