为您的组织设计微服务？遵循这些设计原则来创建健壮且可扩展的微服务
在本文中，我将分享您在设计和开发微服务时可以遵循的基本设计原则。这些设计原则与软件再开发密切相关，它将帮助您设计健壮、可扩展和可维护的微服务。
程序员的 10 条基本微服务设计和开发原则
以下是您在进行微服务开发时可以牢记并遵循的 10 条微服务设计原则的列表。从长远来看，即使在开发和部署之后，它们也会为您提供很多帮助。
1.单一职责原则
这对任何软件开发人员来说都不陌生，作为学习SOLID 设计原则的一部分，我们每个人都熟悉这一点，但这也适用于微服务。
根据 SRP 或单一职责原则，每个微服务都应该有一个单一的、定义明确的职责，并且应该只与其他微服务通信以完成任务。.
例如，一个微服务可以处理用户身份验证，而另一个微服务可以处理支付处理。但是你不应该创建一个同时进行用户身份验证和支付处理的微服务，这将违反 SRP。
您可以在下图中看到我们有不同的服务来处理不同的功能，如账户服务、库存服务和运输服务。
2.分散的数据管理
根据分散数据管理原则，每个微服务都应该管理自己的数据，而不依赖于其他微服务，以确保可扩展性和可靠性。例如，每个微服务都可以有自己的数据库来存储数据。
与其他微服务共享数据库违反了这一原则，应该避免，因为这会使故障排除变得困难，并可能导致数据不一致。
这个设计原则将帮助您更好地管理您的数据库，它也是每个微服务设计模式的基础，这是一个基本的微服务设计原则。
如果您正在考虑另一个微服务如何访问相同的数据，因为另一个服务很可能确实需要它？好吧，您应该始终为此创建 API，正如我们将在下一个微服务设计原则中看到的那样。
你可以在下面的微服务架构中看到这一点，我们有不同的数据库用于 UserService、MessageService 和 FriendService。
3. API 驱动设计
这是我最喜欢的微服务设计原则，它在实际设计微服务时有很大帮助。根据这一原则，微服务应该围绕 API 进行设计，每个服务都公开一组定义良好的 API，以便与其他服务进行通信。
例如，微服务可以公开用于检索客户信息的 API，其他微服务可以使用该 API 来访问该信息。
这个原则也和之前提倡微服务不共享数据库的设计原则一致。您必须为需要访问数据的其他服务创建 API，然后这将驱动您自己的微服务设计。
4. 无状态
根据这个原则，微服务应该是无状态的，这意味着它们不应该在请求之间维护任何特定于客户端的状态。
例如，如果微服务处理用户的购物车，它不应该在请求之间存储任何关于用户购物车的信息，而是应该在每次处理请求时从数据库中检索购物车信息。
如果我只能根据我多年设计 Java 服务的经验给出一个建议，那么我会说尽可能长时间保持无状态。通过不在服务中管理状态，您将避免由此产生的许多问题，并且您可以从诸如缓存之类的东西中受益匪浅，以提高性能。
5.松耦合
这是另一个同样适用于微服务的软件设计原则。在面向对象的设计中，我们的目标是失去对我们的类、包和模块的耦合，我们可以将相同的规则应用于微服务。
根据这个原则，微服务应该是松散耦合的，这意味着它们不应该相互依赖，以确保可扩展性和易于部署。
例如，如果一个微服务宕机，其他微服务应该仍能正常运行。下图说明了紧耦合和松耦合的微服务：
6. 智能端点和哑管道
根据这一原则，数据处理逻辑应位于微服务本身，而不是集中式中心，以确保可扩展性和可靠性。如果您想知道端点和管道在这里意味着什么，端点是 API 或 URL，而管道是数据库队列。
该模式建议端点（例如用户界面或 API）应该设计得更智能，处理所有表示和业务逻辑，而管道（例如队列或数据库）应该设计得更笨，仅执行简单的数据传输和存储功能。
例如，微服务可以负责处理客户订单，而不是让一个集中式中心处理所有订单处理。
使用此模式的主要好处是，它使开发团队能够创建具有松散耦合组件的应用程序，这些组件可以独立开发和部署，从而实现更好的可扩展性和更轻松的维护。
这种模式还有助于简化开发过程，因为开发人员可以专注于在其智能端点中实现特定功能，而不用担心底层通信和数据存储系统。
但是，这种模式的一个缺点是它会使调试变得更加困难，因为错误可能会出现在多个组件中。此外，智能端点可能需要更多资源和处理能力，这会增加运行应用程序的成本。
这是一个很好的图表，它说明了这个原则：
7.自动缩放
当我们想到微服务时，我们会想到缩放，这是处理它的原则。根据此最佳实践和原则，每个微服务都应设计为自动扩展或缩减以响应需求变化，以确保应用程序保持响应性和可用性。
例如，如果访问微服务的用户数量增加，该微服务可以自动启动额外的实例来处理增加的需求。
在现实世界中，像 Kubernetes 这样的工具可以通过创建微服务的新实例并在不再需要时销毁它们来自动扩大和缩小规模。
如果您的微服务不是为自动扩展而设计的，那么它就无法充分利用云和 Kubernetes 等工具，因此您必须确保它们是为扩展而设计的。如果您想知道如何实现这一目标，请继续关注，我将在下一篇文章中分享更多有关如何确保微服务可扩展性的技巧。
8. 监控和日志记录
在拥有数百个微服务的项目中工作的主要问题之一是调试非常困难。很难找到请求失败的原因，因为日志是分散的。
您可能会看到用户身份验证错误，认为用户凭据有问题，但由于服务超时，您只能通过查看多个服务的日志来了解真正的原因。
按照这个原则。微服务应该有强大的监控和日志记录机制来帮助诊断问题和跟踪性能。
例如，每个微服务都可以记录有关其性能和使用情况的信息，这些信息可用于识别和诊断问题。这肯定会帮助您长期和日常支持工作。
9. 持续部署与集成
根据这一原则，任何微服务都应该是可持续部署的，这意味着它们应该通过小的、增量的更改（如错误修复、小的增强等）经常更新。
例如，可以更新微服务以修复错误或添加新功能，而不会影响应用程序的其余部分。
持续部署是通过多种技术的组合来实现的，例如构建和部署过程的自动化、测试以及与版本控制系统、问题跟踪系统和监控工具等其他工具的集成。
通过自动化部署过程，团队可以确保快速、一致地部署新的更改，同时最大限度地减少人工干预。
这种做法还有助于减少停机时间并最大限度地降低错误风险，因为新更改在部署到生产环境之前会经过全面测试。此外，它允许组织更频繁地发布新功能和错误修复，从而增加创新并加快上市时间。
10.基础设施自动化
这是 DevOps 的东西，但作为开发人员，我们也应该熟悉它。根据这一原则，微服务的部署和管理应该自动化，以确保一致性和效率。
例如，您可以使用 Docker 或 Kubernetes 等工具来自动部署和扩展微服务。这实际上是现在所有公司的标准做法，它确保部署过程一致且高效。
您可以创建用于自动部署的 Jenkins 管道，也可以使用 Terraform 等工具自动创建环境。这是一个用于自动部署微服务的示例管道。
这就是每个 Java 开发人员都应该了解的基本微服务设计原则。通过遵循这些设计原则，您可以构建可扩展且可靠的微服务应用程序，以满足客户的需求。
它们不仅可以帮助您构建健壮且可扩展的微服务，还可以在调试、监控、故障排除和维护微服务时节省时间，这是不断增长的微服务领域面临的主要挑战。