多应用+插件架构,代码干净,二开方便,首家独创一键云编译技术,文档视频完善,免费商用码云13.8K 广告
### 框架选择 ### 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块,指的是系统个数,不是行政组: [权限管理系统](http://blog.csdn.net/puma_dong/article/details/12391479) 网站:网站(CMS) 销售中心:[销(订单、促销、退换货、分销)](http://blog.csdn.net/puma_dong/article/details/39272243) 采购中心:[采购管理系统](http://blog.csdn.net/puma_dong/article/details/39013635) 仓储中心:仓储管理系统 用户中心:[会员系统](http://blog.csdn.net/puma_dong/article/details/39505955)、[客服系统](http://blog.csdn.net/puma_dong/article/details/39506157) 商品中心:[商品管理系统](http://blog.csdn.net/puma_dong/article/details/9854899)、[图片管理系统](http://blog.csdn.net/puma_dong/article/details/16835677) 财务中心:结算、收付 搜索推荐:[搜索系统](http://blog.csdn.net/puma_dong/article/details/38942777)、[推荐系统](http://blog.csdn.net/puma_dong/article/details/38943251) 商业智能系统:数据统计分析 3、快速发展阶段,拆服务、加缓存: 各个系统之间数据交换尽量服务化,减少直接的查询本业务之外的数据。引入Dubbo、RabbitMQ、Redis等框架 4、快速发展阶段,拆数据库: 各业务系统数据库完全独立,除了MySql的主从同步之外,引入Otter框架用于数据复制。 5、经过以上的过程,达到完全的SOA化,但是这个过程的演进,实际是多花了非常非常多的时间,2倍?3倍?如果条件允许,尽量还是直接基于SOA框架进行开发,只要框架做好了,仅仅是编码工作而已,最初的开发工作量实际上和那种”原始的、所有系统、数据库都在一起的,唯速度考虑的编程方式“,不会增加很多,但是后期的好处及长远考虑,是值得的。因为,从长远来看,SOA是必须的。 有两篇文章很好,如下: [http://javatar.iteye.com/blog/1329022](http://javatar.iteye.com/blog/1329022) [http://javatar.iteye.com/blog/1345073](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系统介绍 [1、权限管理系统](http://blog.csdn.net/puma_dong/article/details/12391479) [2、图片管理系统](http://blog.csdn.net/puma_dong/article/details/16835677) [3、商品管理系统](http://blog.csdn.net/puma_dong/article/details/9854899) [4、采购管理系统](http://blog.csdn.net/puma_dong/article/details/39013635) [5、搜索系统](http://blog.csdn.net/puma_dong/article/details/38942777) [6、推荐系统](http://blog.csdn.net/puma_dong/article/details/38943251) [7、订单管理系统](http://blog.csdn.net/puma_dong/article/details/39272243) [8、客服管理系统](http://blog.csdn.net/puma_dong/article/details/39506157) [9、会员管理系统](http://blog.csdn.net/puma_dong/article/details/39505955) [10、商业智能系统](http://blog.csdn.net/puma_dong/article/details/41546423) 以上系统并未完全实现,有些仅仅是功能设想和简单列表功能实现,需要在实际的生产过程中逐渐来补充,抛砖引玉,仅供参考。