【架构设计】互联网架构项目架构演进以及三高设计概述

  • 系统架构并非一蹴而就,架构目标也是随着业务发展而变化,业务推送技术发展,技术反哺业务。
  • 系统架构演进:单机 -->集群 -->分布式微服务

架构演进(日活用户占总用户量大概%4到%10,推测总用户量)

(1)单体应用架构(1千UV以下)

【架构设计】互联网架构项目架构演进以及三高设计概述_第1张图片

优点:易于测试,便于集成,对小型项目友好。

缺点:启动时间长,依赖庞大,单机性能瓶颈明显,资源容易出现争夺。

(2)应用数据分离架构(5千UV)

【架构设计】互联网架构项目架构演进以及三高设计概述_第2张图片

优点:易于测试,便于集成,对小型项目友好。

缺点:启动时间长,依赖庞大,单机性能瓶颈明显,资源容易出现争夺。

(3)应用集群架构(1万UV)

【架构设计】互联网架构项目架构演进以及三高设计概述_第3张图片

优点:避免应用程序单点故障,提高应用处理能力。

缺点:链路存在单点故障-网关-数据库,单机性能瓶颈明显。

(4)应用集群缓存架构(5万UV)

【架构设计】互联网架构项目架构演进以及三高设计概述_第4张图片

优点:热点数据缓存,提高性能。

缺点:增加维护成本,包括缓存穿透/击穿/雪崩等问题。

(5)应用集群+读写分离架构(10万UV)

【架构设计】互联网架构项目架构演进以及三高设计概述_第5张图片

优点:读写分离,提高数据库性能和可用性。

缺点:增加维护成本,数据量激增单库容易瓶颈。

(6)微服务化-分库分表架构(100万UV)

【架构设计】互联网架构项目架构演进以及三高设计概述_第6张图片

优点:易开发、理解和维护独立的部署和启动,数据库性能提升。

缺点:分布式系统-分布式事务问题,管理多个微服务,服务治理问题。

(7)多元化业务-数据异构架构(500万UV)

【架构设计】互联网架构项目架构演进以及三高设计概述_第7张图片

优点:数据源多样化,业务性能提升明显,系统复用性高,支撑更高并发+海量数据。

缺点:运维复杂增高,链路分析复杂和技术广度+深度大。

常规互联网项目HTTP请求响应的全链路

【架构设计】互联网架构项目架构演进以及三高设计概述_第8张图片

三高下的架构设计概述

  • 对于技术人员的三高为:高并发、高可用、高性能

(1)什么是高并发?

  • QPS/TPS 来衡量系统的对任务的处理能力
    • TPS
      • Transactions Per Second 每秒事务数, 可以是一个接口、多个接口、一个业务流程, 包括增删改操作
    • QPS
      • Queries Per Second, 每秒查询数, 指一台服务器每秒能够响应的查询次数
      • QPS 只是一个简单查询的统计,不能描述增删改等操作
      • 如果只是查询操作 TPS = QPS

(2)什么是高可用?

  • SLA 衡量一个系统可用性有多高,目标系统 7 x 24 小时不间断服务。
  • 分类
    • 时间维度:系统可以正常使用时间与总时间之比(全年为例子)1年 = 365天 = 8760小时
      • 99.9 = 8760 * 0.1% = 8760 * 0.001 = 8.76小时
      • 99.99 = 8760 * 0.0001 = 0.876小时 = 0.876 * 60 = 52.6分钟
      • 99.999 = 8760 * 0.00001 = 0.0876小时 = 0.0876 * 60 = 5.26分钟
    • 请求次数维度:请求总次数和失败的占比 ( 1000次请求为例子,相对简单 )
      • 系统可用性99%:表示1000个请求中允许1000 * (1- 99%) = 10个请求出错
      • 系统可用性99.9%:表示1000个请求中允许1000 * (1- 99.9%) = 1个请求出错。
  • 9越多代表全年服务可用时间越长服务更可靠,停机时间越短
  • 但往往存在网络/机房问题,应用更新发版导致服务不可用
  • 大厂多数业务4个9是刚需,5个9是目标,6个9是理想

(3)什么是高性能?

  • RT来衡量系统的响应速度,程序处理速度非常快延迟低Latency,所占内存少,cpu占用率低

(4)如何做到高并发-高性能技术?

  • 系统架构

    • 无状态业务-水平扩展(Scale Out),只要增加服务器数量,就能线性扩充系统性能
    • 架构的难点是难做到全链路的水平扩展
  • 【负载均衡】思想

    • 节点轮询、随机、加权轮询、节点固定hash
      • 网络 DNS解析轮询
      • 网关分发请求后端服务
      • 应用服务内部RPC负载均衡
      • 数据存储-分库分表-负载分发
  • 【缓存】思想

    • 本地缓存/分布式缓存
      • 前端浏览器缓存静态资源
      • 网络DNS解析缓存
      • 应用程序 内存缓存/分布式缓存
      • 数据存储Mysql Query Cache
  • 【池化复用】思想

    • 线程池/对象池/连接池/内存池
      • java线程池技术
      • Jdbc/Redis/HttpClient连接池
      • SpringIOC容器对象池
  • 【异步】思想

    • 多线程/消息队列
      • 前端ajax异步请求
      • RocketMQ/Kafka 同步双写-异步刷盘
      • 应用程序多线程异步处理
  • 【预处理-惰性更新】思想

    • 定时任务/懒加载
      • 运营后台报表数据,定时任务提前计算好

      • Mybatis懒加载

  • 【分而治之】思想

    • Mater-worker
      • Hadoop中的MapReduce
      • JDK. Fork/Join Framework
      • 消息队列的广播消息
      • 归并排序算法

(4)如何做到高可用技术?

(冗余集群化 + 自动故障转移failover)

  • 集群架构

    • 将多个相同的应用程序集中起来提供同一种服务,某个节点故障不影响系统
    • 可以横向扩展性增加节点提高并发处理能力
      • 微服务集群

      • Redis集群/Kafka集群/Nginx集群

      • Nacos集群/Mysql集群/ZK集群

  • 熔断降级

    • 保险丝,熔断服务,为了防止整个系统故障,抛弃一些非核心的接口和数据,返回兜底数据
  • 限流

    • 当访问频率或者并发请求超过其承受范围的时候,考虑限流来保证接口的可用性

    • 漏斗模型,不管流量多大均匀的流入容器,令牌桶算法,漏桶算法

  • 隔离

    • 服务和资源互相隔离,比如网络资源,机器资源,线程资源等,不会因为某个服务的资源不足而抢占其他服务的资源
  • 多活架构

    • 同城双活-双机房

      • 两个机房部署在同城,物理距离较近,两个机房用「专线」网络连接,比单个机房内延迟要大一些,但整体的延迟是可以接受的
    • 参考

      • 同机房:0.1ms
      • 同城双机房:1ms(100公里内)
      • 北京到广州:55ms
  • 异地多活-两地三中心

    • 两地是指 2 个城市,三中心是指有 3 个机房,其中 2 个机房在同一个城市
    • 同时提供服务,第 3 个机房部署在异地,只做数据灾备

你可能感兴趣的:(架构设计,架构,系统架构,后端)