第二讲：电商在双11大促活动下的架构体系

架构的演化之路是架构的演变，是纵向的比较。

双11大促是电商的横向的视角。

中台：实际上是一个企业架构，而不仅仅是一个业务架构

• 解决重复的功能建设，重复投资；

• 按照业务线数据不共享，数据孤岛，系统壁垒。

• 业务沉淀，业务共享。

• 大中台，小前台。

• 前台是指前台的系统：包括前台的前端和前台后端。而不仅仅是客户端。

技术中台：

持续集成：

• 服务部署打成jar包仍上去太原始，可以用jekins+docker进行部署，jenkins打包成镜像，推送到镜像仓库，rancher管理服务。

自动化测试：

• 自动化脚本

系统框架、监控、日志、部署集成。

• kibana进行集中日志系统的搭建，查看

业务中台：

数据中台【带有业务属性】：

区别与数据平台【数据库】，数据仓库【报表】。

运维中台

devops，运维负责硬件，研发同学自己发布服务进行部署。

配置管理：

zookeeper,applo,nacos更为主流

系统架构的考量：

 高性能：提供快速的访问体验。

 高可用：网站服务7*24正常访问

可伸缩：硬件弹性增加、减少能力【快速扩容与释放、运维部署层面，加减服务器】

扩展性：方便地增加/减少新的功能/模块（迭代与服务降级）

安全性：安全访问和数据加密、安全存储等策略。

敏捷性：快速应对突发情况的能力（灾备等）

内部的瓶颈：

木桶效应：最短板决定容量，水管最窄的地方决定流量

• 压测的目的就是找出木桶的最短的板。

CPU:序列化和反序列化，高频的日志输出，大量反射、大量线程的的应用。

内存：使用内存的中间件或者服务，如redis，jvm大量对象堆积内存的应用。

网络带宽：大流量高并发环境下，用户激增，造成网络拥堵。

磁盘IO: 文件上传下载，数据库频繁读写。不合理或者大批量的日志输出。

数据库的连接数：应用服务器连接池大批扩容，警惕底层数据库、redis等连接数瓶颈。

外部的服务：

短信

支付

快递平台

外部云存储

CDN: 找最近的IP给用户。

=================第二部分：业务中台：===============================

• 订单中心：

  • 异步化：消息队列

    • 异步化会引发消息的乱序问题，一是传输阶段，二是消费阶段。

    • 做法：同一个订单（可能有很多的状态）在通过的时候我们可以设置一个规则，将同一个订单路由到同一个通道。，保证异步接收的循序性。

    • 

  • kafka传输：

    • 根据分区保证其有序性。

    • 

    •  

• 过期订单：

  • 扫表实现：

    • 优点：实现简单

    • 缺点：大量数据集，对服务器的内存消耗大；数据库频繁查询，大订单下IO是瓶颈。

    •  

    •  

    •  

=============================================

• 慢sql查询
• 借助explain查看sql执行计划

• 策略：热点数据预热。
•  细粒度设计：
  • 两级缓存：第一级是商品的key,第二级是商品详情List.
• 缓存穿透：
  •  
• 缓存击穿：
  • 数据在数据库中有但是缓存中没有，可以都采用【大促前跑一个任务，热点数据预先加载】的方式解决。
• 浏览器的缓存
• 服务器的缓存
  •  
• CDN缓存：
  • 对用户做IP分流
• Nginx缓存：
  • 负载均衡，也可做请求级别的缓存。
• 分布式缓存
  • redis
  • 频繁的交互可以从业务端下移到lua脚本实现，一方面实现原子性【令牌桶算法】，一方面有效减少网络延时和数据的冗余传输，举例：
  • 

• 令牌桶算法，漏桶算法
• 业务分流
• 终端分流
• nginx限流
• 网关限流

• 页面降级
• 微服务降级
• 快速熔断

• 黑名单
• 验证码