本文共 3107 字，大约阅读时间需要 10 分钟。

我真的很讨厌“最佳实践”这句话，主要是因为它使人们相信只有一种正确的做事方法。但是我想围绕一些想法来发表文章，以加强您的微服务架构。

正如我之前讨论的那样，微服务架构的实现更为复杂，但对您的解决方案却有很多巨大的好处。其中一些好处是：

• 可独立部署的部分，不再进行大规模部署
• 更集中的测试工作
• 为您的解决方案的每一部分使用正确的技术
• 我从基于集群的部署中提高了弹性

但是对于包括我自己在内的许多人来说，此过程中最困难的部分是如何构建微服务？每部分应该多小？他们如何一起工作？

因此，如果您开始在解决方案中利用这一点，那么我发现了一些有用的实践。

一个服务=一个工作

第一个问题是我的容器应该多小。有什么是太小的吗？重点关注的一个好的经验法则是分离问题的想法。如果您将每个用例都分解成一个单一的用途，您会发现您很快就会得到一个好的微服务设计。

让我们看一些例子。我最近与我的一位同事一起研究了一种解决方案，最终从API中提取了信息，然后提取该信息以将其放入数据模型中。

用整体的思维方式，应该是1个API调用。传递数据，然后循环进行处理。但是问题是吞吐量，如果我要提取67个不同的区域，并且每个区域提取300多个记录并将其作为批处理，那将是一个巨大的API调用的混乱。

因此，相反的，我们有一个循环遍历区域的函数，然后将它们全部拉到blob存储中的json文件中，然后将消息排队。

然后我们有了另一个功能，当一条消息排队时，它将接收该消息，读入该区域的记录，然后将它们保存到数据库中。此单独的功能是另一个微服务。

现在，这种方法有很多好处，但是最主要的是，第二个功能可以独立于第一个功能扩展，而且我可以使用异步处理对排队的消息进行响应。

三个词……领域驱动设计

有关领域驱动设计的详细定义，请参见。这个想法很简单，构建软件和应用程序的结构应该反映正在实现的业务逻辑。

因此，例如，您的微服务应反映其尝试执行的操作。就像让我们以最直接的示例为例……电子商务。

如果我们必须跟踪订单并提交以下订单的流程，请执行以下操作：

• 订单已提交。
• 库存已验证。
• 订单付款已处理。
• 通知已发送给供应商进行处理。
• 确认已发送给客户。
• 订单已完成并发货。

综上所述，实现此目标的一种方法是执行以下操作：

• OrderService：从头到尾管理订单。
• OrderRecorderService：在跟踪系统中记录订单，因此您可以在整个过程中跟踪订单。
• OrderInventoryService：获取订单内容并对照库存进行检查。
• OrderPaymentService：处理订单的付款。
• OrderSupplierNotificationService：与第三方API交互，将订单提交给供应商。
• OrderConfirmationService：发送电子邮件以确认订单已收到并正在处理。
• OrderStatusService：继续检查第三方API的订单的状态。

如果您在上面注意到，那么在业务流程之外，它们与业务步骤完全匹配。这提供了一种简化的方法，使更改变得容易，并且对于新团队成员而言也很容易理解。服务之间的通信很可能是通过队列完成的。

例如，假设上述公司希望扩展以接受Venmo作为付款方式。确实，这意味着您必须更新OrderPaymentServices才能接受该选项并处理付款。此外，OrderPaymentService它本身可能是不同的微服务之间的编排服务，一种按付款的方式。

使它们独立部署

这是一个很大的问题，如果您真的想看到微服务的好处，那么它们必须是可独立部署的。这意味着，如果我们看一下上面的示例，我可以部署这些单独的服务中的每个服务，并对它们进行更改，而不必进行完整的应用程序部署。

以上述情况为例，如果我想添加新的付款方式，则应该能够更新OrderPaymentService，签入这些更改，然后通过生产将其部署到开发中，而不必部署整个应用程序。

现在，我第一次听到这个消息，我以为那是我听过的最荒谬的事情，但是您可以做一些事情来实现这一点。

• 每个服务应具有自己的数据存储：如果确保每个服务都具有自己的数据存储，则可以更轻松地管理版本更改。即使您要利用SQL Server之类的东西，也要确保每个微服务所利用的表都被该服务使用，并且仅被该服务使用。这可以使用模式来完成。
• 在服务通信之间放置抽象层：例如，一个很常见的例子是排队或事件。如果您正在传递消息，则只要消息离开没有变化，就无需更新接收方。
• 如果要直接进行API通信，请使用版本控制。如果您必须具有连接这些服务的API，则可以利用版本控制来部署和更改微服务，而不会破坏应用程序的其他部分。

头脑灵活应变

如果您对微服务采用这种方法，那么您很快就会注意到的最大事情之一就是每个微服务都变成了自己的黑匣子。因此，我发现在构想这些组件时最好考虑弹性。利用Polly进行重试或断路器模式之类的事情。这些是确保您的服务保持弹性的好方法，并且会对您的应用程序产生累积影响。

例如，以我们上面的OrderPaymentService内容为基础，我们知道队列消息应该与订单和付款详细信息一起传入。我们可以使用显微镜进行这项服务，然后说，它怎么会失败，不难找到这样的列表：

• 邮件以错误的格式通过。
• 无法达到付款服务。
• 付款被拒（由于多种原因之一）。
• 等待付款处理时服务失败。

现在，对于上面的某些内容，这只是一些简单的错误处理，例如，检查消息的格式。我们还可以构建逻辑来检查支付服务是否可用，并进行指数重试直到可用。

我们可能还会考虑实现断路器，即如果尝试了这么多次后仍无法处理付款，则服务会切换到不良状态并导致通知工作流程。

在最后一个场景中，我们可以实现一个状态存储，该状态存储指示正在处理的支付的状态，当一个服务失败并需要由另一个服务拾取时。

考虑尽早监控

这是每个人都忘记的事情，但是与前一个很好地吻合。跟踪和监视微服务状态的机制很重要。我经常说“服务正在运行，这很正常”很容易。这就像说只是导致首页加载而已，一个完整的Web应用程序正在运行。

您应该在微服务中内置跟踪其运行状况的能力，并为操作工具提供一种这样做的方法。让我们面对现实，最终，所有代码最终都将被部署，并且所有部署的代码都必须受到监控。

举个例子，看看上面。如果我将断路器模式构建到OrderPaymentService中，则每个故障都会更新存储在服务内存中的状态，该状态说这是不健康的。然后，我可以公开一个HTTP端点，该端点返回该断路器的状态。

• 关闭：服务运行良好且健康。
• 半开：服务遇到一些错误，但仍在处理中。
• 开放：由于服务不健康，该服务已脱机。

然后，我可以建立逻辑，使其变为半开，甚至打开特定事件。

从小处着手，不要滥用Ocean

鉴于上述情况，这似乎有点讽刺。但是，如果您正在使用现有的应用程序，你永远无法说服管理层允许你抛弃它，重新开始。因此，我过去所做的就是创建一个应用程序，当您发现有时间对应用程序的那部分进行更改时，请趁机进行重新架构并使其更具弹性。分解各个部分，并实现微服务响应以解决问题。

无状态超过有状态

老实说，这只是习惯的好习惯，大多数容器技术（例如Docker或Kubernetes或其他选项）确实赞成弹性扩展的思想以及随时启动或终止进程的能力。如果您必须管理容器中的状态，这将变得更加困难。如果必须管理状态，我绝对建议您使用外部存储来获取信息。

现在我知道并不是每一个都适合您的情况，但是我发现这10个项目使您更容易过渡到为您的解决方案创建微服务，并看到这样做的好处。

转载地址：http://pbwhj.baihongyu.com/