完全从0到1打造一个电子商务网站，技术选型和注意事项有哪些？在此，我们根据几位专家的实际工作经验，分享经验、教训和见解，供正在进行互联网+转型的企业技术人员参考。

早期的技术选型，不要照搬大公司的经验，根据需求出发，先生存下来。需要考虑哪些可以保存，哪些可以用现成的，哪些需要自己开发有独特的特点。早期的方法可能比较粗糙，并尝试考虑云。云服务确实可以解决创业初期的很多棘手问题，节省成本。

0到1解决的是卖什么、怎么卖、卖给谁的问题。思维角度分为技术领域和商业领域。在技​​术领域，注重实用生存，不求高端，但求快速、实用；商业领域，是商业变现，攻克细分区域城镇。

重要的是找到盈利点，建立适合的商业模式，然后通过技术来实现。除非一个技术驱动产品的公司完全以技术为中心，否则掌握了核心就控制了市场。

如果不及时考虑盈利问题，可能会面临以下问题： 公司跟风，花巨资投资一个项目。技术部聘请多人，采用各类高端项目。结果，利润跟不上，最终公司决定不再继续经营。急需投资，项目被放弃，研发团队解散……

上海维肯CTO孔彦斌认为，流量是电商最大的成本，也是成功的关键因素之一。关于流量的问题，其实就是怎么卖、卖给谁。

现在线上流量成本很高，传统线上流量是一次性的。之所以称为一次性，是因为即使同一个用户想要再次唤醒，大多数时候他仍然要支付额外的费用。运营中的流量成本仍然很高。

这里强烈推荐微信流量。微信流量有几个优势。一是有足够的用户。二是它有公众号，可以免费唤醒用户。三是具有社交属性，可以通过朋友圈、优惠券、微信来使用。用于营销的支付和其他微信功能。对于初创公司来说，最重要的是可以利用微信的近场能力在线吸引人，以非常低的成本高效、快速地吸引人。

线下招人的最大好处就是可以通过选择地点来筛选你的潜在用户。为此，需要在系统架构中添加微信模块，以实现与微信相关的营销功能。快速找到第一批客户验证业务，完成0到1，再到1到100、1000，在微信的流量中可以很好的进行复制，有效降低运营中的流量成本。由于篇幅限制，这里不再一一讨论。

青岛海尔简认为，对于网站的流量，严格来说，流量≠客户数。当然，这也要看它是如何定义的。流量更多地取决于网站访问者或应用程序用户的访问状态，从进入第一页到最终退出，这样一个整个过程。客户量，相对于网站来说，我有多少注册客户，每天有多少访问客户（流量分析工具可以实现这个），交易客户数等，需要结合实际公司对客户量的定义和流量分析。

除了前期购买流程缺乏技术短板之外，以产品为中心的营销数据流也非常重要。增加流量，用流量来测试转化率和销售率，然后想办法提高这两点。一旦转化率稳定，就该购买大量流量了。所有这些都必须有试验和错误数据的支持。

王伟认为，架构其实是妥协的结果，多方面受到投资和团队技术水平的影响。

做好从基础上云的准备，比如使用分布式缓存系统等，将应用转变为状态无关的应用。一方面，可以方便地扩展，可以随时添加节点。另一方面，它可以足够可靠，从而降低各种任务的成本。在成本方面；当成本有限时，只用成熟的技术达到最佳的性价比，力争做到优秀，永不放弃对正确的追求；片面要求 100% 可靠性是异端邪说。足以满足80%的优质用户的需求。

技术必须与投资数额相结合。任何事物都有投入产出比。因此，有必要管理老板的期望和用户的期望。所谓量力而行。对人如此，对科技如此，对企业更是如此。秉承用正确的技术做正确的事的理念。

就应用程序而言，很多时候制作应用程序的目的是为了估值。当然，依靠微信等高流量入口可以快速获取用户。缺点是别人的领地依赖别人，限制很多。当用户积累到一定程度，业务受限于平台，做APP就成为必然。选择，正所谓与时俱进，顺应潮流。

孔彦斌：从0到1，关于需求的假设还没有得到验证。无需再折腾App。集中精力快速完成微信，验证需求，积累用户，收集用户反馈。只有这样您才能确定您是否真的需要该应用程序。大多数应用程序都是错误的命题。如果一个App不能满足正确的需求，没有竞争对手，它就能自然增长。如果靠补贴，每个用户20元可能还不够。因此，需要验证需求。你认为美好的事情不一定可行。不太好的事情实际上非常好。你要把它拉出来才知道是驴还是马。

速普母婴认为，一个产品从0到1的过程中，人是最重要的，拥有一个靠谱的CTO，其实已经成功了一大半。 CTO的经验决定了未来产品的技术栈。一些初创的小公司很欣赏某些巨头的技术架构和技术专家，然后花重金请专家来想出各种高大上的解决方案，对吗？当然，巨头专家提出的解决方案不能说是错的，但创业公司可能还没有达到那样的规模和基础。最重要的是，从事其工作的技术人员可能连最基本的优化逻辑都没有掌握。

在商业上。产品初期能正常订购、能锁定库存、服务器稳定、高可用就足够了。从技术上来说。这是借钱的问题。如果有现成的技术或者你能掌握的技术，就不要使用最新的。首先，新技术会带来时间成本，这是初创公司一般无法承受的。此外，无法控制新技术可能会导致问题。给未来带来难以预料的灾难。

第一阶段我们做的比较简单，主要分为三个部分：前端、业务层、数据层。前端分为移动端（IOS）和PC端。业务层开放接口供前端调用。 HTTP协议json传输数据。前后端分离，单独部署。接口文档工具使用阿里巴巴的rap，降低前后端人员的沟通成本。 。其中，前端主要是分流的。当然，目前主流电商都在使用的+lua并没有被使用，因为没人能驾驭lua。其次，将图片静态文件接入三方文件存储系统（再次拍摄）。

后端业务层使用+，应用服务器使用solr，搜索业务使用solr，还有若干个队列服务器（订单业务使用）。至于数据层，分为分布式缓存和持久化数据。分布式缓存采用豌豆荚开源方案。当时.0刚刚出来，不敢踏入陷阱，果断放弃。其实也可以直接使用SSDB双主。毕竟太消耗内存了，尤其是对于创业型公司来说。钱是最重要的。与ssdb相比，读取性能相差不大。而且ssdb采用文件存储（当然也可以用于存储），摆脱了内存的限制。在京东等一些网站上就有成功的案例。

至于持久数据层（），考虑到电商业务前期，我们采用了读写分离，选择了MHA方案（LVS++MHA），以及数据库的设计。不要使用数据库特定的，例如存储过程，反范式设计减少表关联查询并考虑后期分离、服务和可读性。

谢文渊表示，从0到1，说明对于企业来说是一个新的IT领域。很多业务策略和基础基础还不成熟，无论是业务还是技术架构。同时还有一个共同特点：上线周期短、团队新 在上述情况下，有几个方面需要重点关注：

业务流程。该区域是所有工作的基础，包括业务流程的研究和梳理，主要涵盖：采购、会员管理、商品价格、上架下架、采购、订单管理、发货、财务等正向流程。比较麻烦的，比如退货、换货、退款等，核心问题是这些都是促销规则，比如套餐、团购、赠品、免购、折扣、优惠券等。可以先从简单的开始，但要考虑架构中延长项目周期的原因 设计。必要的关键活动：会员注册、登录、购买和支付。 、订单审核、交付、对账。

应用程序架构。一开始业务量小，应用拆分就够了。前期建议有商城前端、后端管理、订单管理、物流配送。商城前端的演进将会是快速的，无论是商业模式还是用户规模，都将推动商城前端的发展。快速迭代也对技术要求最高。业界分享的大部分技术也都集中在后端管理这个领域。主要满足经营商场的需求。在线配置是重点，包括CMS订单管理和后端应用。它的接口相对较多，比如ERP、WMS等。很多企业也在第三方电商平台上销售，比如天猫、亚马逊。等等，接口可以对接物流配送，更加标准化。可以考虑外包，比如WMS，或者外包，可以省去很多麻烦。

技术领域。具体的技术细节我就不说了。我非常同意前面同学说的。够了。不要追求高标准，也不要学习大平台的架构。这些架构也是从最简单的架构开始的。直到今天，他们仍然受到商业的逼迫。的。一定要使用团队最熟悉的或者架构师最熟悉的技术。有几点可供参考：确定技术标准，如分层、开发规范、采用的开源框架等，训练提取基础包或框架包。这可以在开发应用程序时在中完成，例如常用的Util、缓存操作类、数据访问等。（似乎所有软件项目都是如此，但非常重要。）在前期，是不建议将系统按模块拆分，将模块划分好。只是在配置管理上进行区分。虽然拒绝过度设计，但必须考虑可扩展性和安全性。提前考虑可扩展性，会让你在后续的演进过程中游刃有余，尤其是商城前端的横向扩展，通常会受到数据（配置或可售数量等）以及一致性限制的影响。 ，可以使用进行管理，数据可以加载到缓存中。比如一是可以减轻DB压力，二是可以屏蔽DB层的演进，比如分表分库等。

安全是互联网应用永恒的主题。 XSS和SQL注入过滤器可以放置在框架层，以分离静态资源和动态内容。商品详情页可以做成伪静态，静态和伪静态资源都可以发布到CDN上，对于用户体验还是很有帮助的。在流量大的情况下，还可以保护后台服务，减少带宽。 CMS可以安装在一些开源框架上。做一些修改来使用，主要是针对一些活动和首页的一些配置。如果您有WAP和APP，可以使用阿里巴巴的RAP来管理界面，这将大大提高界面的可管理性。几个值得仔细设计的地方：产品模型、促销规则引擎、多类型订单模型、第三方订单接入适配层部署一般使用LVS（土豪可以使用商业的，如F5/）（或web）app DB（或），通常一开始每层只有两个节点。

另外，为了提高业务连续性，可以采用灰度发布，编写一些简单的脚本。它不一定是一个复杂的工具。如果只是从0到1，甚至可以在性能方面进化。很多都是在并发能力方面，在性能和高可用性方面，都是在1之后。上面只是从0到1的简单描述，但其实细节还蛮多的。顺便说一句，电子商务也可以看作是一种互联网应用。流量统计和转化率是运营的起点。这些数据必须可用。流量可以用百度。转化率数据必须由后台生成。还需要做简单的报告。的。