微服务将您的组织功能障碍从编译时问题转变为运行时问题。
该评论员扩展了问题说：
功能不存在错误。运行时问题=>产品问题=>向负责任的人员提供有关功能异常的更强，更快的反馈
现在，我可以通过微服务获得这些信息：
可能会增加吞吐量的延迟-这是生产和运行时的问题。
增加代码中可能存在运行时解析错误的“网络接口”数量。
可能会进行蓝绿色部署。接口不匹配可能会阻止这些故障（请参阅网络接口）。但是，如果蓝绿色的部署能够正常工作，那么它就更需要运行时关注。
我的问题是：转移到微服务会导致运行时问题吗？
#1 楼
我有个问题。让我们使用微服务！现在，我有13个分布式问题。将您的系统分为封装，内聚和解耦的组件是一个好主意。它使您可以分别解决不同的问题。但是您可以在单片部署中完美地做到这一点（请参阅Fowler：Microservice Premium）。毕竟，这是OOP几十年来一直在教的东西！如果您决定将组件转换为微服务，则不会获得任何架构优势。您将在技术选择方面获得一些灵活性，并且可能（但不一定！）获得一些可伸缩性。但是，由于（a）系统的分布式特性和（b）组件之间的通信，您一定会感到头疼。选择微服务意味着您还有其他一些迫切需要解决的问题，尽管有这些问题，您仍然愿意使用微服务。无法设计微服务系统。在整体代码库中，痛苦将非常明显。理想情况下，如果代码被严重破坏，将不会编译。但是对于微服务，每种服务都可以单独开发，甚至可以使用不同的语言。除非集成组件，否则组件交互中的任何问题都不会变得明显，到那时，修复整个体系结构为时已晚。
错误的第一大来源是接口不匹配。可能会出现明显的错误，例如缺少参数，或者更细微的示例，例如忘记检查错误代码，或者忘记在调用方法之前检查前提条件。静态类型可以在代码运行之前尽早检测到此类问题：在您的IDE和编译器中。动态系统没有这种奢侈。在执行错误的代码之前，它不会崩溃。
微服务的含义令人恐惧。微服务本质上是动态的。除非您使用正式的服务描述语言，否则您无法验证接口使用情况的任何正确性。您必须测试，测试，测试！但是测试很昂贵，而且通常不能穷举，这可能会导致生产中仍然存在问题。这个问题什么时候会变得明显？只有在运行时在生产中采用该错误路径时。除非您对数据丢失的可能性感到高兴，否则，生产问题会导致更快的反馈的想法是非常危险的错误。
评论
@JacquesB我有信心“组织功能障碍”是指无法开发系统。我的大部分回答是为了说明一个人如何得出这样的结论的背景，但这是我的专业意见，并非来自推文。
–阿蒙
17年1月1日于13:31
“整洁地分为组件的整体”-这到底是什么意思？
–user223083
17年1月1日在22:43
更不用说接口的版本控制（接口随时间变化）。
– Peter Mortensen
17年1月1日在23:17
@mobileink Monolith在这里不是一个理想的术语，因为它表示“无体系结构”。但是，与基于服务的体系结构（其中系统的各个部分可以独立部署）相比，我要传达的是一个作为单个系统开发和部署的系统。如果您有更好的用语，请编辑帖子……
–阿蒙
17年1月1日于23:55
@amon听到Monolith这个词并不能立即使人想到“没有建筑”的想法。大多数建筑都是巨型独石，埃及大金字塔以及许多其他物品也是。显然，它们是架构师，并作为一个整体交付。许多软件系统缺乏良好的体系结构。但是缺乏好的架构似乎与它们的部署方式无关。您可能会借用另一个项目的一些脚手架，并将其称为架构（3层，2层，n层，微服务等），但是这样做并不能保证您做得很好。
–埃德温·巴克（Edwin Buck）
17年1月3日在17:38
#2 楼
第一条推文是我的，所以我将在其上进行扩展：假设您有100个开发人员，正在开发一个整体应用程序。太多的人无法彼此有效地沟通，因此公司必须努力将他们分成较小的团队，并在他们之间建立良好的沟通模式。当组织处于“功能失调”状态时，团队可能不会互相交谈，他们没有达到更大的目标，他们在优先事项等方面意见不一致-结果，他们花了永远的时间来运送东西。从某种意义上说，功能异常在软件生产之前就很明显，这是一个“编译时问题”。该项目可能是一场致命的游行，或者永远都无法交付（“编译”）。 ，但是因为它允许他们忽略组织功能障碍。他们希望不要让100个开发人员结盟，而是希望他们可以有一些规模很小的团队，每个团队都专注于自己的微型服务。如果您处于这样一个功能失调的组织中，那么它会如此吸引人：它给您更大的权限，可以避免您不喜欢的人，不进行交流。
不幸的是，这成为一个“运行时问题”，因为一旦软件在生产中运行，良好的通信就变得同样重要。与组织有关的问题-团队以及他们如何保持协调和沟通-在“运行时”体现出来。不会帮助。这只会延迟问题的影响。我认为微服务对许多人的吸引力是希望它将神奇地解决这些人的问题。
评论
+1。作为Stack Exchange的答案，这比发送Tweet的要好得多。 :-)
–ruakh
17年1月1日在23:31
实际上，对于任何动态系统而言都是如此。动态键入非常有用，但前提是您拥有合适的人员。 “自由格式数据库”非常有用，但前提是您拥有合适的人员。如果您没有合适的人，那么您只是委派问题，而不是解决问题。
–罗安
17年1月2日，9：49
我认为这是一个重言式。当人们遇到问题时，问题就会无处不在。我无法想象没有适当的集成测试就可以交付作为一组微服务运行的解决方案。在这种情况下，无法提供支持工作流程的解决方案。如果有人在进行微服务时没有进行流量测试，尤其是为了隐藏问题，那就是问题所在。也许还可以运送未经测试/破损的二进制文件。它从更高级别的士兵级别的程序员那里提出了这个问题。
–luk32
17年1月2日在16:18
@ luk32在某种程度上，是的，但是使微服务对坏团队具有吸引力的要点是，使您的技能和沟通不足会在很长一段时间内不被察觉。问题有无与否无关，而是问题何时出现
– T. Sar
17年1月2日在17:45
很好的答案。感谢您确认我对Twitter的看法，除了引起人们的注意之外，它对任何事情都完全没有用。
–罗伯特·哈维（Robert Harvey）
17年1月2日，18：26
#3 楼
我的问题是：转向微服务会导致运行时问题吗？
那不是那些推文所说的！他们没有说过转向微服务，也没有说过制造问题。他们只是说一些有关转移问题的东西。
，他们在声明中施加了上下文限制，即您的组织功能失调。
所以，第一条推文基本上是在说什么有两件事：
“如果您的组织现在没有微服务就无法设计复杂的系统，那么它将无法神奇地使用微服务来设计复杂的系统”和
”由这种无能导致的问题，这些问题现在在编译时即开发时出现，然后在运行时即在生产中出现（从技术上讲，它们也可能在测试中出现，但是请记住，引号将其自身限制为功能失调的组织，可能具有不合标准的测试制度）
第二条推文说，问题只是在生产中表现出来（即客户看到问题的地方）是一个事实，而不是错误。 ，因为当客户抱怨时，往往会听到不同的声音而不是在构建中断时（即在能够解决组织功能异常的地方）（例如高级管理）。由于组织功能障碍通常是高层管理人员的失误，这意味着不满意的客户会对最终导致客户不满意的人员产生严重影响，而高层管理人员失误导致的代码质量低下通常只会对开发人员造成严重影响。但是，这并不是错误，无法对此做任何事情。
因此，第一条推文说微服务将不良管理引起的问题从编译时（只有开发人员看到）转移到运行时（客户看到它们）。第二条推文说这是一件好事，因为那样的话，问题就会伤害到那些对此负责的人。
评论
@Michael如果看不到它们如何影响代码质量，则可以考虑管理层对他们业务创造的产品质量的任何部分（如果有）的影响。
– wjl
17年1月1日在17:13
@Michael：一切最终都是由高层管理人员引起的。代码质量低是否由不可能的期限引起？谁设定这些期限？谁告诉那些设定截止日期的人设定那些截止时间？不称职的开发人员会导致代码质量低下吗？谁雇用了那些不称职的开发人员？谁雇用了那些没有能力的开发商？是由于工具不足引起的吗？谁购买这些工具？谁批准购买这些工具的预算？这是由愚蠢的架构引起的吗？谁雇用建筑师？谁负责他？这些推文特别针对……
–Jörg W Mittag
17年1月1日在17:22
……组织功能障碍。好吧，使组织职能几乎是高层管理的工作。这就是管理。
–Jörg W Mittag
17年1月1日在17:22
尽管从长远来看可能会起作用，但通过使问题影响客户来解决公司问题的想法似乎并不正确。
– Stijn de Witt
17年1月2日在21:48
@JörgWMittag我认为声称由不良开发人员编写的不良代码是雇用这些不良开发人员而不是不良开发人员本身的人的错是不合理的。最终可能是管理的责任，但这是由开发人员引起的。
–Miles Rout
17年1月3日在23:42
#4 楼
它会产生一个运行时问题，而不是编译时问题。单片应用程序很难编译且编译成本很高。但是一旦编译完成，您就可以合理地确定组件之间不存在极其愚蠢的不兼容性，因为类型系统可以捕获它们。直到两个特定的组成部分以特定的方式实际相互作用，微服务系统中的相同错误才会出现。
评论
这似乎假设“整体”应用程序始终是静态类型的。动态类型的语言呢？静态类型的服务接口又如何呢？
–雅克B
17年1月1日在12:39
@JacquesB OTOH，我可以想到完全为零的动态类型的编译语言。
–user253751
17年1月1日于13:39
@JacquesB未编译JavaScript和Python。除非您将内部解释器结构视为编译目标，否则将编译每种语言。
–user253751
17年1月1日于13:45
@immibis：每个当前存在的ECMAScript实现都有至少一个编译器。例如，V8有两个编译器和正好为零的解释器，它从不解释，总是编译为二进制本机代码。我相信SpiderMonkey有四个编译器和一个解释器，但是该解释器无法解释ECMAScript。 SpiderMonkey从不解释ECMAScript，它总是先将其编译为SpiderMonkey字节码，然后再将其编译为二进制本机代码。当前所有现有的Python，Ruby和PHP实现都具有编译器。
–Jörg W Mittag
17年1月1日17:26
@LieRyan如果您认为类型推断与动态类型相同和/或Haskell是动态类型，则您会感到非常困惑。
–德里克·埃尔金斯离开东南
17年1月1日在20:36
#5 楼
在单片系统和微服务中，都必须定义子系统之间的接口。界面应设计合理，文档完善且尽可能稳定。这与OOP中的相同。如果您的组织无法做到这一点，微服务也将无法解决问题。在微服务中，您具有公共Web界面。因此，您甚至还需要在界面设计上花费更多的精力。
如果界面设计不正确，则会遇到两种运行时问题：接口使用不正确，会在运行时（而不是在编译时）出错。
调用Web接口的速度很慢，因此会遇到性能问题。
我认为生成运行时问题不是与负责任的人沟通组织问题的正确方法。
评论
如果A在一个单一的情况下与B交谈，则至少实际接口可以被证明是兼容的（通过静态键入），这使它更有可能也是正确的。通常，微服务在不进行编译时间检查的情况下通过某种东西进行通信如果您正在研究涉及使用微服务的问题，那么Fowler的文章是必读的。martinfowler.com/ articles / microservices.html我相信，这不仅仅是@Richard Tingle所说的编译时间与运行时间的情况。而且，我并不完全同意生产问题要好于开发问题。但是微服务可能会以其他方式帮助扩展大型项目。 （对于大多数小型项目来说，这是一个过大的杀伤力）
那位评论员是短视的。运行时问题=>产品问题=>用户不满意=>赔钱。
@Philipp：这就是重点。由组织功能障碍引起的编译时问题=>没人关心。由组织功能障碍引起的金钱损失=>确切地伤害了负责组织功能障碍的人。希望：组织功能障碍更快得到解决。