框架选择
Windows还是Linux
Windows生态相对简单易用，对开发、运维要求较低，可以满足大中型应用；费用不菲，1台机器的授权费用，Windows Server是万级，SqlServer是10万级；
Linux生态框架甚多，学习成本较高，开发、运维要求较高，可以满足大中型、及超大型应用；完全开源免费。
技术上讲一点，比如应用容器：
在Windows下，基本就是使用IIS了，Apache、Nginx 之类基本不适用；IIS 主要使用UI配置；
在Linux下，则一般用 Nginx 作为Web容器，及反向代理；用Tomcat/Jetty之类作为Java容器；使用 web.xml 作为主要的配置文件。
用了 Linux+java 生态，可以逐渐掌握技术的细节，而Windows生态，技术上的进步要慢一些、困难一些。
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台虚拟机。
架构支撑
总结
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台，上线，逐步扩充。
服务器型号:
人员构成
这里不考虑运维、产品、项目、测试部门，只描述研发部门。
1、角色定义
技术总监：资深的技术研发管理者，深厚的技术及业务功底；也有公司在这个职位上的人完全不懂技术，可能是产品总监、项目总监暂代。
架构师：技术框架的制定者，技术路线的倡导者，负责解决研发中框架相关的问题。
研发经理：经验丰富的工程师，业务功底，协调能力。
高级工程师：经验丰富的工程师，疑难技术问题的解决者。
工程师：自行协调、并解决问题的人。
初级工程师：能在帮助下解决问题的人。
2、人员构成
总监：1
架构师：2
经理：6-8
高级工程师：12-16
工程师：18-24
初级工程师：6-8
总计：五、六十人的规模
3、人员素质
不断学习的进取心、及悟性；
隐忍坚持、协作性好；
胜任职位的技术功底；
其实，我个人认为，人员的素质，其实指的是人员的工作素质，和公司本身的文化是非常相关的，甚至可以说，是公司的文化，塑造了职员在这个公司的工作素质。
电商IT系统介绍
1、权限管理系统
2、图片管理系统
3、商品管理系统
4、采购管理系统
5、搜索系统
6、推荐系统
7、订单管理系统
8、客服管理系统
9、会员管理系统
10、商业智能系统
以上系统并未完全实现，有些仅仅是功能设想和简单列表功能实现，需要在实际的生产过程中逐渐来补充，抛砖引玉，仅供参考。
