转载

杂谈：微服务的体系结构评审的三个问题

点击蓝色“ 程序猿DD ”关注我

回复“ 资源 ”获取独家整理的学习资料！

作者 | 遗失的拂晓

来源 | 公众号「锅外的大佬」

面向微服务的体系结构如今风靡全球。这是因为更快的部署节奏和更低的成本是面向微服务的体系结构的基本承诺。

然而，对于大多数试水的公司来说，开发活动更多的是将现有的单块应用程序转换为面向微服务的体系结构，这可能是许多层面上阻碍和冲突的根源。

虽然Greenfield (未开发的)面向微服务的体系结构实现可以坚持对当前微服务的严格解释-设计原则。但在面向微服务的体系结构中，分解的遗留应用程序存在灰色阴影，如果没有其他原因，只能满足预算和时间限制。

在企业管理链的某个地方，有一位业务主管在一个面向微服务的体系结构中查看与这些遗留应用程序相关的分解成本，并将其与遗留代码已经提供的价值进行比较。一旦开发成本超过了预期的收益，业务主管很可能会退出并取消该项目。

这种事经常会发生。

因此，开发经理面临着巨大的压力，要求他们尽快将代码输出。 “足够好”地成为转型的理想目标。

现在，这不一定是一件坏事。与等待梦想到来相比，输出工作代码的能力总是更好。但是，“灰色的阴影”是很难管理的，问题就在于如何界定“足够好”的界限。

因此，冲突开始了。一方想要输出他们想要的东西，而另一方则希望做更多的改进。

对你来说，挑战是不要让这些不同学派在本质上是信仰支持的观点上制造一场没完没了的争吵。如果您这样做了，它将造成一种情况，即根本不提供任何代码。现在，冲突可以从许多相互竞争的想法中综合出最好的想法。但是，当话语退化为永无止境的冲突时，它可能是致命的。

我通过集中讨论以下三个问题来处理这类情况，以避免这种冲突：

设计的理由是什么？
风险有多大？
减少风险的计划是什么？

请允许我详细说明。

1. 设计的理由是什么？

当您评估面向微服务的体系结构的设计时，所面临的挑战是将过去的观点转移到理论基础分析上。它的创建主要来自于单个应用程序的分解。任何设计都可能“足够好”，只要你能证明它的好处和价值。

例如，面向微服务的体系结构设计的首选样式之一是采用事件驱动的方法进行服务间通信。具体来说，这意味着您使用消息节点以异步方式在微服务之间传递消息。然而，从长远来看，虽然异步通信更加灵活和可扩展，但消息系统实现比在“面向”微服务的API之间使用同步HTTP调用的设计要复杂得多。因此，当市场时间被关注时，完全有理由将单块应用程序中的特性重构为以HTTP API方式表示的独立的微服务。

杂谈：微服务的体系结构评审的三个问题 Synchronous microservices are usually less complex to implement than asynchronous ones.

与异步服务相比，同步微服务的实现通常不那么复杂。

从长远来看，同步通信不一定是最佳选择，但考虑到从单块应用程序中提取独立的微服务所需的所有其他工作，同步对于第一个版本来说是“足够好”的。因此，这是一个合理的理由。

然而，这并不是说同步方法没有风险。事实上，风险有很多。当涉及到审查面向微服务的体系结构设计时，仅仅说明理由并不是唯一的因素。风险也必须加以阐述。

2. 风险有多大？

所有的设计都有内在的风险。在上面描述的同步设计示例中，这种服务间通信方法可能会导致服务之间类型耦合的风险，由于同步HTTP通信和其他通信的性质而增加延迟增加延迟。

重要的是要让人们知道这些风险，这样就可以根据预期设计的合理性来权衡它们。如果风险是巨大的，再多的理由也是不够的。另一方面，考虑到目前的需求，某些风险可能是可以接受的。诀窍是确保风险在审查过程中得到明确的传达。讨论中已知的风险总是比隐藏的风险更可取，而这种风险可能会在路上造成冲击。此外，如果您以前知道风险，那么随着面向微服务的体系结构的成熟，您可以计划如何在未来的版本中更好地向前迈进。这就是减少风险的原因。

3. 减少风险的计划是什么？

一个明智的应用程序设计人员的一个标志是能够识别他们的设计风险，一旦确定下来他会有远见地阐明一种方法，以减轻这些风险。没有适当的缓解技术的风险识别是思维不完整的标志。

如果面向微服务的体系结构设计有很大的风险和解决这些问题的边际计划，那么设计团队需要认真考虑其可行性。此外，如果缓解计划不切实际-超出项目的专门知识和预算-设计的可行性也需要质疑。这都是平衡的问题。

一个平衡良好的面向微服务的体系结构设计是合理的，因为它想要满足的条件与其固有的设计风险和旨在解决这些风险的缓解计划相权衡。

4. 把它们放在一起

冲突是创造性进程的重要组成部分。有创造力的人往往对自己的想法坚韧不拔。所以，当你把它们放在一个房间里，让他们为面向微服务的建筑设计一个单一的设计时，紧张关系肯定会加剧。事情就是这样的。但要振作起来！冲突是好事。

幸运的是，有了一种理性的方法，用我前面描述的三个问题来审查面向微服务的体系结构设计，您就可以促进客观的讨论，从而产生软件以及时满足您的需求。没有任何设计是完美的，特别是那些分解单个应用程序的设计。但是，交付面向微服务的体系结构有一个很大的好处，这个体系结构足够好有效运作在短期和灵活性足够持续不断改善长期。

本文通过OpenWrite的免费Markdown转换工具发布