框架選擇
Windows還是Linux
Windows生態相對簡單易用，對開發、運維要求較低，可以滿足大中型應用；費用不菲，1臺機器的授權費用，Windows Server是萬級，SqlServer是10萬級；
Linux生態框架甚多，學習成本較高，開發、運維要求較高，可以滿足大中型、及超大型應用；完全開源免費。
CS還是BS
CS有其固有的優勢，比如：開發效率會高：做個界面，弄個事件啥的都很快，可以有本地緩存，可以有客戶端的多線程處理；
缺點是軟件的升級維護相對麻煩；
由於Windows在桌面上的絕對壟斷地位，以及Visual Studio開發桌面程序的效率，當前，CS開發基本都是使用.Net框架。
考慮到軟件的升級維護，及長遠的可擴展性，BS是更好的選擇。
場景：
1、基於WindowsCE系列的PDA設備（倉儲的手持設備），倉儲的打包臺部分（性能效率要求極高時）；
2、頻繁Excel處理的小工具，其實這個可以考慮用Web上的表格輸入來實現；
3、其他場景，建議全部是BS。
開發語言
這個實在討論的太多了。
.net開發人員衆多，微軟緊密集成，服務器基本就是windows了，數據庫也基本是sqlserver了；
java開發人員也是衆多，框架衆多，對架構、運維要求都更高，否則易出問題，服務器基本是linux,數據庫基本是oracle,mysql；
ruby on rails，據說開發web快，也有新銳者使用了；
根據公司實際情況選擇吧；中小可以.Net，大中小都可以java。
這個選擇還有個成本考慮，微軟的服務器產品全部都是要錢的：Windows Server上萬，SqlServer 上10萬；linux系列的產品都是開源免費的，但是人力資本相對就高些。
SOA框架及系統拆分
SOA框架實際是一種開發方式，讓人專注於自己最熟悉的一塊，不同系統之間發生的業務交叉，全部採用接口的方式提供，其最大的好處：
是非常有利於系統的性能提升，可以更方便的分庫；
專注也能更利於優化和提升；
缺點是我們用不了以前那種查詢所有的業務表，用一個大事務來保證一起執行的開發方式了，我們必須對系統的異常情況考慮更多，對關鍵業務的失敗要做回滾處理，編碼更多了；
對於大型系統來說，SOA是必然的選擇；
對於小系統來說，爲了快速開發，開始可能都是單庫、查表；隨着業務的發展，數據的增大，不可避免的要重構，要分庫。
一般公司的框架發展過程（Linux/Java/MySql）：
1、系統初創階段，一般不給我們好好系統設計的時間，很多着急上線，經常會選擇最快的方式而忽略系統架構，如果不能選擇，這個階段必須考慮以下部分：MVC、ORM（不要用Hibernate）；這個階段一定不要把需求做龐大，先做主幹流程，先上線，后豐滿；先出成果起到激勵作用，否則遷延日久，士氣怠矣。
2、快速發展階段，拆系統，大約10塊，指的是系統個數，不是行政組：
網站：網站(CMS)
銷售中心：銷（訂單、促銷、退換貨、分銷）
採購中心：採購管理系統
倉儲中心：倉儲管理系統
財務中心：結算、收付
商業智能系統：數據統計分析
3、快速發展階段，拆服務、加緩存：
各個系統之間數據交換儘量服務化，減少直接的查詢本業務之外的數據。引入Dubbo、RabbitMQ、Redis等框架
4、快速發展階段，拆數據庫：
各業務系統數據庫完全獨立，除了MySql的主從同步之外，引入Otter框架用於數據複製。
5、經過以上的過程，達到完全的SOA化，但是這個過程的演進，實際是多花了非常非常多的時間，2倍？3倍？如果條件允許，儘量還是直接基於SOA框架進行開發，只要框架做好了，僅僅是編碼工作而已，最初的開發工作量實際上和那種”原始的、所有系統、數據庫都在一起的，唯速度考慮的編程方式“，不會增加很多，但是後期的好處及長遠考慮，是值得的。因爲，從長遠來看，SOA是必須的。
有兩篇文章很好，如下：
http://javatar.iteye.com/blog/1329022
http://javatar.iteye.com/blog/1345073
是否要讀寫分離
讀寫分離對於減小數據庫壓力是很有幫助的，原則上select只要能訪問從庫的就一定不要訪問主庫，因爲從庫是可以無限擴展的，而主庫不容易擴展。
但是主從訪問的方式是個選擇性問題：
有的給軟件開發者一定的自由決定，是連接主庫還是從庫，這導致了很多不必要的主庫連接；
有的公司採取一刀切的方式，統一採用ameba，corba之類的系統連接數據庫，只要是select，全部去了從庫；這種方式，在一些寫完馬上查的地方，很容易發生“主從問題”，對代碼要求嚴謹一些；
所以，這是個選擇性問題，根據業務場景進行具體的選擇，很多場景中：使用主庫+緩存的模式，可以很好的解決問題。
千萬PV需要的服務器規模估計
業務系統
| 用途 | 系統 | 物理機數量 | 虛擬機數量 | 備註 |
| 網站中心 | 網站主站 | 10 | 0 | |
| 網站後臺 | 0 | 2 | ||
| 訂單中心 | 網站購物流程 | 0 | 0 | 包含在網站主站之內 |
| 訂單接口 | 3 | 0 | ||
| 用戶中心 | 網站會員中心 | 0 | 0 | 包含在網站主站之內 |
| 用戶接口 | 2 | 0 | ||
| 商品中心 | 商品管理系統 | 0 | 2 | |
| 圖片管理系統及CDN源站 | 1 | 0 | ||
| 採購中心 | 採購管理系統 | 0 | 2 | |
| 採購接口 | 0 | 2 | ||
| 倉儲中心 | 倉儲系統 | 0 | 2 | |
| 配送系統 | 0 | 2 | ||
| 倉儲配送接口 | 3 | 0 | 庫存可以通過結構調整記錄到商品表中，這裏指的是爲內部系統提供的接口 | |
| 結算中心 | 結算管理系統 | 0 | 2 | |
| 客服中心 | 客服管理系統 | 0 | 2 | |
| 分銷中心 | 網盟管理系統 | 0 | 0 | 前期暫緩 |
| 商家中心 | 招商管理系統 | 0 | 0 | 前期暫緩 |
| 搜索 | 搜索推薦系統 | 6 | 0 | 前期可以現有搜索系統，中後期再開發推薦 |
| 機器冗餘 | 1 | 0 | 冗餘備用的機器1-2臺 |
合計：29臺物理機，16臺虛擬機。
架構支撐
| 用途 | 系統 | 物理機數量 | 虛擬機數量 | 備註 |
| Dubbo | Zookeeper集羣 | 3 | 0 | |
| 消息 | RabbitMQ高可用 | 2 | 0 | |
| 緩存 | Redis高可用集羣 | 2 | 0 | |
| 負載 | HAProxy/LVS | 3 | 0 |
合計：10臺物理機，0臺虛擬機。
總結
1、系統是UI，接口邏輯，系統要滿足的基本是靜態PV，要求的是IO能力，不是CPU和內存，接口計算任務會多，要求CPU和內存；壓力一般都在接口和數據庫；
2、數據庫按照業務系統的50%計算，4臺虛擬機需要1臺物理機計算，總計約需要60臺服務器；
3、真實案例：Windows+MSSQL，支撐1000萬PV，有人用過約120-150臺R410/710服務器，個人感覺比較浪費；
4、我的估算和上面這個真實案例差別很大，實踐中，可以根據實際情況，酌情增減；
5、針對3的真實案例，如果全用正版，僅license一項，就要花費幾百萬費用，才僅僅是一個千萬PV的規模；
6、初期就安裝SOA框架開發，相對於系統上規模再拆分，可以節省非常多的時間，架構做好了，開發效率並不低，而且，隨着系統更大，非常容易擴展；
7、對於初期，可以先按照1/5規模，約12臺，上線，逐步擴充。
服務器型號
| Dell服務器 | 檔次 | 價格 |
| 410/420系列 | 低端 | 1-2W |
| 710/720系列 | 中端 | 2-6W |
| 910系列 | 高端 | 6-~W |
Dell官網：http://www.dell.com.cn
人員構成
這裏不考慮運維、產品、項目、測試部門，只描述研發部門。
1、角色定義
技術總監：資深的技術研發管理者，深厚的技術及業務功底；也有公司在這個職位上的人完全不懂技術，可能是產品總監、項目總監暫代。
架構師：技術框架的制定者，技術路線的倡導者，負責解決研發中框架相關的問題。
研發經理：經驗豐富的工程師，業務功底，協調能力。
高級工程師：經驗豐富的工程師，疑難技術問題的解決者。
工程師：自行協調、並解決問題的人。
初級工程師：能在幫助下解決問題的人。
2、人員構成
總監：1
架構師：2
經理：6-8
高級工程師：12-16
工程師：18-24
初級工程師：6-8
總計：五、六十人的規模
3、人員素質
不斷學習的進取心、及悟性；
隱忍堅持、協作性好；
勝任職位的技術功底；
其實，我個人認爲，人員的素質，其實指的是人員的工作素質，和公司本身的文化是非常相關的，甚至可以說，是公司的文化，塑造了職員在這個公司的工作素質。
電商IT系統介紹
以上系統並未完全實現，有些僅僅是功能設想和簡單列表功能實現，需要在實際的生產過程中逐漸來補充，拋磚引玉，僅供參考。