互联网架构下的技术体现

高可用设计手段

单点故障

负载均衡技术

• 硬件负载、F5、Netscalar

• 软件负载、apach、nginx、lvs、Haproxy

  一个负载均衡服务器连接多台tomcat服务器

• F5、stantBy。心跳线

• nginx，lvs+keepalived（VRRP）-> VIP路由，一主多从。master【工作状态】/backup【候选者，选举】（心跳机制）

• DNS轮询

负载均衡算法：随机、hash、轮询、最小连接数...

应用层负载

• Ribbon、Gateway

热备

zookeeper/readis-sentinel/etct/redisCluster

Zab(paxos)/Raft/Raft/gossip 算法。

多机房部署

同城、异地

• 跨机房状态同步

应用的可用性

微服务的集群部署

容错性

fail fast

服务隔离

代码容错处理

接口的设计

• 数据的严谨性，数据的校验
• 幂等性，事务处理（添加数据）
• 重试（衰减重试、重试次数）。5s->10s->30s->1min->2min->5min

自我保护能力

熔断、限流、缓存

熔断：调用方法出现异常/出现多次异常—进行熔断，后续请求直接失败。

限流：限制TPS，拒绝超量的请求

缓存：减少数据库层面的压力

降级：高并发情况下，关掉不是核心的功能。提高核心功能的稳定性

监控

• 系统资源（CPU、内存、磁盘），预警
• 应用层面的分析：
  • 日志框架（系统执行情况，日志分析框架ELK…）。多系统情况下，错误码设计，不同系统设计不同的错误码，确保能够通过日志快速定位问题。
• 告警
  • 告警方式：邮件（hitfix）、短信、电话通知 | AlertManager
  • 根据不同故障级别设置告警方式
  • 可以设置阈值，错误过多时/负载过高，进行告警。
• 开源监控平台
  • 应用监控：应用吞吐量、访问量（应用中埋点、数据上报）| cat| 链路监控（A-B-C-D）跟踪链路，zipkin/sleum|pinpoint
  • 系统资源监控：metrics/InfuxDB/Grafana | promethues等

高并发设计

单位时间内能够同时处理的请求数量

RT：Response Time 响应时间

Throughput：吞吐量

QPS(TPS)：每秒响应请求数，并发数/平均响应时间

并发数（用户）

用户体验

响应时间

瀑布流加载设计

支付->第三方。对接多个支付渠道-支付路由（限额、分流…）

异步化

架构层面

• 微服务（服务拆分）
  • 减少单体架构带来的耦合度高问题。
  • 同时解决了应用的性能瓶颈问题，扩大应用计算资源。
  • 可以针对核心服务提供更大规模的集群
• 关系型数据库
  • 数据分片（分库分表）
  • 读写分离
  • 扩容（水平、垂直）
• 存储（非结构化存储）
  • redis
  • mongoDB
• 服务的无状态化设计
  • 堆机器提升性能的方式，横向扩展
  • 以session为例，可以使用JWT将用户信息放在客户端存储，减小服务器压力，同时服务器扩展性提高
• 分布式缓存
  • 热点数据做缓存
  • 抗高并发
• 容量规划
  • 什么时候应该加机器
  • 当前吞吐量是多少
  • 承载多少容量？需要增加多少机器？
  • 最大的负载状态（CPU使用率、内存使用率、磁盘IO延时…）
  • 最大能够接受的请求阈值（qps、tps、ATR、错误率…）

异步化架构

最终一致性

异步队列

实时性要求不是很高的场景

冗余

增加副本

代码层面

• 不要再for循环中调用rpc
• HashMap，比如需要数量为十万级别。初始化容量为16，那么HashMap在运行中会频繁扩容，带来服务器开销压力
• 数据的预热。将热数据保存到非结构化数据库中，提前加载，不走数据库。
• 数据库层面，查询语句的优化
• 异步化（线程池）
• 内存的使用

中间件层面的优化

• 中间件的扩容配置
• NIO/AIO

客户端层面的优化

• 减少请求数量（合并请求）

• 数据缓存

  …

存储层面

提升硬件

磁盘读写方式、缓存

服务的幂等性

多次请求对于数据的变化和一次请求带来的数据变化保持一致

• get操作天然幂等

同一个用户的请求被发起多次（MQ重试）。数据的影响只产生一次，基于服务调用者的重试。可以使用redis来保存请求信息，如果此请求已经进来过，不进行处理

锁

单线程锁

• sychronized、Lock
• 跨进程访问

分布式锁

• Zookeeper（CP）
• etcd（CP）
• 数据库
• redis（AP）

【无锁化设计】 -->结合场景考虑，尽可能不适用锁，使用锁会占用资源消耗性能

CAP：一致性、可用性、分区容错性

CAP-> CP强一致性

redis为AP模型不是强一致性