今天在架构师俱乐部3群（由ArchSummit全球架构师峰会运营）里，大家围绕着一个话题讨论地很热烈——完全从0到1建设一个电商网站，技术选型和注意事项有哪些？群友们都结合自己的实际工作经历分享了很多经验教训，这里是其中的精选。
一，青岛海尔Jan给大家分享了一个失败案例的教训：
- 没有准确估计实际业务量或者说就没有估计过，导致技术选型直接参考京东、淘宝一线大公司，实现较复杂，技术铺的也很大。（教训：技术够用就好，选型的目标是能够快速实现产品的迭代）
- 因为缺少经验，前期业务没有明确的规划，技术选型也没有考虑高内聚、低耦合，导致系统之间依赖太强，导致现在想拆分很难。
- 选择了一些较新的技术框架，过于依赖几位关键的技术牛人，结果这些人一旦离职，就陷入迷茫。（教训：关键人员一定要留住，或者有备份人选）
还有群友表示，对于早期的技术选型，不要抄大公司经验，按需求出发，先活下来再说。要考虑到哪些是可以省的，那些是可以用现成的，哪些是需要有特色自己开发的。早期手段可以粗糙，尽量考虑云。云服务真的可以解决很多创业初期的一些棘手问题，而且可以省下成本。
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的过程，说说我的一点理解：
- 人是最重要的，有个靠谱的CTO其实已经成功了一大半，CTO的经验决定了未来产品的技术栈。 一些小创业公司仰慕某些巨头的技术架构，技术专家，然后不惜花重金请来，专家出了各种高大上的方案，对么？巨头专家当然说的方案不能说不对，但是创业公司 有可能还没到那个体量和基础，最重要的是，干活的技术人员，有可能连最基本的优化逻辑都没掌握呢。
- 业务。产品初期能正常下单，库存能锁住，服务器稳定高可用就可以了。
- 技术。我的理解是拿来主义，有现成的或者自己能掌握的技术千万不要去用那些最新的，一是新技术会引入时间成本，创业公司一般耗不起啊，另外新技术的把控不住可能会在未来造成难以预估的灾难。
3.1我们第一期做的比较简单，主要分三块：前端、业务层、数据层。前端分移动端（Android、IOS）、PC端，业务层开放restful接口给前端调用，http协议json传输数据，前后端分离，分开部署，接口文档工具采用了阿里的rap，减少前端后端人员的沟通成本。其中前端主要nginx分流， 当然，还没用现在主流电商采用的nginx+lua，因为lua大家都没底把控不了。其次图片类的静态文件对接了三方的文件存储系统（又拍）。
3.2 后端业务层采用了springmvc+mybatis，应用服务器是tomcat，搜素业务采用了solr，还有几台队列服务器rabbitmq（用在订单业务上）。至于数据层，则分为分布式缓存和持久化数据。分布式缓存采用了豌豆荚开源的codis方案，那时候redis3.0刚出来，不敢踩坑果断放弃 了，其实也可以直接用ssdb双主，毕竟redis太耗内存了，尤其对创业型公司来说，省钱是最主要的，ssdb和redis对比，读性能差的不大，并且 ssdb采用leveldb做文件存储（当然也可以用rocksdb存储），摆脱了内存的限制，在京东等一些网站都有成功的案例。
3.3 至于持久化数据这层（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的描述，但实际上细节还是挺多的。对了，电商也算是互联网应用，对流量统计和转化率是运营 的抓手，这些数据一定要有，流量可以用百度的就行，转化率得从后台出数据了，做些简单报表也是必须的。
本次讨论还包括其他群友的分享，一并感谢，在这里就不一一列出名字了。