【Spring Cloud一】微服务基本知识
系列文章目录
微服务基本知识
- 系列文章目录
- 前言
- 一、系统架构的演变
-
- 1.1单体架构
- 1.2分层架构
- 1.3分布式架构
- 1.4微服务架构
- 1.5分布式、SOA、微服务的异同点
- 二、CAP原则
- 三、RESTful
-
- RESTful的核心概念：
- 四、共识算法
前言
在实际项目开发过程中，目前负责开发的系统整体的架构采用的是微服务架构。对于微服务架构的认识只是停留在应用层面上，对于微服务的全貌并不是很清晰。最近想要对微服务的认知上更近一步，所以就重新梳理了一下微服务的基础知识。
一、系统架构的演变
1.1单体架构
什么是单体架构：
将一个完成的应用程序作为一个单一的、整体的单元来构建和部署。所有的功能和模块都集中在一个代码库中。共享同一个数据库，相应的也部署在同一个服务器上——单体架构。
单体架构出现的原因：
早期的Java应用程序一般采用单体架构，这是因为在用用程序刚刚开始开发的时候，规模小，并且单体架构简单易于部署。
单体架构的优缺点：
优点：开发简单、易于部署、单一数据库事物
缺点：随着业务增长会面临扩展性和维护性等问题。
1.2分层架构
什么是分层架构：
分层架构将应用程序划分为多个层次（表现层、应用层、数据访问层），每个层次负责不同的功能，用于实现代码的复用和职责的分离。
分层架构出现的原因：
为了解决单体架构的扩展性和维护性问题，演变为采用分层架构。分层架构将应用程序划分为多个层次（表现层、应用层、数据访问层），每个层次负责不同的功能，用于实现代码的复用和职责的分离。
分层架构的优缺点：
优点：代码复用、职责清晰、易于维护。
缺点：复杂性（在一些复杂的业务场景下，层与层之间的交互可能变得复杂）。大型系统中可能导致模块之间的耦合。
1.3分布式架构
什么是分布式架构：
分布式架构是一种设计模式，是将大型应用拆分成多个独立的子系统或服务，并将这些子系统部署在不同的服务器上。通过网络进行通信和协作。
分布式架构出现的原因：
随着互联网的发展和业务的增长，单体架构和分层架构在面对大规模用户和高并发访问时已经不够灵活和高效。因此，Java应用程序逐渐演变为分布式架构，将应用程序拆分成多个独立的服务。
分布式架构的目标：
提高系统的高性能、可伸缩性；高可用性和容错性，来提高系统的整体性能。
分布式架构的优缺点：
优点：横向扩展、高可用性、灵活部署
缺点：系统复杂、通信开销、分布式事务难以处理。
1.4微服务架构
在说微服务架构的时候先了解一下SOA（Service-Oriented Architecture）
SOA是一种软件架构风格，核心思想是将应用程序的功能划分为一组相对独立的服务，这些服务可以通过网络进行通信，并可以按需组成更大的应用系统。
SOA的目标：
强调松耦合和服务的重用，使系统更易于可扩充、可维护、可复用。SOA可以用于实现分布式系统，但并不限定于分布式系统。
了解了SOA架构之后我们再看看微服务架构。
什么是微服务架构：
微服务架构是一种特殊的SOA风格，它将应用程序划分为一组小型、独立的服务。每个服务都专注于一个特定的业务功能。
微服务架构强调将应用程序**差分成更小的、自治的、独立部署和松耦合服务。每个服务都有自己的数据库和业务逻辑。**与SOA相比微服务架构的粒度更小。
微服务架构的优缺点：
优点：
- 模块化和解耦合：将真个系统拆分为一组小型、独立的服务。每个服务都专注于一个特定的职责。
- 独立部署和伸缩性：每个服务都是独立的，可以单独部署也可以根据需求对服务进行水平扩展。
- 更好的团队协作：每个微服务都是独立的，可以由不同的团队开发和维护，提高团队的自治性和工作效率。
- 简化持续交付：由于每个服务都是独立的，可以更轻松的持续集成和交付，减少了系统的发布风险和交付时间。
缺点：
- 系统复杂性：每个服务都是独立的，需要通过网络进行通信。增加了系统的复杂性，包括网络通信、服务发现、负载均衡等方面。
- 部署和运维复杂性：微服务架构涉及多个服务的部署和运维，需要管理大量的服务。增加了部署和运维的复杂性。
- 数据一致性和分布式事物的问题：由于微服务架构中每个服务都有自己的数据存储。可能会导致数据一致性的问题。
1.5分布式、SOA、微服务的异同点
相同点：
他们都将应用程序拆分成多个组件或服务，并通过网络进行通信和协作。
都强调松耦合、可扩展、可维护、可复用。
不同点：
1.分布式架构是一种概念上的设计模式，用于解决系统的性能和可扩展问题，强调的是分担和资源的合理利用。
2.SOA是一种软件架构风格，核心思想是将应用程序划分为一组相对独立的服务，并通过标准化的协议进行通信，以实现松耦合和服务的重用。
3.微服务架构是SOA的一种实践方式，它强调将应用程序拆分为小型、独立的服务，每个服务都有自己的数据库和业务逻辑，来实现更高的自治和独立部署、松耦合。
二、CAP原则
cap是分布式系统中三个重要的属性。
一致性（Consistency）：各个子系统看到的数据都是相同的。数据都是一致性。
可用性（Availability）：分布式系统能够在任何时刻都能对外提供服务，保持持续的可工作状态，不因故障而中断服务。当一个子系统挂掉了，整个系统可以继续对外提供服务
分区容忍性（Partition Tolerance）：
分区容忍性关注的是分布式系统在面对网络分区的情况下仍然能够正常运行，而不会因为分区而导致整个系统不可用。
由于网络或者分区等原因会导致各个子系统中的数据短暂不一致
一般来说，大多数分布式系统会优先考虑分区容忍性和可用性，因为网络分区是不可避免的，而一致性可以通过其他手段来解决
补充：zookeeper遵循CP、Eureka遵循AP
三、RESTful
RESTful（Representational State Transfer 表述性状态转移）是一种设计和构建网络应用程序的架构风格。是最初由Roy Fielding在他的博士论文中提出，并成为了HTTP协议的一种应用方式。
RESTful架构的设计目标是：使网络应用程序具有简介、可伸缩、可维护、可扩展和易于理解。
RESTful的核心概念：
- 资源（Resources）：在RESTful中，所有事物都被看做为资源，例如用户、订单，并且每个资源都有一个唯一的标识符（通常是URL）用于访问资源和操作资源。
- 无状态性：RESTful架构要求每一个请求都应该包含足够的信息，使服务器能够理解和处理，不需要依赖之前的请求或者会话状态，服务器不保存客户端的状态信息，这使得系统更具伸缩性和简洁性。
可伸缩性示例：
假设有一个电子商务网站，它使用RESTful API来处理客户端的请求。由于RESTful架构是无状态的，服务器不会保存客户端的状态信息，每个请求都包含足够的信息来执行操作。这使得该网站可以轻松地水平扩展，即通过增加服务器节点来处理更多的请求负载。
如果服务器需要保存大量的客户端状态信息，例如会话信息、购物车内容等，那么在进行水平扩展时，需要确保所有服务器节点之间的状态同步，这增加了复杂性并降低了可伸缩性。而在RESTful架构下，无状态性消除了这种状态同步的需求，使得系统的扩展更加简单和高效。
简洁性示例：
考虑一个社交媒体应用程序，使用RESTful API来处理用户发布新帖子的请求。用户在每个请求中提供了必要的信息，例如帖子内容、标签等。服务器无需维护用户的会话状态，而是根据请求的信息处理每个帖子的发布。
在这种情况下，RESTful架构简化了服务器的逻辑和状态管理。服务器无需关心用户的上下文或会话状态，只需根据请求的内容处理每个帖子。这种简洁性使得服务器的代码更易于编写、测试和维护。
- 统一接口：RESTful架构使用统一的接口规范来定义资源的操作方式。这种统一性使得不同的客户端可以通过相同的接口与服务器进行通信。
RESTful API使用标准的HTTP方法（GET、POST、PUT、DELETE等）来对资源进行操作。客户端通过不同的HTTP方法来执行不同的操作，比如获取资源、创建新资源、更新资源或删除资源。
- 按需编码：服务器可以将资源在不同的表示形式（如JSON、XML等）之间进行转换，根据客户端需求返回不同的表现形式。客户端通过HTTP头部信息来指定期望的表示形式。
符合RESTful原则的架构方式就可以称为RESTful。
四、共识算法
共识算法常常被用于集群服务中的主从模式中。
什么是共识算法：让集群中的各个节点的数据保持一致性的一种策略。
Raft共识算法