让网站运营更简单
让搜索引擎更喜欢的网站
立即咨询
福利，定制网站送小程序， 名额有限，先到先得
完全从0到1建设一个电商网站，技术选型和注意事项有哪些？这里结合几位大牛实际工作经历分享下经验教训和心得，供正在互联网+转型的企业技术人参考对于早期的技术选型，不要抄大公司经验，按需求出发，先活下来再说。
要考虑到哪些是可以省的，那些是可以用现成的，哪些是需要有特色自己开发的早期手段可以粗糙，尽量考虑云云服务真的可以解决很多创业初期的一些棘手问题，而且可以省下成本0到1解决的是卖什么、怎么卖、卖给谁的问题。
思考的角度分为技术化域和商业化域技术域， 是实用生存为主， 不求高大上， 但求快速实用； 商业领域，就是经营变现了， 细分领域夺城拔寨重要的是，寻找到盈利点，建立合适的商业模式，然后通过技术来实现，除非技术驱动产品这样的公司完全以技术为核心，掌握核心就掌握市场。
如果不及时考虑盈利问题，可能面临以下的问题：公司跟风耗费巨资投入一个项目，技术部门找了很多人，并且采用了各种高大上的项目，结果盈利没跟上来，最终公司决定不再急需投入，项目就黄了，研发团队也解散了......
上海微肯CTO孔燕斌认为，流量是电商的最大成本和成功的关键因素之一，关于流量的问题其实就是怎么卖和卖给谁的问题现在线上流量的成本是非常高的，而且传统的线上流量都是一次性的，为什么叫一次性，是因为即使是同一个用户，要再次唤醒，大部分时候还是要支付额外的成本，流量的成本谁一值跟着运营高企不下。
线
基于篇幅的限制，在此不一一展开
青岛海尔Jan认为，关于网站的流量，严格来说流量≠客户量，当然这也得看如何定义流量更多看的是网站访问者或是App使用者的访问情况，从进入第一个页面到最后退出，这样一个全流程客户量，相对于网站来说，我的注册客户多少，日访问客户多少(流量分析工具可以实现)，成交客户量等等，需要结合实际公司的对客户量的定义，结合流量分析。
初期除了购买流程上不能有技术短板外，产品为核心的营销数据流也很重要。提升流量，用流量测试转化率和动销率，然后想办法提升这两点。一旦转化率稳定，才是买大流量的时候。这些都要有数据支撑试错。
LAANTO王巍认为，架构其实是妥协的结果，受投入、团队技术水平多方面影响的，够用就好从基础做好上云的准备，比如用memcache，redis等分布式缓存系统，把应用改造成与状态无关，一方面可以做到容易扩容，随时增加节点，另一方面可以足够的可靠性，从而降低各方面成本；在成本有限的情况下，使用成熟技术，达到最优性价比即可，力争达到good，不放弃对perfect的追求；片面要求百分百可靠的都是异端。
满足80%的高质量用户需求就够了技术还得结合投入的多寡，凡是都有个投入产出比，因此要管理好老板的期望和用户的期望，所谓量力而行，做人如此，技术也是如此，做企业更是如此秉承恰当的技术做恰当的事的理念就App而言，很多时候做App是为了估值。
在于人家的地盘听人家的，有着诸多限制，当用户积累到一定程度，业务受限于其平台的时候，做APP就成了必然的选择，所谓因时而动，顺势而为
孔燕斌：从0到1的时候需求上的假设都没有验证，没必要去折腾App，集都不一定够。
所以需求需要验证的，觉得很美妙的未必可行，不咋样的其实会很不错，是驴子是马都得拉出来溜过才知道
速普母婴Martin认为，产品从0到1的过程，人是最重要的，有个靠谱的CTO其实已经成功了一大半，CTO的经验决定了未来产品的技术栈啊 一些小创业公司仰慕某些巨头的技术架构，技术专家，然后不惜花重金请来，专家出了各种高大上的方案，对么？巨头专家当然说的方案不能说不对，但是创业公司有可能还没到那个体量和基础，最重要的是，干活的技术人员，有可能连最基本的优化逻辑都没掌握呢。
在业务上产品初期能正常下单，库存能锁住，服务器稳定高可用就可以了在技术上是拿来主义，有现成的或者自己能掌握的技术千万不要去用那些最新的，一是新技术会引入时间成本，创业公司一般耗不起啊，另外新技术的把控不住可能会在未来造成难以预估的灾难。
我们第一期做的比较简单，主要分三块：前端、业务层、数据层前端分移动端（Android、
其中前端主要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，说明是一个企业的一个新的IT领域，很多业务策略和基础根基都是不成熟，不管是业务还是技术架构，同时还有个共同特征：上线周期短，新团队在上面的情况下，有几个方面是需要重点关注的：业务流程。
这一块是所有工作的基础，包括调研和梳理业务流程，主要涵盖正向流程如：采购、会员管理、商品价格、上下架、购买、订单管理、发货、财务等，逆向的更麻烦，如退换货、退款等另一个核心就是促销规则，如套餐、团购、满赠、买赠、折扣、优惠券等，这个可先从简单入手，只是在架构设计考虑扩展项目周期原因，必须的关键活动：会员注册、登录、购买支付、订单审核、发货、对帐。
应用架构一开始业务量小，应用拆分适可而止，初期建议有商城前端、后台管理、订单管理、物流发货商城前端的演变将会是快速的，不管是业务模式还是用户量规模，都会促使商城前端的快速迭代，其技术要求也是最高的，大多数在行业内分享的技术也都集中在这一块后台管理主要处理运营商城的需求，在线配置是重点，包括CMS订单管理也是后台应用，接口相对也多一些，如与ERP、WMS等，很多企业也在第三方电商平台上销售，如天猫、亚马逊等，可以接口接入物流发货比较规范，可以考虑外购，如WMS，也可外包，可省很多事。
技术领域具体的技术细节不谈了，非常同意前面同学说的够用即可，不要追求高大上，也不要去学大平台的架构，这些架构也是从最简单的架构开始的，到现在这样也是被业务迫使的一定要用团队最熟悉的技术或架构师最熟悉的，有几点可以参考：确定技术标准，如分层，开发规范，采用的开源框架等，并培训抽取基础包或框架包，这个可以在边开发应用边抽取，如通用的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的描述，但实际上细节还是挺多的。
对了，电商也算是互联网应用，对流量统计和转化率是运营的抓手，这些数据一定要有，流量可以用百度的就行，转化率得从后台出数据了，做些简单报表也是必须的更多"互联网+"案例，请阅读原文，访问ITA1024 中国互联网+第一网站。
构、政策研究机构，整合社会化资源、打造社会化组织、建立社会化服务平台。
为互联网企业和传统企业“互联网+互联网”升级转型战略提供必要的专家资源、媒体资源、资本资源、技术资源为企业提供有价值的资讯&数据服务、跨界连接服务、“互联网+”商学院服务/技术学院服务/专家服务、媒体包装推广服务、融资对接服务。
本文图文来源于网络，版权属于原作者或网站，内容为作者观点，内容版权归原作者所有、本站不对文章中的任何观点负责，内容只用于提供信息阅读，无任何商业用途。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站（文章、图片、音频、视频）有涉嫌抄袭侵权/违法违规的内容，请联系管理员，一经查实，将立刻删除、维护您的正当权益。
扫一扫，关注我们
