转： 从0到1的电商架构应该怎么作？

from:  https://yq.aliyun.com/articles/54414

 

1. 摘要：

问题提出

今天在电商金融架构群里，来自蚂蚁金服的于总抛出了一个问题：“彻底从0到1建设一个电商网站，技术上如何选型，如何快速上线？”

群友们集思广益

参与讨论的电商公司背景：有来自传统行业的“互联网+”式的电商平台，有目前正处在风口的“跨境电商”，也有来自知名大公司的电商实践等。

 

UC的莫俊彬说：

我以为...先把基础设施弄好，上云..搞业务..这样精力就集中了”（给赞，还卖了一手好萌）。

 

北京的isnow分享了他的经历：

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

 

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

 

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

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

 

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

 

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

 

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

 

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

 

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

 

• UC的莫俊彬接着问了一个问题：“初期数据支撑，这块感受很差作，不知道有没专作这块服务的公司。”
• 来自北京的俞斌说：“咱们所有阿里云。”
• 来自深圳的小刚说： 咱们的业务才刚起步，技术上没有太多的创新。

1. 硬件带宽：非核心业务，阿里云；
2. 总体架构：分层模式+微服务模式，可复用的核心功能下沉、抽成服务。
3. 技术选型

            3.1.  网站前端php+yii+thrift+阿里ocs+mysql；

            3.2.  后台服务spring+mybatis+thrift+dubbo+mysql

 

• 最后来自友群的朋友分享了他们的经验：

咱们如今电商平台，算是从0-1，我全程参与过，技术选型也都参与讨论过，如今来看的话，犯过如下几个错误：

 

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

 

总结

 

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

 

快速上线，知足目标不要作过多设计，大概用到的技术堆栈有：

电商平台通常都分为面向客户的客户端网站系统、面向公司内(或第三方平台)的业务系统以及运维平台(云平台)。

 

对于面向客户端的网站系统主要包括如下几个模块：

    1. 用户管理系统

    2. 商品管理系统

    3. 支付系统

    4. 订单管理系统

    5. 评价系统

 

对于面向公司内(或第三方平台)的业务系统主要包括如下几个模块：

人员管理以及权限管理系统

• 客户服务系统
• 订单管理系统
• 财务管理系统
• 商品维护系统
• 数据统计系统
• 运营支撑系统

 

主要架构图：

 

 

从图中咱们能够很清晰的看到大概的技术栈：

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的电商平台建设的一些建议

 

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