微服务架构——介绍、挑战和最佳实践
在软件开发中，开发人员遵循不同的方法、技术、架构模式和最佳实践来构建高质量的软件或系统。微服务是行业中流行的架构模式风格之一。你可能听说过这个名字，你可能已经为它工作过。
在微服务架构中，我们将应用程序分解为更小的服务。这些服务中的每一项都满足特定目的或满足特定业务需求，例如客户支付管理、发送电子邮件和通知。在本文中，我们将详细讨论微服务架构，我们将讨论使用它的好处，以及如何从微服务架构入手。
什么是微服务架构？
简单来说，它是一种软件开发方法，我们将应用程序分解为小的、独立的、松散耦合的服务。这些服务由一小部分开发人员开发、部署和维护。这些服务有一个单独的代码库，由一小群开发人员管理。
这些服务不相互依赖，因此如果团队需要更新现有服务，无需重新构建和重新部署整个应用程序即可完成。使用定义良好的 API，这些服务可以相互通信。这些服务的内部实现不会相互暴露。
微服务的优点/好处
1、独立开发部署：微服务中的每一个服务都是独立部署的。正如我们所讨论的，一个小团队负责这些服务的构建、测试和部署。这可以加快开发速度。此外，修复错误和发布功能变得容易。如果出现问题，您可以轻松更新服务并回滚。
这是关于微服务的最好的事情之一，这个特性在许多传统应用程序中是不可用的。如果在一个进程或应用程序的一部分中发现错误，那么要解决它，您将不得不阻止整个发布过程。
2. 专注的小团队：要专注于单一服务，需要有一个小团队。代码变得容易理解，对于新成员来说，加入团队变得容易。无需花费数周时间来弄清楚复杂的巨石是如何工作的。在大型团队中，很难进行适当的沟通，从而导致缺乏灵活性。管理时间增加，敏捷性降低。
3. 小型代码库：在单体应用程序代码中，依赖关系会随着时间的推移而变得复杂。如果开发人员需要添加一些新功能，他们需要在多个地方进行更改。在微服务架构中，代码库或数据库是不共享的。依赖性被最小化，并且更容易添加新功能。此外，更容易理解代码和添加新功能。
4. 技术组合：在微服务架构中，您可以自由选择最适合您的服务的任何技术。您可以混合使用多种技术并将它们用于您的服务。
5. 故障隔离：在微服务架构中，您可以轻松处理关键故障点。如果服务出现故障，整个应用程序的功能不会停止，只要任何上游微服务都旨在处理故障。
6. 可扩展性：您将应用程序分解为更小的服务，这使得它们易于独立扩展。您不需要扩展整个应用程序。使用 Kubernetes 或服务结构等编排器，您可以将更高密度的服务打包到单个主机上。资源被更有效地利用。
7. 数据隔离：模式更新更容易执行，因为只有一个微服务受到影响。在单体应用程序中，模式更新很困难。应用程序的各个部分可能会触及相同的数据。更新数据会使架构有风险。
微服务的挑战/缺点
我们已经讨论了微服务的好处。现在让我们讨论一下它的挑战或缺点。
1、复杂性：微服务中的服务更简单，但整个系统更复杂。您需要处理所有服务和数据库，并且需要独立部署每个服务。
2. 测试：您需要一种不同的方法来编写依赖于其他依赖服务的小型服务。这与传统的单片或分层应用程序不同。如果服务相互依赖，编写测试将更加复杂。要进行单元测试，必须使用依赖服务模拟。
3.数据完整性：微服务支持分布式数据库架构。微服务中的每个服务都负责自己的数据持久化。在这些情况下，数据完整性或数据一致性可能是一个挑战。对于某些业务转换，您可能必须更新应用程序的多个业务功能。对于不同的服务，您可能需要更新多个数据库。您将不得不设置更复杂的数据的最终一致性。
4、网络延迟：微服务中的许多小服务需要更多的服务间通信。如果微服务中的服务会有很长的依赖链，那么额外的延迟可能会成为您的问题。您必须仔细设计 API。
5. 版本控制：如果一个服务需要更新，那么它不应该破坏依赖它的服务。如果多个服务需要同时更新，那么如果没有精心设计，您可能会面临一些向后或向前兼容性的问题。
最佳实践
1.您可以围绕业务领域对服务进行建模
2.我们已经讨论了为特定服务分配单个团队，因此无需共享代码或数据模式。
3.对于每个服务数据存储应该是私有的。您需要为每种服务和数据类型使用最佳存储。
4.微服务中的每个服务都应该通过精心设计的 API 进行通信。实施细节不应泄露。
5.服务之间应避免耦合。这种耦合有多种原因，包括共享数据库模式和严格的通信协议。
6.您应该将领域知识排除在网关之外。应该在不了解业务规则或域逻辑的情况下处理客户端请求的路由。这应该非常小心，否则您将面临服务之间的耦合问题。
7.服务之间应该有松耦合和高功能内聚。一起改变的功能应该一起打包和部署。如果这些功能驻留在不同的服务中，那么这最终应该是紧密耦合的。更新一项服务需要更新另一项服务。