原电商设计框架

好久没更新博客了. 现在慢慢更新下吧 . 简单介绍下原来电商框架的基本架构图.

基本架构图

image.png

说明

这里简单减少下之前电商框架使用的架构模式.

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来做积分的加减.

然后有个对账程序来补漏

原文地址:https://www.cnblogs.com/ztteng/p/9767585.html