微服务架构设计详解

小小Java开发者

于 2024-08-11 18:49:19 发布

阅读量89

点赞数 3

分类专栏： Spring Cloud 文章标签：微服务架构详解

本文链接：https://blog.csdn.net/weixin_43759352/article/details/141109659

版权

Spring Cloud 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

为什么要做微服务？

微服务一直是近几年的技术热点，凡是谈到架构设计，毫无疑问都离不开微服务这个话题。无论是做架构设计，还是只是做业务开发，几乎在所有的面试中，微服务设计几乎是必问的一道面试题。

另外，在我们的实际工作中，几乎百分之80的公司，微服务也都是架构演变升级的方向。那么，为什么要做微服务呢？微服务的出发点是什么呢？

单体架构达到瓶颈

业务复杂度上升，扩展困难，维护费力度上升，牵一发动全身
团队规模扩大，开发冲突增多，开发效率降低，无法兼容多种编程语言
性能受到制约，在服务可靠性、吞吐能力、服务部署等方面达到瓶颈

优化架构，更新换代

保证技术架构的鲜活度，不与主流脱轨
不断的调整技术建设，支撑内部技术发展
更好的架构体系，更有力的支撑业务需求

跟随潮流，为了微服务而微服务

为了紧跟潮流，别人搞我们也要搞
为了体验下微服务架构的魅力
为了自己实操一把，掌握微服务技术

微服务的出发点必定是为了解决架构层面遇到的问题，微服务是分而治之的思想。它通过引入更分散的架构思想，从而来解决更复杂的系统问题。

所以，微服务并不是所有系统都适用的。在考虑微服务架构的时候，我们得先评估下是否真的需要？从单体到微服务是一个复杂化的过程，如果非必要不微服务。

最近，大有微服务合并转向单体的趋势。只有我们的系统在业务复杂度层面、系统性能层面、团队开发协作层面等有了确切的需求，那么微服务确实是不二之选。

微服务到底是什么？

微服务（Microservices）是一种软件开发架构风格，它将一个复杂的应用程序构建为一系列小型服务的集合，每个服务运行在其独立的进程中，并通常围绕特定的业务能力进行构建。这些服务可以通过定义良好的API进行通信，通常是HTTP
RESTful API或轻量级的消息传递系统。

微服务的核心特点包括：

小型化和轻量级： 每个服务都相对较小，只关注特定的业务功能。
独立部署： 各个微服务可以独立部署，不需要依赖其他服务。
独立扩展： 可以根据需求独立扩展或收缩特定的服务。
技术多样性： 团队可以根据服务的特定需求选择最适合的技术栈，包括编程语言和数据存储等。
业务中心化： 每个服务都围绕一项业务能力构建，易于理解和维护。
敏捷性： 微服务架构提高了开发和部署的速度，使得快速迭代和持续交付成为可能。
容错性： 系统中某个服务的故障不会导致整个系统的崩溃，提高了系统的稳定性。
去中心化治理： 没有统一的控制中心，服务之间的调用和数据流是去中心化的。
去中心化数据管理： 每个服务可以有自己的数据库，实现数据的封装和隔离。
基础设施自动化： 自动化的部署、扩展、监控和故障恢复是微服务架构的关键。

我们到底如何进行微服务拆分？

拆分是没有完全标准的答案和方式，每家公司或者每个团队拆分的微服务方式可以说是各不相同。但拆分必然有相同的部分，有一些必然需要参考的准则和拆分方式。这些就是我们所需要掌握的，包括面试时候所需要回答出来的点。

微服务拆分原则

单一职责原则： 每个服务应该有一个清晰定义的职责，并且只负责一个特定的业务功能。
业务能力对齐： 服务应该围绕业务能力构建，确保每个服务都是一个可独立部署和扩展的业务单元。
独立性： 每个服务应该是独立的，拥有自己的代码库、数据库和部署流程。
轻量级通信： 服务之间的通信应该是轻量级的，避免使用重量级的通信协议。
数据隔离： 每个服务应该有自己的数据存储，避免服务之间的数据依赖。
去中心化治理： 允许每个服务独立选择技术栈和框架。
容错性： 服务应该能够容忍其他服务的故障，通常通过断路器模式实现。
敏捷性： 服务应该能够快速迭代和部署，以适应快速变化的业务需求。
智能端点和哑管道： 服务之间通过简单的管道通信，而业务逻辑应该封装在端点中。
API 网关： 使用API网关来提供统一的入口，处理跨服务的请求路由、负载均衡和安全控制。
持续集成和持续部署（CI/CD）： 自动化的构建和部署流程对于微服务架构至关重要。
监控和日志： 实现集中的监控和日志管理，以便于跟踪和诊断跨服务的问题。
团队自治： 每个服务的开发团队应该有足够的自治权，以快速响应业务需求。
服务发现： 实现服务发现机制，以便服务实例可以相互发现并进行通信。
断路器模式： 使用断路器模式来防止级联故障，并提高系统的稳定性。
异步消息传递： 在可能的情况下，使用异步消息传递来解耦服务。
版本控制： 为服务和API实现版本控制，以支持向后兼容性。
安全性： 确保每个服务都有适当的安全措施，包括认证和授权。
文档和API管理： 为API提供详细的文档，并管理API的变更。
避免远程调用： 尽量避免远程服务调用，优先考虑本地服务调用。
服务边界清晰： 服务之间的边界应该清晰定义，避免功能重叠。
避免共享服务： 避免创建共享服务，因为它们可能导致服务间的耦合。
可替换性： 设计服务时，应考虑到将来可能的替换或升级。
环境一致性： 确保开发、测试和生产环境尽可能一致，以减少环境差异导致的问题。
配置管理： 实现集中的配置管理，以便于跨服务的配置变更。
服务契约： 定义清晰的服务契约，包括API和数据格式。
性能和可伸缩性： 在设计服务时，考虑性能和可伸缩性需求。
避免过度拆分： 避免过度拆分服务，导致过多的服务管理和通信开销。

微服务拆分方式

1.按业务拆分

这是最常见的拆分方式，根据业务功能的不同将应用程序划分为不同的服务。每个服务对应一个特定的业务领域，例如用户管理、订单处理、库存管理等。

优点：

服务之间界限清晰，易于管理和维护。
每个服务可以独立部署和扩展。

缺点：

需要良好的业务领域分析和规划。

2.按复用度拆分

根据服务的复用程度进行拆分，将那些在多个地方被使用的通用功能（如认证、日志记录、配置管理）划分为独立的服务。

优点：

提高代码复用性。
便于统一管理和更新通用功能。

缺点：

过度拆分可能导致服务之间的依赖性增加。

3.按冷热拆分

根据服务的使用频率以及业务复杂度、需求频率，将高频率（热）服务和低频率（冷）服务分开部署。热服务可能需要更多的资源和优化、以及更频繁的服务发布。

优点：

可以根据服务的实际使用情况优化资源分配。
冷热分离有助于提高系统整体性能。
有助于保持系统稳定性。

缺点：

需要准确评估服务的使用频率。

4.按吞吐量拆分

根据服务的吞吐量需求进行拆分，将那些需要高吞吐量处理的服务单独拆分出来，以便进行专门的优化和扩展。

优点：

可以根据服务的性能需求进行资源分配和优化。
有助于确保关键服务的性能。

缺点：

需要对服务的性能特性有深入的了解。

5.按团队架构拆分

根据团队的组织结构和开发能力进行服务拆分，每个团队负责一个或多个服务的开发和维护。

优点：

提高团队的责任感和开发效率。
便于团队内部协作和知识共享。

缺点：

可能导致团队间的沟通和协调成本增加。

微服务与DDD领域驱动设计

微服务与DDD的关系

业务边界的确定： DDD通过战略设计帮助确定业务边界，这些边界可以直接映射到微服务的划分上。每个限界上下文（Bounded Context）通常对应一个微服务。
高内聚低耦合： DDD提倡高内聚的领域模型，这与微服务追求的高内聚、低耦合的服务设计原则相吻合。
持续演进： DDD鼓励通过不断的迭代来演进领域模型，这与微服务架构中服务的持续集成和持续部署（CI/CD）的理念相符。
技术与业务的对齐： DDD通过统一语言（Ubiquitous Language）促进业务专家与开发人员之间的沟通，而微服务架构则通过服务的独立性支持快速响应业务变化。
独立部署和扩展： DDD中的每个限界上下文都可以独立部署和扩展，这与微服务的独立部署和扩展原则一致。
领域事件： DDD中的领域事件可以用来触发微服务间的通信，实现服务间的松耦合 __ 。
抗腐层： 在微服务架构中，DDD的反腐层概念可以帮助维护服务间的清晰界限，确保服务的独立性和稳定性。

在实践中，DDD可以帮助团队更好地理解和建模业务领域，而微服务架构提供了实现这些模型的技术手段。通过DDD的领域模型，可以更容易地识别出微服务的职责和边界，从而设计出更灵活、可维护和可扩展的系统。

说白了，DDD诞生了20多年了，之前一直不温不火是因为DDD很难落地。但随着微服务的出现，DDD思想与微服务非常契合，2者相辅相成，DDD成为了微服务拆分的指导思想，而微服务有着完善的落地技术方案。

DDD通过聚焦业务模型，强调明确清晰的业务边界，划分出多个限界下上文，通过定义具体的实体、值对象、聚合根把业务模型分的明明白白，这不就是微服务划分业务服务最好的军师吗？

微服务与其他架构模式的区别

微服务架构与传统的单体架构、分布式架构和 Serverless __ 架构有显著的不同。以下是微服务架构与其他架构的区别：

微服务架构 vs 单体架构

单体架构：

应用程序的所有功能模块都打包在一起，作为一个单一的单元运行。
通常难以维护和更新，因为任何更改都需要重新部署整个应用。
技术栈统一，整个应用通常使用相同的编程语言和技术。

微服务架构：

应用程序被分解为一系列小型服务，每个服务运行在自己的进程中，并通常围绕特定的业务功能构建。
易于开发和维护，因为每个服务都是独立的，可以单独部署、升级和扩展。
技术多样性，不同的服务可以使用不同的编程语言和技术栈。

微服务架构 vs 分布式架构

分布式架构：

应用程序被拆分成多个模块，这些模块运行在不同的服务器上，并通过网络通信。是一个更广泛的概念，已经存在了很长时间，涉及多个计算机或节点协同工作完成复杂任务。
指的是系统的组件分布在不同的物理位置，但作为一个整体协同工作。分布式系统不一定涉及服务的拆分，它更侧重于组件之间的通信和协作。

微服务架构：

虽然微服务架构也是分布式的，但它更侧重于服务的独立性、灵活性和敏捷性。
微服务架构是分布式系统架构的一种特殊形式，它专注于更细粒度的服务拆分和独立部署

微服务架构 vs Serverless架构

Serverless架构：

在Serverless架构中，开发者不需要管理服务器，而是将代码部署到云平台上，由云平台负责运行和扩展。
通常以函数为单位，按需运行，按实际使用量计费。

微服务架构：

微服务通常长期运行，提供持续的服务，而Serverless架构中的函数是事件驱动和短暂运行的。
微服务架构可能需要更多的运维工作，因为每个服务都需要独立管理和部署。

微服务架构 vs Soa架构

微服务架构和SOA（面向服务的架构）都是设计软件系统的方法，它们在多个方面有相似之处，但也存在一些关键的区别：

服务粒度：

微服务：通常具有更细的粒度，每个服务都非常专注，以至于可能只有一个单一的职责或功能23。
SOA：服务粒度较粗，可以包含多个功能，服务组件的大小可以从小型应用程序服务到非常大型的企业服务23。

通信方式：

微服务：倾向于使用轻量级的通信机制，如HTTP RESTful API或轻量级的消息传递系统12。
SOA：可能使用更复杂的协议，如WebService BPEL（业务流程执行语言），并且常通过ESB（企业服务总线）进行服务间的通信和集成12。

架构划分方式：

微服务：强调按垂直架构划分，按照业务能力将系统拆分成独立的服务，每个服务完成一种特定的功能，服务即产品3。
SOA：更注重按水平架构划分，将系统划分为前端、后端、数据库和测试等不同的层次

微服务架构 vs Service Mesh

微服务和Service Mesh是云原生架构中的两个重要概念，它们在软件架构和部署上有不同的关注点和作用：

微服务（Microservices）：

微服务是一种架构风格，它将一个大型复杂软件应用分解为一组小型、独立的服务，每个服务运行在自己的进程中，并通常围绕特定的业务功能构建。
微服务之间通过定义良好的API进行通信，通常是HTTP RESTful API或轻量级的消息传递系统。
微服务架构的优点包括降低系统复杂度、松耦合、跨语言开发、独立部署等。

Service Mesh（服务网格）：

Service Mesh是微服务架构中的一个基础设施层，专门用于处理服务间的通信。它通过使用“sidecar”代理模式，使得服务通信的细节（如发现、负载均衡、故障恢复、度量和监控、安全性等）对应用层透明。
Service Mesh的典型实现包括Istio、Linkerd、Consul等，它们通常以轻量级代理的形式与应用服务一起部署，而不需要应用代码的更改。
Service Mesh解决了微服务架构中的一些挑战，如服务发现、配置管理、流量控制和故障处理等。

主要区别：