概述：本文簡單概述了為提高應用程序吞吐量的一般做法，這些做法僅涉及總體部署方面。
應用服務器
一般的，我們通過微軟的網絡負載平衡技術實現擴展，你可以架設32台以內的應用服務器，當然實際上你可以架設更多（微軟有詳細的資料介紹如何架設的更多）。對於一般的ERP應用來說，32台服務器已經足夠足夠使用了，因為性能的瓶頸實際上在數據庫上。
使用微軟網絡負載平衡技術的好處：他沒有一個中央調度服務器，所以你不必擔心這個中央調度服務器的崩潰或緩慢導致事實上仍然有瓶頸。
這些應用服務器之間是完全均等的，也就是說A服務器能夠提供的功能在B服務器上完全一樣能夠做到，他區別於從業務上划分不同的應用服務器。
如果你覺得一個服務器寄生一個服務實例，有些讓這台服務器太浪費，你可以將你的服務設計成COM+或者寄生在IIS下，因為他們都有成熟的技術將服務器壓榨到底。
當然，這樣的服務器部署方式對程序編寫有一定的要求，例如你在你的程序中使用靜態變量緩存數據時，你可能遇到麻煩，因為當你更新你的緩 存時，即你的靜態變量時，你僅僅只更新某一台服務器。相似的問題同樣發生在單例的服務上。因此你必須保證服務是無狀態的，那么緩存數據怎么辦呢？
緩存服務器
幸好微軟有開發了Velocity，一個使用分布式內存緩存技術，關於此技術的中文說明你可以參考《使用微軟分布式緩存服務》，他是三篇連載的文章寫的很詳細。
通過使用Velocity你相當於有了一個全局的緩存空間，同樣的，通過簡單的手法你還可以實現全局的會話數據，這樣你不用擔心某台應用服務器崩潰導致會話數據。
當然，從我目前了解到的信息來看，Velocity將數據分布到多台計算機上，如果某個服務器崩潰，對於緩存的數據來說，我覺得無所謂，沒有任何影響，問題是寄生在這個服務器的會話數據你在別的機器上也是找不到的。所以某台緩存服務器對部分在線用戶是有影響的。
Velocity還提供了版本功能，這個功能你必須了解並在你的程序中充分考慮，這是在大並發下必須考慮的問題；
但是緩存服務器畢竟是緩存，理論上我們認為他具有不穩定性。所以當你需要一些具有全局狀態的對象時，可能比較頭大了。例如你希望有一個 元數據服務，記錄當前應用中所有實體的結構，這些元數據不僅是數據，還有行為。目前我沒有很好的辦法，只能盡可能的將這些服務設計成無狀態服務。
數據庫服務器
其實一切瓶頸的根源還是在數據庫服務器，到目前為止，我沒有收到任何信息說Microsoft有打算讓SQL Server可以將一個數據庫分布在多個計算機上。
從目前的技術上來說，你還是可以有很多的手段提高性能，這些方法在網絡上都有很多的文章，我這里僅是羅列一下：
l 購買一個64位的計算機，64位的操作系統，64位的SQLServer吧，購買你的計算機能夠裝進的最大內存，這是最簡單最快速的辦法，下面所有的方法都比不是這個來的快。要知道通常的ERP應用數據庫都只有30GB以下，而SQL Server都可以把數據都緩存了；
l 將一個數據庫分布在多個文件上，而這些文件又分布在不同的磁盤陣列上；
l 超級大的表請考慮將歷史數據拆分到別的表，在查詢中盡可能包含日期，而日期字段又是聚集索引；
l 調整你的SQL和索引，這個老生常談了，也是最復雜的。
l 從業務上，你僅可能的將多個帳套（業務上的帳套）設計到不同的數據庫，例如不要在訂單表上設計一個諸如AccountID的列區分不同的帳套，而將全國各地的訂單都塞到這個表中，雖然程序上稍稍復雜些（我有時候覺得反而程序簡單些了），但是將請求隔離到不同的數據庫是很值得的，因為很多死鎖你很難搞定的；
l 將大量頻繁讀取但是一般不會做關聯查詢的數據，例如配置數據和權限數據，盡可能的放在緩存中吧，如果你沒有辦法放在緩存中，那么也請隔離到另外一個數據庫服務器；
l 將不太關聯的業務表拆分到不同數據庫服務器，例如你的OA和生產系統做關聯查詢的不多。這樣你的數據庫負載又分擔開了，如果你發現還是有些表需要關聯查詢時，考慮使用SQL Sever的遠程視圖，將其映射過來，這樣你的程序就不必為這種情況來個IF語句了。
方法還有很多，大家可以幫助補充下啊。