从0到1的电商架构应该怎么做？

关于如何架构一个电商，虽然作为一个开发人员，各种技术栈都有所了解，但如何运营一个产品没有宏观的概念。 特别是缺乏硬件设施，负载均衡，CDN，运维之类的直接经验。
转载一篇博文：https://yq.aliyun.com/articles/54414?spm=5176.7910928.318187.4.djgTe4

问题提出
今天在电商金融架构群里，来自蚂蚁金服的于总抛出了一个问题：“完全从0到1建设一个电商网站，技术上如何选型，如何快速上线？”
群友们集思广益
参与讨论的电商公司背景：有来自传统行业的“互联网+”式的电商平台，有目前正处在风口的“跨境电商”，也有来自知名大公司的电商实践等。

UC的莫俊彬说：
我觉得...先把基础设施弄好，上云..搞业务..这样精力就集中了”（给赞，还卖了一手好萌）。

北京的isnow分享了他的经历：
“我们是去年10月份(注：2014年)从0到1搭建的电商网站，做知识产权电商，2b2c的业务，开始在首都在线的云上，前端是用bootstrap，使用nginx做负载均衡，后端用springmvc+spring+mybatis数据库用mysql，支付接入第三方支付，支付宝和银联支付，网站分前端用户访问和后端业务系统，分开部署，前端部署在两台tomcat上，mysql一主一备，这大概是我们的第一版系统的架构。开始的时候产品线比较单一，将主打的产品上线，然后在后期迭代过程中逐步上线其他业务。”

于总心想我才不相信你们没遇到问题，说问题。



然后isnow就开始倒苦水模式:

由于人员和流程的问题，每次上线都是直接将变动的class文件部署上去，代码管理没跟上；
随着业务线的增多，发现最开始的业务架构无法扩展，每次增加业务线代码重用效率不高；
由于业务线中存在大量的文件，导致随着订单的逐渐增多，文件io变慢 ；
随着业余订单的变多，订单访问开始变慢；
因为业务系统是o2o的模式，客户那边做业务的时候容易对业务经常状态变动，现阶段都是专人在数据库上更改数据状态，个人觉得太危险；
业务方变动太大，我们的产品暂时在市场上没有可借鉴的(第一个吃螃蟹的)，因此在业务上一直都是在变动，然后就形成了一种业务混乱的感觉。后来，招了cto，改第二版时候把大量的业务逻辑转移到数据库里用存储过程来解决，导致业务逻辑分散。
感觉创业公司其实技术过得挺艰难的，招不到好的人员，领导在新技术的尝试上往往步伐没那么大，不敢轻易上他没有把握的技术，有时候甚至为了稳定去将就一些技术甚至业务上的坑”。

于总看到这里瞬间不淡定了：“CTO的经验决定技术堆栈啊！存储过程是一个大坑，未来要分离，服务，可读性都是问题”。

小刚插了一句：“硬件和网络，直接买厂商的”(土豪任性)
来自金山的Kerwin说：“先想一个能扩展的框架”（果然是大公司的，家底就是厚呀）
北京的孔庆龙则说：完全从0到1 建设一个电商网站？

如何选型，首先要清楚自己想要什么这个就要做好业务分析和业务架构和战略整理，进而找到关键需求，通过关键需求来对市面上的技术或者套装软件进行选型——也就是应用架构选型。
快速上线：这个涉及到的问题较多，如数据架构、基础架构、应用架构、安全架构等一系列问题，如果安全架构不高那么上云是一个不错的选择，毕竟云可以提供一整套的PASS和SAAS解决方案。
关于技术栈：主要是根据自己的团队人员量身打造，从前到后有前端技术选型（jquery、Bootstrap等）、HTTP网关或LBS（nginx、F5等）、容器中间件（Tomcat、jboss、weblogic等）、应用（SSH、分布式的dubbo等）、数据库（mysql、redis、oracle、db2等），监控软件（应用监控、网络监控、数据库监控、服务监控等）
关于团队：如何快速构建如何上实现DEVOPS（技术工具如：maven、svn/git、sonar、jenkins、Confluence、jira、nexus等）

于总补充到：“容器中间件（Tomcat、jboss、weblogic等），现在都是tomcat 和jetty，其他的太重。”
刚开始做跨境电商的Jesse说：项目一个半月上线。

服务器与数据库直接买现成的，减少运维成本。目前我们是ECS加RDS，全是阿里云。 框架是Spring+Mybatis，服务器是tomcat
图片存储用的是OSS，自定义域名，CDN加速（也是阿里云的）首页优化包括动静分离，异步加载，用户首页打开速度从7秒多缩短到了3秒以内。 由于上线匆忙，很多细节来不及优化和确定。所以对于一些经常变动的模块直接用新的工程。这样要修改不会影响到其他模块。 代码管理用Git。没有service话，感觉用不到。
缓存直接是EHCache，每个机器都保存一份。没有用memcache，因为目前memcahche还是会增加管理成本。
负载均衡也是直接上阿里云的负载均衡
快速上线的一个问题就是好多技术设计的细节没有考虑完善，代码比较粗糙，但是又不能做大的调整，而且还要兼顾新的功能。目前的做法是，业务需要更改哪一个模块，就去在做业务的过程中去重构，而且做灰度发布。
业务上跨境电商的一个最大问题就是货币问题。不同国家的用户登录显示的货币要不一样。对于产品，报关是个大问题，现在这一块都是运营手动报关发货。现在还做不出来那种跨境DRP，即使购买现成的服务也不知道该咋用。 汇率是采用一个月取平均值。要判断是哪个国家的话。。先做成让用户自己选。。但其实现在就是中文和英文

UC的莫俊彬接着问了一个问题：“初期数据支撑，这块感觉不好做，不知道有没专做这块服务的公司。”
来自北京的俞斌说：“我们全部阿里云。”
来自深圳的小刚说： 我们的业务才刚起步，技术上没有太多的创新。
硬件带宽：非核心业务，阿里云；
整体架构：分层模式+微服务模式，可复用的核心功能下沉、抽成服务。
技术选型
            3.1.  网站前端php+yii+thrift+阿里ocs+mysql；
            3.2.  后台服务spring+mybatis+thrift+dubbo+mysql

最后来自友群的朋友分享了他们的经验：
我们现在电商平台，算是从0-1，我全程参与过，技术选型也都参与讨论过，现在来看的话，犯过以下几个错误：

没有准确估计实际业务量或是就没估计，导致技术选型直接参考京东，淘宝等一线公司，实现较复杂，技术铺的也很大。
因为缺少经验的原因吧，前期业务没有明确的规划，技术选型也没有考虑高内聚，低耦合，导致系统之间依赖太强，现在想拆分很难
选择了一些较新的技术框架，依赖于1~2个技术牛人，牛人离职，一片茫然。。。
初期除了购买流程上不能有技术短板外，产品为核心的营销数据流也很重要。提升流量，用流量测试转化率和动销率，然后想办法提升这两点。一旦转化率稳定，才是买大流量的时候。这些都要有数据支撑试错。

总结

最后我们总结了一下我们的讨论：

快速上线，满足目标不要做过多设计，大概用到的技术堆栈有：
电商平台一般都分为面向客户的客户端网站系统、面向公司内(或第三方平台)的业务系统以及运维平台(云平台)。

对于面向客户端的网站系统主要包括以下几个模块：
    1. 用户管理系统
    2. 商品管理系统
    3. 支付系统
    4. 订单管理系统
    5. 评价系统

对于面向公司内(或第三方平台)的业务系统主要包括以下几个模块：
人员管理以及权限管理系统
客户服务系统
订单管理系统
财务管理系统
商品维护系统
数据统计系统
运营支撑系统


主要架构图：

bcf9266ce3ff87592d9f82bfac5e8d079d5c8db6

从图中我们可以很清晰的看到大概的技术栈：
1. 前端系统:
     1.1 Web端技术选择:
            1.1.1 JS框架搭建
            1.1.2 PHP框架搭建
            1.1.3 JSP/Freemarker模板+UI框架(Bootstrap等)+Jquery工具
    1.2 移动端
           1.2.1 Android平台
           1.2.2 IOS平台
           1.2.3 Mobile(H5)平台
2. 后端系统
     2.1 负载均衡系统
        2.1.1 硬件类负载均衡器
              (1). NetScaler
              (2). F5
              (3). Radware
              (4). Array
       2.1.2 基于Linux免费开源的负载均衡软件策略
              (1). Nginx
              (2). LVS/HAProxy
              (3). Lighttpd、Apache-mod_proxy、Squid、Socks、TIS FWTK、Delegate等
     2.2 web容器集群(最基础的集群，一主一备)
        2.2.1 传统模式，将所有模块定义到同一个项目中发布到web容器中
        2.2.2 SOA模式(微服务模式),根据业务模块将系统进行拆分，分开部署，系统间使用rpc或rest方式调用。具体可参考dubbo(dubbox)、Spring-boot等框架。
    2.3 文件服务器
        2.3.1 储存方式
        2.3.2 储存容量
        2.3.3 安全性与存取权限控管
        2.3.4 存取效能
     2.4 缓存服务器
         2.4.1 分布式Redis缓存
         2.4.2 Memcache缓存
         2.4.3 EHCache等
     2.5 消息系统
         2.5.1 ActiveMQ
         2.5.2 分布式消息系统Kafka、Rocketmq等
     2.6 数据持久层
         2.6.1 关系型数据库
              (1). PostgreSQL
              (2). Mysql
              (3). Oracle、DB2等
         2.6.2 Nosql
              (1). MongoDB
              (2). HBase等

注：硬件解决方案的优点是：有专业的维护团队来对这些服务进行维护、缺点就是花销太大。软件解决方案的优点是费用低廉，缺点是开源系统，可能出问题得自己想办法找解决方案。

CTO(技术负责人)会很大程度上影响技术发展

CTO 在创业公司扮演了的角色很独特，创业公司CTO不仅负责业务上的开发任务，还负责扛住外界(其他部门负责人)的压力等。对内还要负责团队人员的合理搭配和安排，对外负责开发任务的安排和调控。 同时CTO在技术选型上更多时候考虑的是自身熟悉的技术以及稳定的技术，或许创业公司有更多的试错机会，但毕竟是身处创业的环境，外界环境不可能给予团队多次失误的机会， 因此在技术选型上包括公司技术走向上更多的取决于CTO对技术的熟练程度。

发展过程中遇到的问题

问题：
1.由于创业公司迭代非常频繁，因此运维上线的问题是最大一个很大的问题
我们开始的解决是每次将修改后的class文件直接替换线上环境，这种方案是非常危险的。后期我们搭建了自动部署平台，基于Git和Jenkins进行代码自动化部署。

2.前期由于各种各样的原因导致业务逻辑上耦合程度高，开发新业务线的成本很高
这个没办法，前面挖的坑后面慢慢填，然后在重构的时候，一点点的将业务独立出来，使用微服务方式进行架构。

3.前期未将系统中文件同代码分离出来，导致随着用户量增多，服务器IO越来越慢
搭建文件服务器，将所有文件移到文件服务器中，减轻web应用服务器的压力。

4.随着订单的增多，后台业务系统订单访问变慢
第一步，从sql优化的角度，看是否能够通过加索引等方式加快速度。第二步，计算订单相关表的读写比，进行分库分表操作。(目前我们团队还未到达这一步)

5.业务方需求变动太快或产品思路不清晰，每次迭代都是在挖坑
这个没办法，第一，寻找更加懂业务的产品经理。第二，业务开会须有核心业务开发人员参与，对需求或产品的发展做出中肯的评审

我们的关于从0到1的电商平台建设的一些建议

对核心业务思路要成熟，不要人云亦云，千万不要说"淘宝、京东就是这么搞的"。要结合自己的产品和业务去架构自己的平台。
在技术选择上，尽量选择开源稳定的方案，不要选特别新的技术。
前期可以将非核心数据或服务托管在稳定可靠的云服务平台上，集中精力将核心业务完成核心业务的开发和产品迭代，到团队有一定的积累后，可选择自主开发某些托管在云平台的服务。
能选择将业务分离开，则尽量分离开，以方便后期产品的重构。