原电商设计框架
好久没更新博客了. 现在慢慢更新下吧 . 简单介绍下原来电商框架的基本架构图.
基本架构图
说明
这里简单减少下之前电商框架使用的架构模式.
DNS
域名解析. 这里不用多少
CDN
静态资源,比如商品的图片可以缓存到CDN里. 减轻服务器压力.
还支持用户就近原则.用户可以就近去cdn里去缓存信息
keepalived+lvs
主要三个能力
- Keepalived 提供vip能力以及lvs的容灾能力.
- lvs提供第四次的负载均衡能力
业务量小的时候.完全没必要使用.直接上nginx就行.
但是这里有个问题就是nginx成为单点.一旦nginx挂了.整个后面就不可用了.不过现在都上云了一般也没人搭这个. 云上一般都有vip和四层负载均衡的能力
web服务器
- 解析url内容并按协议组装请求包
- 根据配置中心决定下发到哪台后端服务
有些不用访问到后台数据的或者流量不到的直接web服务怼就行了,不用请求到后端.这里说正常业务.
这里用的是go版本的cgi. 接受用户请求解析.然后按照规定的序列号请求包请求到后端服务
配置中心
每台机器上有配置中心服务
- 读取db里面服务对于的ip地址
- 把信息存到内存中
- 服务进程读取内存中对于的服务地址
配置中心有些功能还没有其实可以加上. 后端每个服务、每个机器上报自己的负载情况.然后配置中心根据这些上报的信息.来自动摘除和重新上架服务
web服务器调用后台服务
路由策略
- 随机路由
- uid路由
- 权重路由
权重路由. 这里还没做. 其实可以做. 根据后端服务的负载情况给每个服务一个加权值.负载高的就少分点请求.负载低的可以多分点请求
后端服务
主要三个组件
- netio
- container
- back_netio
具体就不介绍了. 我之前有4片博客介绍了.
redis
主要用来做商品详情的缓存.减少对db的压力
其次 秒杀的时候用了有序集合来做队列
RabbitMQ
- 异步解耦
- 晓峰
我们主要还是异步解耦. 比如下单送积分. 支付成功后会丢一个消息到mq里。然后有消费者拉去mq来做积分的加减.
然后有个对账程序来补漏