后端架构 | 架构知识浅谈

Simple evolution

• 第一次分离的时候，应用程序、数据库、文件系统分别部署在不同的服务器上

• 使用缓存改善性能，通过缓存读取数据。缓存主要有分布式缓存和本地缓存两种。分布式缓存将多台服务器共同构成一个集群，存储更多的缓存数据

• 因为连接大量的并发用户的访问，通过负载均衡服务器，将应用服务器部署为一个集群

• 数据库的读写分离

• 大多数的互联网应用而言，以上的分布式架构就已经可以满足用户的并发访问压力了

• 更上一层还需要解决：

  • 【海量数据的存储与查询】，主要通过分布式数据库、分布式文件系统、NoSQL 数据库解决

  • 【网络带宽压力以及访问延迟】？部署独立的搜索引擎提供查询服务。同时减少数据中心的网络带宽压力，提供更好的用户访问延时、使用 CDN 和反向代理提供前置缓存

  • 【实现系统的低耦合与模块化开发和部署】为了使各个子系统更灵活易于扩展，使用分布式消息队列将相关子系统解耦，通过消息的发布订阅完成子系统间的协作、使用微服务架构将逻辑上独立的模块在物理上也独立部署，单独维护，应用系统通过组合多个微服务完成自己的业务逻辑，实现模块更高级别的复用从而更快速地开发系统和维护系统

Cache

减少 CPU 的计算消耗，节省计算资源
​通读缓存（read-through）旁路缓存（cache-aside）区别在于缓存是否负责帮应用程序从数据源读取数据

• 通读缓存（read-through）

  如果没有，通读缓存就自己负责访问数据源，从数据源获取数据返回给应用程序，并将这个数据缓存在自己的缓存中，通常会作为系统架构的一部分，很多时候对应用程序是透明的

  • CDN
    静态内容和动态内容部署在不同的服务器集群上，使用不同的二级域名，即所谓的动静分离

  • 反向代理缓存

    • 设计HTTP代理缓存

• 旁路缓存（cache-aside）

  如果没有，就返回空（null）

  • • 本地缓存，使用和应用程序在同一个进程的堆空间存放缓存数据

    • 分布式缓存

      （每个程序需要依赖一个Memcached 的客户端 SDK）

      • 应用程序调用 API，API 调用 SDK 的路由算法，路由算法根据缓存的 key 值，计算这个key对应的内容的服务器 IP 地址和端口号，API 再调用 SDK 的通信模块，将 <key, value> 值以及缓存操作命令发送给具体的某台服务器

• 解决数据脏读问题

  • 过期失效（使用更多）

  • 路由hash算法遇到增加服务器时候，会造成大量缓存不命中，可以用一致性哈希算法解决？？？

Asynchronous architecture（Event driven architecture）

• 痛点：如何提高系统的写操作的性能呢？两个应用系统之间需要互相调用，其实把两个应用耦合起来了，被调用的应用产生了故障或者升级，都可能会引起调用者故障，或者也不得不升级！

• 消息队列的职责就是缓冲消息，等待消费者消费（在2个相互调用的服务之间增加一个队列）。根据消息消费方式又分为点对点模式和发布订阅模式两种。

  • 点对点模式（保证服务的）

    • 消费者程序可以部署在多台服务器上，但是对于任何一个消息，只会被发送给其中的一个消费者服务器。

    • 这些服务器可以根据消息的数量动态伸缩，保证邮件能及时发送。

    • 如果有某台消费者服务器宕机，既不会影响其他消费者处理消息发送邮件，也不会影响生产者程序正常运行

  • 发布订阅模式

    • 在消息队列中设置主题，多个消息消费者可以订阅同一个主题，每个消费者都可以收到这个主题的消息拷贝

    • 与点对点区别：消息生产者不需要自行构造不同的业务消息到对应的mq中，只需要把普通数据加入到mq的某个主题，订阅该主题的不同消费者根据自己的业务消费该数据
      eg 新用户注册的时候一方面需要发送激活邮件，另一方面可能还需要发送欢迎短信，还可能需要将用户信息同步给关联产品或数据库

• 该架构好处：

  • 改善写操作请求的响应时间

  • 更容易进行伸缩

    • 负载均衡实现集群伸缩，但是这种集群伸缩是以整个应用服务器为单位的，但如果只是某些功能（例如图像处理）有压力，使用mq单独针对图片处理的消费者集群进行伸缩
  • • 消费者可以控制消费速度，降低系统访问高峰时压力，在访问低谷时继续消费消息队列中未处理的消息，保持系统的资源利用率
  • • 消费者如果在处理消息的过程中失败，不会传递给生产者

  • 耦合会使软件僵硬、笨拙、难以维护

    • 代码的依赖

    • 返回调用结果的依赖
      如果调用出现异常，应用程序必须要处理这个异常

Data storage architecture

• 改善数据存储能力的主要手段包括：数据库主从复制、数据库分片、业务分库和NoSQL 数据库

• 主从复制（提高可用性，无法提升存储能力）

  • 一主多从
    有的从数据库用来做实时数据分析，有的从数据库用来做批任务报表计算，有的单纯做数据备份

  • 两台服务器互相备份，仅仅用来提升数据写操作的可用性，并不能用来提高写操作的性能

    • 所有的应用程序都必须连接到同一个主数据库进行写操作，只有当该数据库宕机失效的时候，才会将写操作切换到另一台主数据库上。

• 业务分库（提高存储能力）

  • 将不同业务相关的数据库表，部署在不同的服务器上，每一类数据库还可以继续选择使用主从复制，或者主主复制

• 数据库分片（提高存储能力）

  • 硬编码方式分片（根据数据ID映射成服务器编号），缺点是增加节点数，逻辑要修改

  • 分布式关系数据库中间件分片（例如MYCAT）–类似查表法

    • MYCAT 就可以解析出 SQL 中的地区字段 prov（根据地区进行数据分片），根据这个字段连接相对应的数据库

  • 余数 Hash 算法分片（更常见，分布均匀）

    • 根据主键 ID 和服务器的数目进行取模计算，根据余数连接相对应的服务器

  • 一致性hash算法

• NoSQL 数据库（Key、Value 的方式进行数据访问）

  常用的 NoSQL 数据有 Apache HBase，Apache Cassandra、Redis， 与RDMS主要区别可用RDMS的ACID和NoSQL的BASE概括

  • CAP 原理

  一个提供数据服务的分布式系统无法同时满足数据一致性（Consistency）、可用性（Availability）和分区耐受性（Partition Tolerance）这三个条件。

  • 一个分布式系统而言，网络失效一定会发生，也就是说，分区耐受性（P）是必须要保证的，而对于互联网应用来说，可用性也是需要保证的，分布式存储系统通常需要在一致性上做一些妥协和增强

  • Apache Cassandra 解决数据一致性的方案是，在用户写入数据的时候，将一个数据写入集群中的三个服务器节点，等待至少两个节点响应写入成功。用户读取数据的时候，从三个节点尝试读取数据，至少等到两个节点返回数据，并根据返回数据的时间戳，选取最新版本的数据。这样，即使服务器中的数据不一致，但是最终用户还是能得到一个一致的数据，这种方案也被称为最终一致性。

Micro service

• 单体架构缺点之一：一个巨型的应用必须把应用部署到大规模的服务器集群上。然后每个应用都需要与数据库建立连接，大量的应用服务器连接到数据库，会对数据库的连接产生巨大的压力，某些情况下甚至会耗尽数据库的连接

• 实施微服务最重要的是做好业务的模块化设计，如果业务关系没梳理好，模块设计不清晰，使用微服务架构很可能得不偿失，带来各种挫折

• 中台：-企业级能力复用平台