分布式以及cap理论

最新推荐文章于 2024-09-13 21:40:38 发布

风都404

最新推荐文章于 2024-09-13 21:40:38 发布

阅读量65

点赞数

文章标签： java

本文链接：https://blog.csdn.net/2302_79412927/article/details/133255297

版权

分布式:

设计思想:将任务和数据分散存储和处理在许多计算机节点上，以实现更高的性能、可靠性和可扩展性

分布式是指将任务和数据分散在多个计算机节点上进行处理和存储的一种计算机系统设计和架构方式。在传统的集中式系统中，所有的任务和数据都集中在一个中心节点上进行处理。而在分布式系统中，任务和数据被分割成多个部分，并分散在多个计算机节点上。

分布式系统中的各个节点通过网络互联，彼此之间可以进行通信和协作。每个节点相对独立，可以同时进行任务的处理和数据的存储，而不会依赖于其他节点的状态。分布式系统可以充分利用多台计算机的处理能力和存储资源，从而提高系统的性能和可靠性。

分布式系统的设计需要考虑节点间的通信机制、任务的划分和调度、数据的分布和传输、一致性的保证、故障的处理等方面的问题。同时，分布式系统也面临一些挑战，比如网络延迟、数据一致性、容错性等。

分布式系统具有以下的优点和缺点：

优点：

高性能：分布式系统可以利用多个计算机节点的处理能力，实现并行处理，从而提高系统的整体性能和吞吐量。
可扩展性：分布式系统可以根据需要增加或减少计算机节点，实现系统的动态扩展，以适应不断变化的负载需求。
高可靠性：分布式系统具有冗余和容错性，即使某个节点发生故障，系统仍然能够正常工作。节点的故障不会导致整个系统的崩溃。
分布式存储：分布式系统可以将数据分散存储在多个节点上，提高数据的冗余度和可靠性。同时，分布式存储可以支持大规模数据的存储和处理。
灵活性：分布式系统可以灵活地配置各个节点的功能和角色，可以根据具体的需求定制不同的节点。

缺点：

复杂性：分布式系统的设计、实现和维护较为复杂，需要考虑分布式通信、节点间的一致性、任务的调度等问题，增加了系统的复杂性和难度。
开销：分布式系统需要额外的资源和开销来维护节点之间的通信和协调，比如网络带宽、通信协议等方面的开销。
一致性问题：在分布式系统中，由于节点之间的延迟和故障可能导致数据的不一致性，需要采取一致性协议和机制来保证数据的一致性。
调试和故障排查：在分布式系统中，故障排查和调试比较困难，需要对多个节点进行监控和调试，增加了故障排查的难度和成本。

分布式就是把就把一个项目按照功能分为各个小项目他们直接可以互相联系

这样有利于后期升级，维护

缺点是架构复杂

分布式架构：松耦合，扩展性好，但架构复杂，难度大。

微服务:

实际上是一种架构风格(设计思想)

微服务（Microservices）是一种架构风格，用于构建应用程序的独立可部署的小型服务。在微服务架构中，一个复杂的应用程序被拆分成一组小型的、独立的服务，每个服务都围绕着特定的业务功能构建。

每个微服务都运行在自己的进程中，并使用独立的数据存储，可以通过轻量级的通信机制进行相互通信。通常，这种通信机制是基于HTTP的RESTful API，也可以使用其他的通信协议如消息队列等。

微服务的设计原则包括：

单一责任原则：每个微服务应该专注于解决一个明确定义的业务功能。
松耦合：微服务之间应该松散耦合，解除了对其他服务的依赖，可以独立地开发、测试、部署和扩展。
独立部署：每个微服务都可以独立地部署，在需要时进行水平扩展，而不会影响其他服务的正常运行。
自包含性：每个微服务应该包含自己所需的所有组件，包括数据存储、UI、业务逻辑等。
基础设施自动化：微服务架构通常依赖于自动化的基础设施，如自动化部署、监控、日志记录等。

核心原理和理念详解：

单一职责原则（Single Responsibility Principle）：每个微服务应该专注于解决一个明确的业务需求。这意味着每个微服务应该只关注一个特定的业务功能，而不是试图承担过多的责任。
松耦合（Loose Coupling）：微服务之间应该是松散耦合的，它们应该通过明确定义的接口进行通信，并且不应该依赖于彼此的内部实现细节。这样，一个微服务的变化不会对其他微服务造成影响，实现了独立的开发、扩展和部署。
独立部署（Independent Deployment）：每个微服务都可以独立地进行部署。这意味着当一个微服务需要进行更改、升级或扩展时，只需要对该微服务进行部署，而不会影响其他微服务。
自包含性（Self-Contained）：每个微服务应该包含自己所需的所有组件，包括数据库、存储、业务逻辑等。这种自包含性使得微服务可以独立地进行运行和管理。
基础设施自动化（Infrastructure Automation）：微服务架构通常依赖于自动化的基础设施，例如自动化的部署、监控和扩展。这些自动化流程可以减少人力成本，提高系统的可靠性和可维护性。

微服务架构有以下优点：

独立开发和部署：微服务允许不同团队独立地开发和部署各自的微服务。团队可以专注于特定的业务功能，而不需要等待其他团队的完成。这提高了开发效率和部署灵活性。
可扩展性和弹性：由于每个微服务是独立部署的，因此可以根据需要对特定的微服务进行水平扩展，而不会影响整个系统。这使得微服务架构在处理高并发和大规模负载时更为灵活和可靠。
技术多样性：微服务架构允许每个微服务使用最适合的技术栈和工具。不同的团队可以选择适合其需求和专长的编程语言、框架和数据库。这种技术多样性提供了更大的灵活性和创新空间。
高可用性和容错性：由于微服务架构中的每个微服务都是独立运行的，如果一个微服务发生故障，不会影响整个系统的其他部分。这种解耦和容错性可以提高系统的可用性和容错性。

缺点：

分布式系统的复杂性：微服务架构涉及到多个独立运行的微服务，需要管理分布式系统的复杂性，例如服务发现、负载均衡、故障处理等。这增加了系统的复杂性和运维难度。
服务间通信开销：微服务之间的通信是通过网络进行的，这会增加一定的网络开销和延迟。需要有效地设计和管理服务间的通信，以避免性能瓶颈和延迟问题。
数据一致性：由于微服务之间可能有各自的数据存储，确保数据的一致性和同步变得更加复杂。需要采用适当的策略和机制来处理数据一致性，例如事件驱动架构、分布式事务等。
系统复杂性：微服务架构会带来更多的组件和服务，增加了系统整体的复杂性。需要仔细设计和管理每个微服务，确保系统的可维护性和稳定性

1、CAP理论的区别

CAP理论：C一致性，A高可用，P分区容错性。eureka只支持AP，nacos支持CP和AP两种。

nacos是根据配置识别CP或AP模式,如果注册Nacos的client节点注册时是ephemeral=true即为临时节点,那么Naocs集群对这个client节点效果就是AP,反之则是CP,即不是临时节点

#false为永久实例，true表示临时实例开启，注册为临时实例

ap 是保证数据可用性

cp 则是保证数据一致性

Nacos和Eureka都是常用的服务注册与发现框架，用于在分布式系统中管理和发现服务实例。它们的一些主要区别如下：

语言支持：
- Nacos支持多种语言，包括Java、Go、Python等，因此可以与不同编程语言开发的服务进行集成。
- Eureka主要使用Java开发，对于非Java语言的支持相对较弱。
功能特性：
- Nacos提供了更多的功能特性，包括服务注册与发现、动态配置管理、服务健康监测、动态DNS等。
- Eureka主要关注服务的注册与发现，提供了基本的服务注册与心跳机制，功能相对较简单。
高可用性：
- Nacos通过支持集群部署和数据持久化等方式，提供更好的高可用性支持。
- Eureka的高可用性需要依赖额外的组件，如Eureka Server的集群部署或者与ZooKeeper等外部注册中心的结合。
社区活跃度：
- Nacos是由阿里巴巴开源的，并且拥有活跃的社区支持，不断更新迭代。
- Eureka在Netflix的开源项目中使用较广，但在近年来社区维护逐渐降低，更新较为缓慢。

总的来说，Nacos提供了更丰富的功能特性和多语言支持，具备更好的高可用性，而Eureka则更简单直接，适用于一些简单的服务注册与发现需求。

服务类型

Web服务：基于HTTP协议的网络服务，通过Web API提供数据和服务。可以根据具体的需求，使用RESTful风格的Web服务（如基于REST API的服务）或者SOAP（Simple Object Access Protocol）风格的Web服务。
微服务：将应用程序拆分成小而自治的服务，每个服务专注于特定的业务功能。微服务架构使得应用程序更容易扩展、部署和维护。
数据库服务：提供数据库相关的服务，包括数据库的CRUD（创建、读取、更新、删除）操作、查询服务、数据存储和访问控制等。
文件存储服务：提供文件上传、下载、存储和管理等功能，常见的文件存储服务包括云存储服务（如Amazon S3、Google Cloud Storage）和基于文件系统的服务。
消息队列服务：提供异步通信和消息传递机制，用于解耦和缓解系统间的通信压力。常见的消息队列服务包括RabbitMQ、Apache Kafka等。
认证和授权服务：提供用户身份验证、权限管理和访问控制等功能，用于保护应用程序和数据的安全性。
缓存服务：提供缓存数据的存储和访问，以加速数据的读取和响应时间，常见的缓存服务包括Redis、Memcached等。