06-微服务架构之微服务设计指导书

发布时间:2023年12月18日


前言

经过前面的学习,我们对每个微服务的架构有了深入的了解。接下来,我们来重点讨论如何进行每个微服务的设计,以便提高系统的可维护性、可扩展性和可靠性。


一、微服务常规的设计原则

微服务常规的设计原则包括以下几点:

  1. 单一职责原则(SRP):每个微服务应该只负责一件事情,即具有单一的职责。这有助于避免微服务之间的耦合。
  2. 隔离性原则(ISOLATION):微服务应该被设计为独立的进程,具有自己的数据库和其他资源。这可以确保一个服务的故障不会影响其他服务的正常运行。
  3. 可伸缩性原则(SCALABILITY):微服务应该能够在需要时水平扩展,以满足高负载和流量的需求。这意味着微服务应该被设计为可重复部署的、自治的服务单元。
  4. 可替换性原则(REPLACEABILITY):微服务应该被设计为可替换的。这意味着当一个服务不再满足需求时,应该能够轻松地将其替换为一个新的服务。
  5. 可重用性原则(REUSABILITY):微服务应该被设计为可重用的,这样其他服务或系统可以通过API访问它们。这有助于避免重复的代码和功能。
  6. 容错性原则(FAULT TOLERANCE):微服务应该被设计为容错的,以便在系统的某个部分失败时,整个系统可以继续正常运行。这意味着微服务应该有备用的服务或机制来处理故障。
  7. 服务自治性原则(AUTONOMY):每个微服务都应该是自治的,即它应该包含其自己的数据和业务逻辑,而不依赖于其他服务。
  8. 开放/封闭原则(OCP):微服务应该对扩展开放,对修改封闭。这意味着在需要添加新功能时,应该通过添加新服务来实现,而不是修改现有的服务。
  9. 微服务独立性原则(SIP):每个微服务应该是独立的,既不应该共享数据库或其他资源。相反,它们应该通过定义接口来进行通信。

这些原则为设计微服务提供了指导方针,以确保系统的灵活性、可扩展性和可维护性。

二、微服务的设计步骤

在《03-微服务架构构建之微服务拆分》这篇文章中已经介绍过领域驱动设计,其实不仅是在拆分阶段,在设计阶段领域驱动设计与微服务设计也是密切相关的。下面我们将使用领域驱动的设计方法来介绍为微服务的设计步骤。

再次看下领域驱动的概念
领域驱动设计(Domain Driven Design,简称DDD)是一种软件设计方法论,旨在解决复杂领域模型和软件设计之间的难题。DDD关注的是领域专家和程序员之间的交互,将领域模型放在设计的中心,并强调领域模型与实现代码的一致性。DDD也提倡使用通用语言来描述领域模型,以便于领域专家与开发人员之间的交流与理解。DDD的目标是创建出一个有意义、可理解、可维护和可扩展的软件系统,使得领域模型能够被清晰地表达,并且易于实现和维护。

通过项目经验,总结起来,微服务的设计法步骤可以分为以下内容:

1、确定服务边界,划分领域模型

确定应用程序的不同功能模块,将其分解为小型、自治的服务。这个服务边界,也就是边界上下文。

边界上下文(Bounded Context)是领域驱动设计(DDD)中一个非常重要的概念,它指的是一个特定的领域模型上下文,它包含了相互关联的概念、实体和过程。一个Bounded Context通常会包含一组特定的业务功能,它在设计时需要考虑领域内部的语言、规则和业务需求,同时也需要考虑与其他Bounded Context的交互。
Bounded Context是一个自包含的、彼此独立的领域模型,每个Bounded Context都有自己的语言规则和上下文,而这些上下文可以随着业务规模、复杂度的增加而不断演化和变化。每个Bounded Context都需要有一个明确的边界,用于将其与其他Bounded Context区分开来,这样可以减少不必要的耦合和复杂度。
在实际应用中,当多个Bounded Context之间需要互相交互时,可以通过定义明确的接口和协议来实现。这样可以保证每个Bounded Context都可以独立开发、测试和部署,同时也能保证整个系统的可扩展性和可维护性。因此,通过Bounded Context的设计,可以帮助开发团队更好地理解业务需求,减少沟通和协调的成本,提高开发效率。

这一步也是微服务设计中最为重要的一步。

首先,我们需要定义每个领域模型的边界上下文,明确其承担的业务职责和范围。通过确定边界上下文,可以确保各个领域模型之间的界限清晰,减少模型之间的依赖和耦合度,提高系统的灵活性和可维护性。

同时,我们需要识别不同的业务领域,并将其分解为多个具有内聚性和高度关联性的领域模型。这一步尤为重要的一点是需要业务专家参与。否则很难将业务需求,划分到合适的领域中。并且要和组织架构相匹配,否则会影响系统的开发和维护。

在这一步中,需要业务专家和技术团队进行合作,进行充分的讨论。在此过程中,我们需要深入了解业务需求和业务流程,了解不同领域模型之间的关系和影响,最终确定划分领域的方案并明确各个边界上下文的职责和范围。

常见问题:
1、领域划分不合理,导致微服务之间的职责和功能重叠或冲突。
2、过度拆分微服务,导致系统过于复杂,难以维护和管理。

2、设计数据模型

为每个微服务设计合适的数据模型,包括数据库架构、实体关系等。确保数据模型与业务需求和目标保持一致,并考虑数据的一致性、冗余和性能等因素。

在实际业务中,仅可能尽量避免数据库表的公用。但也会存在无法处理的情况,表冗余或者字段冗余也是可以接受的方案。但在使用冗余的过程中,就必须要考虑数据之间的同步。

常见问题:
1、数据模型设计不合理,导致数据一致性问题或性能瓶颈。
2、微服务之间的数据冗余和重复,增加了数据维护的成本和复杂性。

3、定义服务接口,确定通信机制

为每个服务定义清晰的接口,确保它们可以轻松地相互协作。在API设计过程中可以参考《RESTful设计规范》。同时,确定服务之间的通信方式,例如同步、异步或者消息队列等。

常见问题:
微服务之间的通信耦合度过高,导致系统的可扩展性和灵活性下降。这与领域划分也存在一定的关系。

4、服务的可用性和可伸缩性

在设计服务时,要考虑服务的可用性和可伸缩性,并确保服务可以水平扩展。尤其是需要注意容错设计。当微服务出现问题时,以便快速恢复。可以通过实现断路器、超时设置、重试机制等来实现。

5、其他需要考虑的因素

  1. 考虑服务的安全性:确保服务之间的通信是安全的,并且可以处理身份验证、授权和数据保护等安全问题。
  2. 考虑服务的监控和日志记录:确保每个服务都具有适当的监控和日志记录机制,以便可以跟踪和解决问题。
  3. 进行适当的测试和验证:对每个服务进行适当的测试和验证,以确保它们符合要求,并能够正常运行和相互协作。

这一步中,其实很多已经成熟的工具已经解决了这些问题,比如Spring Cloud Alibaba分布式解决方案。已经具备了从服务发现,到服务的跟踪和监控,以及收集日志等全面的管理。
再补充说明下监控和日志的重要性。实现全面的监控和日志记录机制,可以及时发现和解决问题。选择合适的监控工具和技术栈进行集成和使用。对监控数据和日志进行定期的分析和总结,以便优化系统的性能和可用性,防患于未然。建立应急响应机制,以便在出现问题时能够及时响应和处理。

至此,通过以上步骤,就可以完成微服务的设计工作。这些步骤为微服务的设计提供了指导方针,以确保系统的灵活性、可扩展性和可维护性。

请注意,每个步骤的执行都需要对业务需求和目标进行全面考虑和权衡,以便做出最合适的设计决策


总结

本文首先介绍了微服务的常见设计规则,接着,详细阐述了微服务设计的方法和步骤。设计方法适用于各种规模和复杂度的系统。无论是小型应用还是大型分布式系统,都可以采用微服务设计方法来实现模块化和可扩展的架构。 总之,微服务的设计规则、方法和步骤是实现高效、灵活和可扩展系统的关键。通过合理地应用这些设计原则,可以构建出稳定、可靠的微服务架构,并为业务的持续发展提供支持。

文章来源:https://blog.csdn.net/moon_ly/article/details/134832250
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。