由于許可和單一系統的特性，數據庫和內部企業系統的擴展成本會很高。因此，我們希望它們能專注于執行特定的任務。就數據庫而言，我們希望它們能夠專注于事務而不是產品智能。就后臺辦公系統(商業智能)而言，我們不希望產品與系統的擴展能力聯系在一起。對于業務系統的數據，采用異步傳輸模式。
我們常常告訴客戶，要避免在關系數據庫中使用存儲過程。他們的第一反應通常是:“你們為什么這么討厭存儲過程呢?”其實我們并不討厭存儲過程，我們在很多情況下也在用它們。但問題在于，存儲過程經常在解決方案中被過度使用，而這種過度使用有時會造成系統中的擴展瓶。既然這個原則強調的是數據庫方面的問題，那為什么不把這個原則放在數據庫那章中呢?事實上我們關注存儲過程的真正原因是，我們主張把商業智能和產品智能與事務處理區分開來。一般說來，這個主張可以進一步概括為“把相似的事務放在一起(或者說把不同的事務分開)以獲取最大的可用性和可擴展性以及最低的成本”。這樣的表述可能不太好理解，因此讓我們仍以存儲過程和數據庫為例，說明為什么需要這種區分。
在你的架構中、數據庫可能是最貴的系統或服務之一。即使采用的是開源數據庫，這些系統所在的服務器也可能會連接到成本相對較高的存儲解決方案(相對于你其他的解決方案而言)，它們具有最快、最大數量的處理器以及最大數量的內存。在成熟的環境中中，這些系統通常都被用于做一件事情、即執行關系操作，并把事務盡可能快地提交給穩定的存儲引。這些系統上的每個計算周期的成本都比架構中的其他解決方案或服務(如應用服務器或web服務器)要高。這些系統是某些服務的匯集點、也是泳道的定義點。在極端情況下，如在架構的初期，這些系統所占的比例可能更為巨大的，那么它們顯然是影響整個環境的擴展的決定性因素。
出于以上這些原因，把這種昂貴的計算資源用于業務邏輯幾乎是毫無意義的。這時每個事務所花的成本會增加，因為處理這些事務的系統的操作成本更為昂貴了。同日時這個系統本身也可能是影響我們擴展的決定性因素，那么為什么我們還要浪費生產力在它上面運行與事務處理不相關的操作呢?因此，我們應該讓這些系統只處理與數據庫(或相關的存儲或 NOSQL)相關的事務，以便讓它們做自己最擅長的事情。這樣我們不僅提高了可擴展性，還能減少擴展成本。
在數據庫這個例子中，我們把不相似的服各區分開可以應用到架構中的其他環節。我們很可能會有后臺辦公系統，諸如發送和接收電子郵件(與平臺無關)的系統、做總賬和其他會計事務的系統、市場細分的系統，以及支持客戶戶的運維系統，等等。我們很可能會把這些系統一股腦地放到我們的平臺上。我們可能希望電子商務系統中的一筆交易能立刻顯示在我們CFO的ERP系統中，或者我們想讓客戶支持代表能立刻看到它，以免這筆交易出問題。同樣地，如果我們運行的是一個廣告平臺，那么我們可能想實時分析數據倉庫中的數據，以便給出更好的廣告建議。有很多原因促使我們想把業務流程與產品平臺中的系統混在一起。但是，我們的建議很簡單:不要這樣做。
理想的情況是，讓這些系統都能根據自己的需要獨立地進行擴展。如果把這些系統綁定在一起，那么當一個系統需要擴展時，所有系統都要同時擴展。在某些情況下，如用數據庫執行業務邏輯，系統的擴展成本會更高。許可證是與CPU相關聯的ERP系統就經常會發生這種情況。如果每個事務都同步調用ERP系統，那么擴展成本一定會提高。此外，把系統以串聯方式加入平臺，也會降低產品的可用性，那么為什么我們還要如此做呢?
就像不應該把產品智能放在數據庫中一樣，商業智能也不應該綁定到產品事務上。在許多情況下，我們需要讓數據駐留在我們的產品中而且此時我們最好讓數據駐留在產品中。我們可以從其他系統中選擇數據集，在產品中正確地表示出來。通常，最好用一種新的或不同的方式表示這些數據，有時是采用不同的范式。我們經常需要把數據從產品移到后臺的業務系統中，如客戶支持系統、市場營銷系統、數據倉庫和ERP系統。在這些情況下，我們也希望能夠用不同的方式總結或表示數據。此外，為了提高可用性，我們希望以異步方式在系統間傳輸這些數據。為此可以采用ETL(提取、轉換、加載)系統，甚至還有很多開源工具可以幫助你構建自己的ETL過程。
記住，網站制作模式并不意味著是“舊”數據。沒有理由選擇過期的數據元素在系統間進行傳輸。此外，還可以把數據發布到某種消息總線上，以供其他系統使用。成本最低的解決方案是批提取，不過如果時間有限不允許采用這種方法，那么消息總線絕對是個好選擇。
本文地址：http://knowyourextract.com//article/3525.html
