电子商务IT系统-系统框架、机器框架及人员构成-电商系统

框架选择

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台