原电商设计框架

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

基本架构图

说明

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

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

而后有个对帐程序来补漏