为什么要限流？

由于Web服务无法控制调用方的行为，当遇到请求并发量超过系统的容量阈值，会导致服务器资源耗尽从而导致服务异常或宕机，而且某个服务的请求量突增还会影响到上游的服务，如DB或者是其他的公共服务，导致整个系统瘫痪。 可能导致流量突增的原因有以下几点：

全局唯一ID要求

分布式系统中，我们会对一些数据量大的业务进行拆分，如用户表、订单表，当数据量巨大导致数据库性能下降时，通常会进行分库分表，无法利用MySQL的自增ID，那么就需要一个单独的系统来生成全局唯一ID，而且生成的ID要求具有以下特性：

消息队列

消息队列是分布式系统的一个重要组件，从五个问题来初步认识一下消息队列，基本原理是什么样的，如何正确的使用消息队列。

• Q1: 为什么需要消息队列？
• Q2: 如何保证消息不丢失？
• Q3: 如何处理重复消息？
• Q4: 如何保证消息有序性？
• Q5: 如何处理消息堆积？

为什么需要

异步处理

• 随着业务的增长，业务逻辑会不断加重，为了保持较快速的响应，可以在核心逻辑处理完后就返回，其他逻辑放到消息队列之后异步处理

应用解耦

• 业务模块增加，可以通过订阅核心服务的消息主题，不影响核心服务

流量控制

• 后端服务无法支撑大量的并发请求，请求先放到队列，后端服务尽最大的能力消费队列

日志处理

基本概念

模型

• 点对点（队列）模型

概念

基本定义

• 微服务就是一些协同工作的小而自治的服务

服务注册与发现

• 微服务之间互相调用，服务发现需要管理各个服务的服务器地址，当进行扩容或摘除时能及时更新

服务监控

• 监控、日志、调用链、告警通知、健康检查

服务容错

• 熔断
• 切换
• 限流和降级
• 重试

服务安全

• 敏感服务进行身份验证和授权

基础

性能

• 性能指标

  • 响应时间
  • 吞吐量（QPS、TPS）
  • 并发用户数：不是越高越好，如果系统来不及处理就会阻塞，响应时间会大大提高

• 性能优化

  • 集群
  • 缓存（Redis、CDN）
  • 异步

伸缩性

• 扩容
• 无状态的应用服务器可以通过负载均衡器想集群中添加新的节点
• 关系型数据库可以用过Sharding实现
• 非关系型数据库对伸缩性支持很好

扩展性

• 添加新的功能对现有系统的其他应用无影响
• 使用消息队列进行解耦
• 分布式服务奖业务可复用的部分模块化

可用性

• 冗余（多点备份，异地双活）
• 故障切换
• 服务降级
• 监控

安全性

• 应对各种攻击手段

软件环境

• 操作系统：Ubuntu16.04-server
• MySQL版本：5.7.25

故障一

只能通过localhost登录MySQL

1. 报错如下

$mysql -h172.16.0.1 -uroot -p123456 mysql: [Warning] Using a password on the command line interface can be insecure. ERROR 1130 (HY000): Host ‘172.16.0.1’ is not allowed to connect to this MySQL server