大型电商常规功能点压力分析（B2B2C）

1 作者：kongqz

1.1 blog:http://blog.csdn.net/kongqz

2 核心业务功能模块

2.1 提醒

2.1.1 邮件

2.1.2 短信

2.1.3 站内消息

2.1.4 IM？

2.2 滤词系统

2.3 前台

2.3.1 订单

2.3.2 卖家

2.3.3 搜索

2.3.4 商品

2.3.5 提现、对账

2.3.6 促销

2.3.7 投诉仲裁

2.4 后台

2.4.1 买家

2.4.2 卖家

2.4.3 合同

2.4.4 其他支持业务系统

2.4.5 关键词销售系统

3 大数据量

3.1 买家数

3.1.1 买家数量是一个累积增长的过程

3.2 卖家数

3.2.1 中国号称有4000万的中小企业

3.3 订单数

3.3.1 一个买家可以形成多个订单

3.4 评论数

3.4.1 评论几乎是和订单系统平行

3.5 产品数量

3.5.1 每个卖家会发布多个产品

3.6 邮件数量

3.6.1 每个订单从生成开始整个流程会触发多个通知操作

3.7 站内消息数量

3.7.1 买家和卖家的交互大部分是通过站内消息的方式

3.7.2 买家和卖家的消息也可以以IM形式存储

3.7.3 买家和卖家的消息是整个平台做仲裁的重要依据

3.8 账务信息数

3.8.1 与订单息息相关

3.9 用户行为存储

4 大并发量

4.1 产品终极页

4.1.1 淘宝的70%的订单发起地址是产品终极页

4.1.2 所有活动都会导向这个页面

4.2 垂直搜索

4.2.1 大部分的产品查找都会通过这个引擎

4.2.2 很多公司的B2C和B2B2C同时推进，这个搜索需要整合两部分数据

4.3 订单数

4.3.1 促销以及常规的营销活动会带来比较大的并发量

4.3.2 促销活动产生的压力

4.4 站内消息数

4.4.1 对于一些B2B2C类型的电商，站内消息是买家和卖家唯一沟通渠道

4.4.2 属于产生订单的触发型操作

4.4.3 平均一个订单会产生4个以上的站内消息

4.5 邮件信息数

4.5.1 一个订单平均会触发4个以上的邮件操作

4.5.2 邮件的发送要求准实时

4.5.3 属于订单产生的触发型操作

4.6 产品图片

4.6.1 每个产品对应多个图片

4.6.2 图片的展示一般通过cdn进行加速

4.6.3 属于访问量带来的不可避免的访问压力

4.7 用户行为记录

4.7.1 用户触发型的动作

5 理解的几个架构核心算法

5.1 一致性hash算法

5.2 分布式算法paxos算法

5.3 LRU算法

6 核心目标

6.1 干掉小型机

6.2 干掉oracle，都用免费的mysql

6.3 支持大数据量

6.4 支持高并发

6.5 支持线性拓展

6.6 保证HA

7 分布式不可避免的损失

7.1 数据统计只能单独处理

7.2 为了HA我们必须付出成倍的机器

7.3 为了加速我们需要更大的带宽

7.4 为了性能我们将冗余较多字段

7.5 系统膨胀到一定程度，我们的必须SOA

8 常规技术

8.1 系统垂直拆分

8.1.1 卖家系统

8.1.2 买家系统

8.1.3 商品系统

8.1.4 邮件系统EDM

8.1.5 评论系统

8.1.6 财务系统

8.1.7 日志审计系统

8.1.8 消息系统

8.1.9 资讯系统

8.1.10 其他业务系统

8.1.11 支付系统

8.1.12 对账系统

8.2 分布式数据库

8.2.1 订单需要用分布式的方式存储

8.2.2 买家需要使用分布式方式存储

8.2.3 卖家需要进行分布式存储

8.2.4 消息需要采用分布式存储

8.2.5 商品需要用分布式方式存储

8.2.6 策略推荐

客户端方式可以用阿里的cobar

有局限性是只能在spring+myabatis下使用

如果有机器可以用阿里的cobar-server

粗糙一点的用变形虫amode

华丽一点的可以考虑用淘宝的tddl

8.3 异步的消息服务器

8.3.1 核心就是订单产生的时候通知买家和卖家

8.3.2 邮件提醒需要消息服务器做缓冲

8.3.3 站内消息建议也通过消息服务器做缓冲

8.3.4 策略推荐

一般基本的推荐activemq做集群和failover机制

较大数据量推荐淘宝的开源消息服务器Metaq

8.4 图片加速

8.4.1 全国CDN加速

8.4.2 图片的分布式存储策略

8.4.3 图片的加工提速

8.4.4 策略推荐

淘宝的tair文件系统

8.5 海量数据计算

8.5.1 统计用户行为类的

8.5.2 商业BI类的

8.5.3 策略推荐

较大数据量建议使用hadoop

4T以下数据量使用mongodb

8.6 终极页静态化

8.6.1 建议全部静态化

8.6.2 memache去支持静态页上的动态数据的动态创建

8.6.3 策略推荐

freemark做可静态化资源的静态化

velocity做可静态化资源的静态化

8.7 机房异构

8.7.1 一般淘宝的数据量可能需要这样的操作，常规电商不建议

8.7.2 一般通过数据库层次的同步

8.7.3 通过消息服务器进行部分信息的传递

8.8 垂直搜索

8.8.1 就是通过mapreduce这类搜索直接放到文件系统上进行

8.8.2 将搜索结果cache到memcache这类集群或者mongodb上

8.8.3 策略推荐

solr+luence

8.9 服务治理

8.9.1 上边列出的系统只是业务系统的一部分，多个系统的接口需要统一管理

8.9.2 服务治理最好简化为一种语言，方便通讯

8.9.3 策略推荐

阿里的dubbo

淘宝曾经开源的HSF

8.10 单点SSO

8.10.1 将系统进行拆分后，SSO是一个核心引擎在不同系统间切换

8.10.2 针对支付类的操作，建议做二次密码验证

8.10.3 策略推荐

CAS

有时间还是自己写吧

8.11 ESB

8.11.1 核心工作就是服务编排，以及数据流转编排

8.11.2 并发量有限，一般放到后端进行比较合适

8.11.3 策略推荐

mule

camel

8.12 工作流引擎

8.12.1 主要是平台商角度需要进行订单流转以及业务的变更需要

8.12.2 暂时这类系统除非自己构建，无法支持较大数据量以及并发量

8.12.3 策略推荐

activiti（jbpm4.4的升级版）

关注规则引擎的可以用jbpm5

8.13 审计日志收集

8.13.1 较大数据量增加网卡，写本地磁盘延迟传送

8.13.2 策略推荐

推荐开源项目：timetunel，经过证明可以每天进行4T的数据量传送

中小数据量就activemq即可

8.14 定时任务调度

8.14.1 用来执行一些定时任务

8.14.2 策略推荐

利用quartz本身的集群特性

利用淘宝的定时任务项目taobaoschedule

BTW:附上mindjet图