电商网站的初期技术选型--转

原文地址：http://www.infoq.com/cn/articles/e-commerce-web-tech-stack

今天在架构师俱乐部3群（由ArchSummit全球架构师峰会运营）里，你们围绕着一个话题讨论地很热烈——彻底从0到1建设一个电商网站，技术选型和注意事项有哪些？群友们都结合本身的实际工做经历分享了不少经验教训，这里是其中的精选。

青岛海尔Jan给你们分享了一个失败案例的教训：

1. 没有准确估计实际业务量或者说就没有估计过，致使技术选型直接参考京东、淘宝一线大公司，实现较复杂，技术铺的也很大。（教训：技术够用就好，选型的目标是可以快速实现产品的迭代）
2. 由于缺乏经验，前期业务没有明确的规划，技术选型也没有考虑高内聚、低耦合，致使系统之间依赖太强，致使如今想拆分很难。
3. 选择了一些较新的技术框架，过于依赖几位关键的技术牛人，结果这些人一旦离职，就陷入迷茫。（教训：关键人员必定要留住，或者有备份人选）

还有群友表示，对于早期的技术选型，不要抄大公司经验，按需求出发，先活下来再说。要考虑到哪些是能够省的，那些是能够用现成的，哪些是须要有特点本身开发的。早期手段能够粗糙，尽可能考虑云。云服务真的能够解决不少创业初期的一些棘手问题，并且能够省下成本。

0到1解决的是卖什么、怎么卖、卖给谁的问题。思考的角度分为技术化域和商业化域。技术域， 是实用生存为主， 不求高大上， 但求快速实用； 商业域，就是经营变现了， 细分领域夺城拔寨。重要的是，寻找到盈利点，创建合适的商业模式，而后经过技术来实现，除非技术驱动产品这样的公司彻底以技术为核心，掌握核心就掌握市场。

若是不及时考虑盈利问题，可能面临如下的问题：公司跟风耗费巨资投入一个项目，技术部门找了不少人，而且采用了各类高大上的项目，结果盈利没跟上来，最终公司决定再也不急需投入，项目就黄了，研发团队也解散了......

上海微肯CTO孔燕斌则认为，流量是电商的最大成本和成功的关键因素之一，关于流量的问题其实就是怎么卖和卖给谁的问题。如今线上流量的成本是很是高的，并且传统的线上流量都是一次性的，为何叫一次性，是由于即便是同一个用户，要再次唤醒，大部分时候仍是摇支付额外的成本，流量的成本谁一值跟着运营高企不下。这里很是推荐微信上的流量，微信的流量有几个好处，一个是用户充足，第二个是有公众号，能够免费唤醒用户，第三个是有社交属性，能够经过朋友圈、券、微信支付等微信能力进行营销。其中对初创的企业最最重要的是能够经过微信的近场能力在线下拉人，使用很低的成本高效地拉人，快速验证。

线下拉人的最大好处是能够经过选择地点，来圈定本身的潜在用户。要作到这一点，系统架构的时候须要增长微信的模块，实现和微信的和和相关的营销功能。快速找到第一批客户验证业务，完成0到1，完成以后是1到100，1000，10000的复制均可以在微信这个流量里面很好地展开，而且有效地下降运营中的流量的成本。基于篇幅的限制，在此不一一展开。

Jan认为，关于网站的流量，严格来讲流量≠客户量，固然这也得看如何定义。流量更多看的是网站访问者或是App使用者的访问状况，从进入第一个页面到最后退出，这样一个全流程。客户量，相对于网站来讲，个人注册客户多少，日访问客户多少(流量分析工具能够实现)，成交客户量等等，须要结合实际公司的对客户量的定义，结合流量分析。

初期除了购买流程上不能有技术短板外，产品为核心的营销数据流也很重要。提高流量，用流量测试转化率和动销率，而后想办法提高这两点。一旦转化率稳定，才是买大流量的时候。这些都要有数据支撑试错。

LAANTO王巍表示，架构实际上是妥协的结果，受投入、团队技术水平多方面影响的，够用就好。从基础作好上云的准备，好比用memcache，redis等分布式缓存系统，把应用改形成与状态无关，一方面能够作到容易扩容，随时增长节点，另外一方面能够足够的可靠性，从而下降各方面成本；在成本有限的状况下，使用成熟技术，达到最优性价比便可，力争达到good，不放弃对perfect的追求；片面要求百分百可靠的都是异端。知足80%的高质量用户需求就够了。技术还得结合投入的多寡，凡是都有个投入产出比，所以要管理好老板的指望和用户的指望，所谓量力而行，作人如此，技术也是如此，作企业更是如此。秉承恰当的技术作恰当的事的理念。

就App而言，不少时候作App是为了估值。固然，依附与微信等高流量入口能够快速获取用户，缺陷在于人家的地盘听人家的，有着诸多限制，当用户积累到必定程度，业务受限于其平台的时候，作APP就成了必然的选择，所谓因时而动，顺势而为。

孔燕斌：从0到1的时候需求上的假设都没有验证，不必去折腾App，集中力量，快速把微信搞定，验证需求，累积用户，收集用户反馈。而后才能肯定是否真的须要App，绝大部分的App都是伪命题。一个App若是需求不找对，而且没有竞争对手，能够天然增加，靠补贴的话，一个用户20块钱都不必定够。因此需求须要验证的，以为很美妙的未必可行，不咋样的其实会很不错，是驴子是马都得拉出来溜过才知道。

 速普母婴Martin说，我是作母婴电商这块的，从去年4月份到如今，也是经历了团队从0到1，产品从0到1的过程，说说个人一点理解：

1. 人是最重要的，有个靠谱的CTO其实已经成功了一大半，CTO的经验决定了将来产品的技术栈啊。 一些小创业公司仰慕某些巨头的技术架构，技术专家，而后不惜花重金请来，专家出了各类高大上的方案，对么？巨头专家固然说的方案不能说不对，可是创业公司有可能还没到那个体量和基础，最重要的是，干活的技术人员，有可能连最基本的优化逻辑都没掌握呢。
2. 业务。产品初期能正常下单，库存能锁住，服务器稳定高可用就能够了。
3. 技术。个人理解是拿来主义，有现成的或者本身能掌握的技术千万不要去用那些最新的，一是新技术会引入时间成本，创业公司通常耗不起啊，另外新技术的把控不住可能会在将来形成难以预估的灾难。
   
   咱们第一期作的比较简单，主要分三块：前端、业务层、数据层。前端分移动端（Android、IOS）、PC端，业务层开放restful接口给前端调用，http协议json传输数据，先后端分离，分开部署，接口文档工具采用了阿里的rap，减小前端后端人员的沟通成本。其中前端主要nginx分流，固然，还没用如今主流电商采用的nginx+lua，由于lua你们都没底把控不了。其次图片类的静态文件对接了三方的文件存储系统（又拍）。
   
   后端业务层采用了springmvc+mybatis，应用服务器是tomcat，搜素业务采用了solr，还有几台队列服务器rabbitmq（用在订单业务上）。至于数据层，则分为分布式缓存和持久化数据。分布式缓存采用了豌豆荚开源的codis方案，那时候redis3.0刚出来，不敢踩坑果断放弃了，其实也能够直接用ssdb双主，毕竟redis太耗内存了，尤为对创业型公司来讲，省钱是最主要的，ssdb和redis对比，读性能差的不大，而且ssdb采用leveldb作文件存储（固然也能够用rocksdb存储），摆脱了内存的限制，在京东等一些网站都有成功的案例。
   
   至于持久化数据这层（mysql），考虑到电商业务初期，采用了读写分离，选择了MHA方案（LVS+Atals+MHA），还有数据库设计，不要用数据库特有的，好比存储过程，还有反范式设计，减小表的关联查询，对后期的分离、服务、可读性作考虑。

谢文渊表示，从0到1建电商上面同窗把一些关键点都说了很是清楚，我作过几个这种从0到1的电商，说说个人几点见解：

从0到1，说明是一个企业的一个新的IT领域，不少业务策略和基础根基都是不成熟，无论是业务仍是技术架构，同时还有个共同特征：上线周期短，新团队在上面的状况下，有几个方面是须要重点关注的：

 1. 业务流程

这一块是全部工做的基础，包括调研和梳理业务流程，主要涵盖正向流程如：采购、会员管理、商品价格、上下架、购买、订单管理、发货、财务等，逆向的更麻烦，如退换货、退款等另外一个核心就是促销规则，如套餐、团购、满赠、买赠、折扣、优惠券等，这个可先从简单入手，只是在架构设计考虑扩展项目周期缘由，必须的关键活动：会员注册、登陆、购买支付、订单审核、发货、对账。

 2. 应用架构

一开始业务量小，应用拆分适可而止，初期建议有商城前端、后台管理、订单管理、物流发货商城前端的演变将会是快速的，无论是业务模式仍是用户量规模，都会促使商城前端的快速迭代，其技术要求也是最高的，大多数在行业内分享的技术也都集中在这一块后台管理主要处理运营商城的需求，在线配置是重点，包括CMS订单管理也是后台应用，接口相对也多一些，如与ERP、WMS等，不少企业也在第三方电商平台上销售，如天猫、亚马逊等，能够接口接入物流发货比较规范，能够考虑外购，如WMS，也可外包，可省不少事。

 3. 技术领域

具体的技术细节不谈了，很是赞成前面同窗说的够用便可，不要追求高大上，也不要去学大平台的架构，这些架构也是从最简单的架构开始的，到如今这样也是被业务迫使的。必定要用团队最熟悉的技术或架构师最熟悉的，有几点能够参考：肯定技术标准，如分层，开发规范，采用的开源框架等，并培训抽取基础包或框架包，这个能够在边开发应用边抽取，如通用的Util、缓存操做类、数据访问等（这个好象全部软件项目都是这样，但很关键）初期不建议按模块拆分系统，作好模块划分，在配置管理上作区分便可虽然拒绝过分设计，但扩展性和安全性必定要考虑，提早考虑扩展性会让你在后续演变过程当中如鱼得水，尤为是商城前端的水平扩展，一般受到数据(配置或可卖数等)和会话的一致性限制，会话能够用memcache来管理，数据可加载到缓存如redis，一个可减小DB压力，二个能屏蔽DB层的演变，如分表分库等。

安全性是互联网上应用的永恒主题，可在框架层置入XSS和SQL注入的过滤器静态资源和动态内容作分离，商品详情页可作成伪静态化，静态和伪静态资源均可发布到CDN上，对用户体验仍是颇有帮助的，万一流量大时，也能保护后台服务，而且可减小带宽CMS能够从一些开源框架上作些改造来用，主要针对一些活动、首页的一些配置，若是有WAP和APP，能够用下阿里的RAP来管理接口，会大大提升接口的可管理性值得好好设计的几个地方：商品模型、促销规则引擎、多类型订单模型、第三方订单接入适配层部署上通常采用LVS(土豪可用商用的，如F5/Array) nginx(or other web server) app server DB(or cache)，一开始通常每层搞个双节点就行了。

另外，为了提升业务连续性，能够采用灰度发布，能够简单写些脚本，不必定要高大上的工具若是仅仅是从0到1，甚至在性能上都是可演进的，不少在并发容量、性能及高可用方面，是1以后的事情了以上只是简单从0-1的描述，但实际上细节仍是挺多的。对了，电商也算是互联网应用，对流量统计和转化率是运营的抓手，这些数据必定要有，流量能够用百度的就行，转化率得从后台出数据了，作些简单报表也是必须的。