Zookeeper 从架构到CPA模型

系统服务架构和服务问题

单体架构

单体架构概述：单体架构（Monolithic Architecture）指的是将应用的所有功能模块打包成一个独立的可执行单元进行部署和运行的架构方式。所有的代码和功能模块都在一个项目中，整体结构简单清晰。

单体架构的优点

1. 架构简单：所有的代码和功能模块都在一个项目中，整体结构简单。
2. 开发简单：新手开发者可以更容易理解和掌握整个应用的工作原理。
3. 部署简单：将整个应用打包成一个文件，部署时只需在服务器上运行该文件即可。

单体架构的缺点

1. 代码重构难：代码库庞大且复杂，重构和维护变得困难。代码改动需要重新打包和部署整个应用。
2. 代码膨胀：所有的功能模块都在一个代码库中，代码量巨大，编译和构建时间长。不同开发人员编写的工具类可能重复，导致代码冗余。
3. 项目升级周期长：任何一个小的改动都可能需要重新打包和部署整个应用，升级和发布周期较长。代码改动需要重新打包和部署整个应用。
4. 性能瓶颈：当请求量很大时，服务器的处理能力有限，容易导致性能瓶颈，特别是数据库和应用服务器都在同一台服务器上时，资源争用严重。

扩展

1. IDC（Internet Data Center）数据中心：用于托管服务器的场所，通常有多个IDC以防单点故障。
2. 上云：利用云服务提供商（如百度、阿里、腾讯等）的服务器资源，减少自建机房的成本和维护工作。
3. 服务器的硬件配置：服务器通常只包含核心组件如CPU、内存和硬盘，显示器和键盘等外设不需要。

单体架构适用于小型项目和初期的快速开发，但随着项目的规模和复杂度增加，单体架构的缺点逐渐显现，可能需要考虑迁移到微服务架构以解决单体架构的局限性。

单体架构升级到集群与分布式架构

随着项目的发展和用户的增加，单体架构逐渐显现出其局限性，如性能瓶颈和难以扩展的问题，我们就要考虑集群架构。集群架构指多个服务器执行相同的任务，多个Tomcat实例部署相同的应用，通过负载均衡来分担请求压力。

分布式架构定义：分布式架构指多个服务器协同完成一个任务。各个服务器分工明确，执行不同的功能模块，如一个服务器处理搜索，另一个处理购物车等。

集群与分布式的区别

• 集群：多个服务器执行相同的任务，提高系统的并发处理能力。
• 分布式：多个服务器分工合作完成不同的任务，提高系统的处理效率和速度。

优缺点

• 集群架构的优点：负载均衡：请求压力分散到多个服务器，提高系统的稳定性和可用性。高可用性：某台服务器故障时，其他服务器仍能继续提供服务。
• 分布式架构的优点：任务分解：不同服务器处理不同功能模块，提高处理效率。扩展性好：可以根据需求增加或减少特定功能模块的服务器。

实施建议：初期：小型项目或用户量较少时，采用单体架构可以快速开发和部署。中期：用户量增加到几千甚至上万时，采用集群架构，通过负载均衡分担压力。后期：用户量持续增长，需求复杂时，采用分布式架构，将不同功能模块独立部署，提高系统扩展性和维护性。

通过以上分析，可以看到从单体架构升级到集群和分布式架构是为了应对用户量增加和业务复杂度提升的问题，确保系统高效、稳定地运行。

垂直架构（分布式架构）

垂直架构也称为分布式架构，是将一个**大型单体应用拆分成多个小型单体应用，每个小型应用专注于一个特定的业务领域，**如门户系统、商户系统和物流系统等。这样，每个系统可以独立开发、部署和维护。

垂直架构通过将大型单体应用拆分为多个小型应用，解决了单体架构的许多问题，如压力集中、代码不安全等。然而，这种架构也带来了新的挑战，需要开发人员具备更高的技术水平和丰富的经验。通过合理的架构设计和技术选型，可以充分发挥垂直架构的优势，提高系统的扩展性和维护性。

图片展示了将京东商城按垂直领域划分为门户系统、商户系统和物流系统，每个系统运行在不同的Tomcat服务器上，数据库也分布在不同的服务器上。

垂直架构的实现与挑战

1. 实现：

• 将单体应用按业务领域拆分为多个小型应用。
• 每个应用独立开发、部署，并选择最适合的技术栈。
• 通过API或消息队列实现系统间的通信。

1. 挑战：

• 数据一致性：需要解决跨多个数据库的数据一致性问题，如使用分布式事务。
• 系统通信：不同系统间需要高效通信，如使用REST API或消息队列。
• 技术复杂度：开发人员需要掌握更多的技术和工具，增加了学习成本。

垂直架构的优点

1. 压力分散、架构简单：每个系统只处理特定的业务，减轻单个系统的负担。同时因为是针对于单模块开发架构也可以相对简单，部署开发也都会比较简单
2. 代码安全：不同系统的代码分离，降低了代码泄露的风险。
3. 技术选型多样：不同系统可以选择最适合的技术栈，例如物流系统可以使用MongoDB来提高效率。

垂直架构的缺点

1. 对技术要求高：开发人员需要掌握更多的技术，如分布式事务、数据一致性等。
2. 数据一致性处理复杂：多个系统间的数据需要保持一致，增加了实现难度。
3. 升级和维护复杂：每个小系统都需要独立升级和维护，可能导致整体协调困难。

垂直架构中的分布式锁问题：
分布式锁是一种用来协调多个分布式系统之间并发访问共享资源的方法。它确保在多个实例并发访问某个资源时，只有一个实例能够访问该资源，从而防止数据不一致或竞争条件的发生。

微服务

到了后面为了保证代码安全和提高维护性，同时也为了保证服务的独立和高可用，我们将模块一个一个拆开独立的开发就是微服务架构，开发不算复杂但是想对整合和架构难度很高

 微服务架构生态图2.0 流程图模板_ProcessOn思维导图、流程图

架构的CAP原则和BASE理论

对于多数大型互联网应用，主机众多、部署分散，而且现在的集群规模越来越大，节点只会越来越多，所以节点故障、网络故 障是常态，因此分区容错性也就成为了一个分布式系统必然要面对的问题。

CAP 原则又称 CAP 定理，指的是在一个分布式系统中， C一致性、 A可用性、P分区容错性，三者不可得兼。 普遍认为，好的架构要相应快，要可以实现故障转移，还要可以多节点数据一致问题，不存在最好的架构只有最适合的架构，架构中三个特性只能拿到其2做不到全部兼得。

CP当你把一致性和分区容错放在第一位的时候，因为要每个节点数据保持一致当操作数据的时候要同步的时候就无法接收新的请求导致 A不能实现。 活没干完不做其他活，给手下协调好再接收

AP当你把可用性放在第一位的时候，当用户执行一个操作的时候其他节点没有及时同步，数据不一致，这个时候用户请求进来了但是其他节点没同步数据，都是错乱的 不能兼容C

CA那就不是集群，所有的数据只有我一个机器有不存在数据紊乱或者不可用的情况，坏了就是坏了，这种情况下P是不存在。

CP常用敏感系统，对数据要求比较高的金融或者政府企业单位，强制要求数据必须高度同步不允许出现脏数据，正常互联网项目就是AP架构，优先保证用户的使用交互还有最高可用性来提供自己的服务

Base 基本可用模型

BA (base)：当系统发生故障或者流量激增，牺牲部分服务保证基本功能的可用性。通过服务降级，服务熔断，服务限流来实现基本的可用性

S(soft)：软状态，可以理解少说服从多数，只要我们操作数据有一半以上的节点同步完成就允许接收新的请求，就理解为上一次的修改操作是一个有效的，核心思想就是必须集群大于二分之一的服务器完成了写入

E(Eventual conslstency) 此时还需要满足可用性，我们要避免脏数据，先让用户拿到数据然后再触发二次的当前校验，如果正常那就没问题，如果不正常那就失败然后返回错误刷新服务器状态，当访问高峰期度过之后做最后的一致性同步。

base适用于AP架构，在保证高可用性和交互的时候尽可能的实现数据同步性，最后的数据怎么做一致性校验什么的都是必须要做到的。

其他资源协助： 哈喽沃德先生

原创作者: u_16229584 转载于: https://blog.51cto.com/u_16229584/11525610