人体是不同系统的组合，其中大部分是独立的，又作为一个整体协同工作。每个系统都有自己特定的功能。所有器官与其他各种支持框架形成一个功能齐全的身体。现在，如果应用于软件系统，这就是微服务架构的概念。在技??术方面，微服务系统允许开发单独的功能模块。这种开发单一功能模块的趋势为大大小小的组织提高了灵活性、性能和成本效率，同时支持持续测试和早期交付。但是，在我们深入微服务设计的基础知识之前，让我们先看看它的优势。微服务架构的优势使用单体架构，开发人员经常面临可重用性和可扩展性有限的挑战。但是，通过微服务设计，这个单元可以分解成不同的模块，从而简化了开发、部署和维护。因此，让我们来看看微服务架构的一些主要优势：技术灵活性虽然整体式架构总是让开发人员寻找“适合工作的工具”，但微服务架构提供了多种技术在一个外壳下的共存。不同的解耦服务可以用多种编程语言编写。这不仅使开发人员能够进行试验，还可以通过添加额外的特性和功能来扩展他们的产品。提高效率微服务架构加快了整个创建过程。与单个单元不同，团队可以同时处理软件系统的多个组件。除了提高生产力之外，还可以更轻松地定位特定组件并专注于它们。单个组件的故障不会影响整个系统。反过来，这也简化了错误定位和维护。产品而不是项目根据MartinFowler的说法，微服务架构可以帮助企业创建“产品而不是项目。简而言之，微服务架构的使用允许团队聚集在一起并为业务创建功能，而不是简单的代码。整个团队聚集在一起共同贡献不同的功能，如果适用，这些功能可以进一步用于不同的业务。同时，它创建了一个自治的跨职能团队。成功微服务设计的基础现在我们知道了微服务架构的优势，但是，我们如何做到完美我们了解微服务设计原则？设计微服务架构的最佳实践是什么？让我们回答这些问题并了解成功的微服务设计的一些基础知识。1.功能范围随着不同团队的实施，定义微服务的范围成为一项重要的任务同时开发和部署以构建或支持功能a产品的独特性。虽然许多人担心创建“太多”的微型微服务，但更常见的是这些微服务超载了。当我们谈论微服务的范围时，我们指的是独立软件模块的功能。微服务几乎是无状态系统的能力使它们能够独立开发。因此，必须确定微服务将实现的功能。这是否有助于理解微服务的职责？实现每个微服务应该提供的预期功能。不仅要防止过载，还要服务于不同的场景。例如，如果一段代码在整体设置中被多次调用，创建微服务将使它更容易访问和使用。最小化代码大小只会提高效率并避免臃肿的服务。问题是关于如何定义微服务的范围。虽然没有明确定义的规则集来实现这一点，但如果您可以定义范围，则可以使用一些指南或最佳实践。以下是您可以用来定义微服务的一些步骤。第一步是识别在各种模块下复制的代码片段。您多久看到一次重复？每次将它们设置在不同的模块中需要多少努力？如果所有这些的答案都很高，那么微服务的范围就是只处理重复的代码片段。您可以采取的另一个步骤是检查该模块是否不依赖于其他模块，或者更简单地说，检查该模块是否可能与其余服务松散耦合。如果是这样，那么微服务的范围就是整个模块的范围。定义范围时要考虑的另一个非常重要的指标是检查功能是否将用于重负载。这将检查是否必须在不久的将来扩展微服务。如果是这样，最好将可扩展性位定义为微服务的范围，而不是将其与其他功能相结合。2.高内聚和松耦合任何微服务的主要动机是让服务相互独立。这意味着可以在不妨碍任何其他服务的情况下编辑、更新或部署新服务。如果相互依赖性很低，这是可能的。松散耦合的系统是其中的服务对其他服务知之甚少或一无所知的系统。将单体架构分解为更小的服务或组件时，组合相似的功能非常重要。将相关逻辑组合成一个单元称为内聚。内聚性越高，微服务架构越好。低内聚表示由于不同服务之间的过度通信而导致的系统性能差。3.唯一标识源遵循微服务设计的基本原则，任何服务都必须是系统其余部分的唯一标识源。让我们举个例子来了解情况。在电子商务网站下订单后，向用户提供订单ID。生成此订单ID包含有关订单的所有信息。作为微服务，订单ID是有关订单服务的任何信息的唯一来源。因此，如果任何其他服务寻求有关订单服务的信息，订单ID将充当信息源而不是其实际属性。4.API集成将整体设计分解为多个服务，意味着这些服务将相互协调、协同工作，形成系统。但是这些服务如何通信呢？想象一下使用多种技术来创建不同的服务。它们之间有什么关系？嗯，简单的答案是使用API（应用程序编程接口）。微服务设计的基础是使用正确的API。这对于维护服务和客户端调用之间的通信至关重要。易于过渡和执行对于正常运行很重要。创建API时要注意的另一个重要事项是业务领域。这种域的定义将简化区分功能的过程。系统外部有多个客户端。这些客户端可以是其他应用程序或用户。每当调用业务逻辑时，它都由适配器（消息网关或Web控制器）处理，适配器返回请求并对数据库进行更改。5.数据存储隔离为特定服务存储的任何数据都应对该特定服务保密。这意味着对数据的任何访问都应归服务所有。此数据只能通过API与任何其他服务共享。这对于保持对数据的有限访问和避免“服务耦合”很重要。基于用户的数据分类很重要，可以通过命令和查询责任分离(CQRS)来实现。6.流量管理一旦设置了API并且系统启动并运行，流量将因不同的服务而有所不同。流量是客户端发送给特定服务的调用。在现实世界中，服务运行缓慢，导致调用时间更长。或者该服务可能会被呼叫淹没。在这两种情况下，性能都会受到影响，甚至导致软件或硬件崩溃。需要管理这种高流量需求。具体的呼叫和被呼叫方式是畅通交通的答案。服务应该能够终止任何导致延迟和影响性能的实例。这也可以使用称为“自动缩放”的过程来实现，该过程涉及在需要时通过快速行动持续跟踪服务。在某些情况下，“断路器模式”很重要，可以提供在呼叫中断或服务无响应时可用的任何不完整信息。7.自动化流程独立设计的微服务应该能够独立运行。自动化将在没有任何干预的情况下自行部署和运行。此过程使服务本质上是云原生的，并且能够部署在任何环境中。但要实现这个目标，让DevOps团队持续致力于服务的开发是非常重要的。8.最少的数据库表（最好是孤立的表）访问数据库表以获取数据可能是一个漫长的过程。这可能需要时间和精力。在设计微服务时，主要动机应该围绕业务功能而不是数据库及其工作。为了确保这一点，即使数据条目达到数百万，微服务设计也应该只有几个表。除了最低数量，专注于业务是关键。9.持续监控想象一下将单体架构分解为微服务设计。这需要大量的时间和资源。借助传统工具监控所做的所有更改并不容易。插入数据层和缓存会提高性能，但很难监控整个过程。因此，为了设计微服务架构，建立在中央位置主动监控数据存储的程序非常重要。这有助于在不影响系统性能的情况下反映频繁的更改。在常见的场景中，微服务监控工具将监控单个服务，然后通过将数据存储在一个集中位置来组合数据。这是遵循微服务设计原则的必要步骤。了解API在成功的微服务架构中发挥的关键作用。还必须有一个持续监控API性能的过程。API性能监控对于任何微服务架构都至关重要，以确保功能在产品的速度、响应能力和整体性能方面保持一致。微服务架构的局限性虽然微服务是降低整体架构的最佳方式，但它也有其自身的一些缺点。但在得出任何结论之前，让我们先看一下其中的一些。1.开发环境超载。随着应用程序及其数据库的增长，代码库也在不断扩展。随着代码针对每个微服务进行扩展，它会使每个加载的应用程序的开发环境过载。这可能会导致生产力的显着延迟。2.DevOps的复杂性单功能微服务的开发和部署并不是一件容易的事。使用多种技术集中化系统并创建API是一项挑战。这需要经验丰富的DevOps团队。获得这样一支经验丰富的DevOps团队对于维护基于微服务的应用程序的复杂性至关重要。3.增加资源和网络使用由于多个组件协同工作，因此以某种方式相互通信很重要。此通信将导致网络使用量增加。这需要高速可靠的网络连接。此外，运行这些应用程序的成本也会增加。所有服务单独运行，增加了运营成本。4.测试测试应用程序可能具有挑战性，因为组件是独立的。与单体应用程序相比，微服务需要更长的测试时间，并且在出现任何错误时更加复杂。有时，由于测试最终会影响整个应用程序，可能会导致延迟。5.安全性对于网络应用程序，安全性是最重要的。使用微服务，这很难实现。当存在独立模块集群时，每个模块都需要遵守为整个系统定义的认证和授权规范。除此之外，每个模块都可能与其他模块通信，跟踪数据流变得非常困难。需要额外的措施，例如具有负载平衡的API网关，以确保一致的行为。这些额外的步骤会给每个微服务带来开销。6.应用的复杂性由于微服务是独立的组件，每个微服务通常都有最适合其需求的技术栈。例如，机器学习模块可能使用python堆栈，而计量服务可能使用Java堆栈，UI服务可能使用MEAN堆栈。这会导致复杂性，因为管理和构建新功能所需的资源池和技能将非常高。7.高初始投资微服务独立运行，它们需要单独的容器或资源来运行它们。每个项目可能有很多微服务一起工作，需要更高的投资来建立所有的集群，包括微服务、安全容器、负载均衡器、API网关等，这值得吗？在阅读了微服务设计的基础知识之后，很明显可以遵循一组最佳实践。但是，我们还观察了微服务设计原则如何通过打破单体架构来简化创建应用程序的过程。然而，与此同时，在调整微服务架构时也有一些挑战需要克服。这些复杂性会影响运营流程，但从长远来看，克服这些挑战可以带来优化且更高效的应用程序。此外，它克服了延迟和缺陷，同时提高了灵活性和性能。记住上面提到的内容，可以说微服务架构对于一个成功的软件系统是必不可少的。包括PayPal、Twitter、LambdaTest和Netflix在内的许多企业都采用微服务架构的可靠性来部署更具可扩展性、功能更强大且更强大的软件。原标题：微服务设计成功的9个基础
