万字长文浅谈三高系统建设方法论和实践(下)-架构设计论坛-技术-SpringForAll社区

万字长文浅谈三高系统建设方法论和实践(下)

4.1.1.6 兼容

我们在对老系统,老功能进行重构迭代的时候,一定要做好兼容,否则上线后会出现重大的线上问题,公司内外有大量因为没有做好兼容性,而导致资损的情况。兼容分为:向前兼容性和向后兼容性,需要好好的区分他们,如下是他们的定义:
  • 向前兼容性:向前兼容性指的是旧版本的软件或硬件能够与将来推出的新版本兼容的特性,简而言之旧版本软件或系统兼容新的数据和流量。

  • 向后兼容性:向后兼容性则是指新版本的软件或硬件能够与之前版本的系统或组件兼容的特性,简而言之新版本软件或系统兼容老的数据和流量。
根据新老系统和新老数据我们可以将系统划分为四个象限:第一象限:新系统和新数据是我们系统改造上线后的状态,第三象限:老系统和老数据是我们系统改造上线前的状态,第一象限和第三象限的问题我们在研发和测试阶段一般都能发现排除掉,线上故障的高发期往往出现在第二和第四象限,第二象限是因为没有做好向前兼容性,例如上线过程中,发现问题进行了代码回滚,但是在上线过程中产生了新数据,回滚后的老系统不能处理上线过程中新产生的数据,导致线上故障。第四象限是因为没有做好向后兼容性,上线后新系统影响了老流程。针对第二象限的问题,我们可以构造新的数据去验证老的系统,针对第四象限的问题,我们可以通过流量的录制回放解决,录制线上的老流量,对新功能进行验证。

eb4831021c20240929100521

4.1.2 存储层

存储层主要通过复制和分片来保证存储层的高可用,复制主要是通过副本(主从节点,主从副本)来保证高可用,分片是将数据分散到不同的节点上来保证高可用(鸡蛋不要放在同一个篮子中)。复制和分片在保证高可用的情况下,其实也提高了系统的高性能和高并发,复制和分片的思想在Mysql,Redis,ElasticSearch, kafka中都进行了采用。

4.1.2.1 复制

复制技术是一份数据的完整的拷贝,思想是通过冗余保证高可用。复制又可以分为:主从复制,多主复制,无主复制。
  • 主从复制:客户端将所有写入操作发送到单个节点(主库),该节点将数据更改事件流发送到其他副本(从库)。读取可以在任何副本上执行,但从库的读取结果可能是陈旧的。

  • 多主复制:客户端将每个写入发送到几个主库节点之一,其中任何一个主库都可以接受写入。主库将数据更改事件流发送给彼此以及任何从库节点。

  • 无主复制:客户端将每个写入发送到几个节点,并从多个节点并行读取,以检测和纠正具有陈旧数据的节点。

4.1.2.2 分区

分区也称为分片,对于非常大的数据集在单节点进行存储时,一方面可用性比较低(鸡蛋放在同一个篮子中),另一方面也会遇到存储和性能的瓶颈,我们需要将大的数据集通过负载均衡分片到不同的节点上,每条数据(每条记录,每行或每个文档)属于且仅属于一个分区,每个分区都是自己的小型数据库。分区我们分为键范围分区,散列分区。
键范围分区:其中键是有序的,并且分区拥有从某个最小值到某个最大值的所有键。排序的优势在于可以进行有效的范围查询,但是如果应用程序经常访问相邻的键,则存在热点的风险。在这种方法中,当分区变得太大时,通常将分区分成两个子分区来动态地重新平衡分区。
散列分区:散列函数应用于每个键,分区拥有一定范围的散列。这种方法破坏了键的排序,使得范围查询效率低下,但可以更均匀地分配负载。通过散列进行分区时,通常先提前创建固定数量的分区,为每个节点分配多个分区,并在添加或删除节点时将整个分区从一个节点移动到另一个节点。也可以使用动态分区。

4.1.2.3 Redis 的复制和分片

redis cluster集群中,我们会划分16384个槽,key 通过散列哈希算法会映射到相应的槽中,这些槽分配到不同的分片上,每个分片有主节点和从节点,主节点对外提供读写服务,从节点对外提供读服务。当某个分片的主节点挂掉,其他分片的主节点会从挂掉分片的从节点选择一个作为主节点继续对外提供服务。整体的架构如下图所示。

8275ed934220240929101159

4.1.2.4 ES索引的复制和分片

我们在创建ES索引时,会指定分片的数量和副本的数量,分片的数量确定后是不允许修改的,副本的数量允许修改,分片的数量一般和数据节点的数量保持一致,这样能将索引的数据分配到每个数据节点上,每个数据节点都存储索引的部分数据,Primary分片可以对外提供读写服务,Replica分片对外提供读服务的同时作为备份节点保证可用性,ES索引的不同分片在不同数据节点的分布如下图所示。

1afddf069420240929101240

4.1.2.5 Kafka topic的复制和分区

kafka的topic为了提高可用性及高吞吐,引入了topic的分区,每个分区为了提高可用性,分区分为Leader partition 和 Follower partition,Leader partition对外提供读写服务,Follower partition作为灾备提高可用性,整体的架构如下图。

0b73e73a4320240929101304

 

4.1.3 部署层

4.1.3.1 业界部署架构的演进

部署层是通过不断突破单机器,单机房,单地域,做到机器级别,机房级别,地域级别的容灾来保证系统的高可用。核心思想是通过冗余以及负载均衡进行容灾保证高可用。

b462a2c45520240929101334

4.1.3.2 我们部署架构现状

目前我们的应用都是采用多机房多分组Docker容器化部署,会根据业务方的重要程度及流量大小设置不同的别名,隔离到不同的分组中对外提供服务。
  • 应用容器机房为:中云信,有孚,廊坊,宿迁等;

  • 数据库Mysql双机房部署:中云信,有孚;

  • 缓存Redis双机房部署:中云信,有孚;

  • ES单机房部署:有孚。

9784fa8d2f20240929101857

总结

软件的发展历程就像一场与复杂性对抗的持久战,这场战争主要围绕着两个主要的战场:技术复杂性和业务复杂性。在这篇文章中,我从后端研发的视角出发,深入探讨多年来来我在B\C端系统建设方面的宝贵经验和实践,特别关注那些需要同时应对高性能、高并发和高可用性的系统设计和优化策略,希望和大家多多交流,相互探讨。

来源https://mp.weixin.qq.com/s/KexjVJOsGYN50MxqzVT3mA

请登录后发表评论

    没有回复内容