转向微服务如何造成运行时问题？

以下评论员写道：

微服务将组织功能障碍从编译时问题转移到运行时问题。

该评论员扩展了该问题的说法：

功能不是错误。运行时问题=>产品问题=>向功能负责人反馈更强大，更快速的功能障碍

现在，我通过微服务获得了您：

• 可能会增加吞吐量的延迟-这是生产和运行时的问题。
• 增加代码中“网络接口”的数量，其中可能存在潜在的运行时解析错误。
• 可能会进行蓝绿色部署。接口不匹配可能会阻止这些故障（请参阅网络接口）。但是，如果蓝绿色部署能够正常工作，那么它就更是运行时的问题。

我的问题是：转移到微服务会带来运行时问题，这是什么意思？

我有个问题。让我们使用微服务！现在我有13个分布式问题。

将系统分为封装，内聚和解耦的组件是一个好主意。它使您可以分别解决不同的问题。但是，您可以在整体部署中完美地做到这一点（请参阅Fowler：Microservice Premium）。毕竟，这是OOP几十年来一直在教的东西！如果您决定将组件转换为微服务，则不会获得任何架构优势。您将在技术选择方面获得一些灵活性，并且可能（但不一定！）获得一些可伸缩性。但是，由于（a）系统的分布式特性和（b）组件之间的通信，您一定会感到头疼。选择微服务意味着您还有其他迫在眉睫的问题，尽管有这些问题，您仍然愿意使用微服务。

如果您无法设计干净整洁的组件，那么您也将无法设计微服务系统。在整体代码库中，痛苦将非常明显。理想情况下，如果代码严重损坏，将不会编译。但是对于微服务，每种服务都可以单独开发，甚至可能使用不同的语言。在集成组件之前，组件交互中的任何问题都不会变得明显，到那时，修复整个体系结构为时已晚。

错误的第一大来源是接口不匹配。可能会出现明显的错误，例如缺少参数，或者更细微的示例，例如忘记检查错误代码或忘记在调用方法之前检查前提条件。静态类型可以在代码运行之前尽早检测到此类问题：在您的IDE和编译器中。动态系统没有这种奢侈。在执行错误的代码之前，它不会崩溃。

微服务的含义令人恐惧。微服务本质上是动态的。除非您使用正式的服务描述语言，否则您无法验证接口使用情况的任何正确性。您必须测试，测试，测试！但是测试是昂贵的，并且通常不能穷举，这可能会导致生产中仍然存在问题。这个问题何时会显现出来？只有在运行时在生产中采用该错误路径时。产品问题会导致更快的反馈的观念是滑稽地 除非您对数据丢失的可能性感到高兴，否则这是非常危险的错误。

第一条推文是我的，因此我将在其上进行扩展：

假设您有100个开发人员，在一个整体应用程序上工作。太多的人无法彼此有效地沟通，因此公司必须努力将他们分成较小的团队，并在他们之间建立良好的沟通模式。当组织处于“功能失调”状态时，团队可能不会互相交谈，他们没有达到更大的目标，他们在优先事项等方面意见不一致-结果，他们要花很多时间才能运送东西。从某种意义上说，功能异常在软件生产之前就很明显，这是一个“编译时问题”。该项目可能是步履蹒跚或永不出货（“编译”）。

我认为许多人被微服务所吸引，并且正在转向微服务，这并不是因为固有的技术/架构优势，而是因为它使他们可以忽略组织功能障碍。他们希望不要让100个开发人员结盟，而是希望他们可以有一些小团队在各自为战，每个团队都专注于自己的微型服务。如果您处于这样一个功能失调的组织中，那么它会如此吸引人：它给您更大的权限，可以避免您不喜欢的人，不进行交流。

不幸的是，这成为一个“运行时问题”，因为一旦软件在生产中运行，良好的沟通就变得同样重要。组织的问题-团队以及他们如何协调和沟通-在“运行时”出现。

我的推文的重点是：如果您遇到的是人员问题，那么新的体系结构将无济于事。这只会延迟问题的影响。我认为微服务对许多人的吸引力是希望它将神奇地解决这些人的问题。

我的问题是：转移到微服务会带来运行时问题，这是什么意思？

那不是那些推文所说的！他们没有说过转向微服务，也没有说过制造问题。他们只说了解决问题的方法。

而且他们把上下文限制对他们的主张，即你的组织是不正常的。

因此，第一条推文基本上是在说两件事：

• “如果您的组织现在无法使用微服务来设计复杂的系统，那么它将无法神奇地使用微服务来设计复杂的系统”和
• “由这种无能引起的问题现在会在编译时（即在开发期间出现，然后在运行时（即在生产中）出现”（从技术上讲，它们也可能在测试期间出现，但请记住，引号本身就具有局限性）到功能失调的组织，这些组织可能具有不合格的测试制度）

在第二鸣叫说的事实，问题只体现在生产，即让客户看到他们，是一种功能，而不是一个错误，因为当客户抱怨，倾向于在不同的地方可以听到比当生成中断，即在能够解决组织功能障碍的地方（例如高层管理人员）。由于组织功能障碍通常是高级管理的失败，这意味着不满意的客户会对最终导致这种不满意的客户产生严重影响，而更高级别的管理失败所导致的代码质量低下通常只会对开发人员造成不良影响。但是，这并不是错误，也无法对此做任何事情。

因此，第一条推文说微服务将管理不善引起的问题从编译时（只有开发人员看到）转移到运行时（客户看到它们）。第二条推文说这是一件好事，因为那样的话，问题会伤害那些对此负责的人。

与编译时问题相反，它会产生运行时问题。

单片应用程序难于编译且昂贵。但是一旦编译完成，您就可以合理地确定组件之间不存在极其愚蠢的不兼容性，因为类型系统可以捕获它们。只有当两个特定的组件以特定的方式实际交互时，微伺服系统中的相同错误才会显示出来 。

在单片系统和微服务中，都必须定义子系统之间的接口。界面应设计合理，文档完善且尽可能稳定。这与OOP中的相同。

如果您的组织无法做到这一点，微服务也将无法解决问题。在微服务中，您具有公共Web界面。因此，您甚至必须花费更多的精力进行界面设计。

如果接口的设计不正确，则会遇到两种运行时问题：

1. 如果未正确使用该接口，则会在运行时（而不是在编译时）出现错误。
2. 调用Web界面的速度很慢，因此会出现性能问题。

我认为产生运行时问题不是将组织问题传达给负责人员的正确方法。