我最喜欢博客（而且从来没有得到足够的）的一件事就是反馈。我之前发表的文章“雕刻它 - 微服务，巨石和康威定律”，产生了一些评论/讨论，这些评论/讨论合在一起，保证了一个后续帖子。
其中一个讨论是与Ruth Malan和Jeff Sussna就治理进行的Twitter交流。杰夫认为分权治理的概念是“有争议的”，尽管他认为集权治理是“有问题的”和“僵化”。露丝观察到“或者至少是一个权衡轴和（组织）设计......？ （甚至“联邦”也有广泛的解释）“。我为一些集中治理的需要辩护，但是克制，注意“管理比必要更深的会导致问题，例如：问题是BDUF（IMO）是B，而不是UF“。
当应用程序跨越多个团队，所有团队都独立部署时，将需要一些集中式治理。关键是制定道路规则，允许团队独立工作而不会相互干扰，不会尝试微观管理。这种编排需求不仅仅局限于技术方面。正如Tom Cagley在我上一篇文章中的评论所指出的那样“在考虑跨团队和组织边界的流程改进时，也可以利用你的论点”。团队之间冲突的流程模型很容易使分布式解决方案复杂化。
另一篇关于“雕刻它 - 微服务，巨石和康威定律”的评论，这一次来自Robert Tanenbaum，讨论了重用，并质疑图书馆在某些情况下是否是更好的选择。 Robert还观察到“敏捷原则告诉我们实现满足需求的最小体系结构，只有在需求超出最小实现时才能使用更复杂的体系结构”。我认为微服务和SOA架构更像是一种分区机制而不是重用工具。因为重复使用会带来更多的成本和负担，而不是大多数人认为，我倾向于不那么热衷于这方面。但是，我绝对同意，分布式架构可能更适合于演进过程的后续步骤，而不是起点。来自Chris Richardson的“微服务：分解应用程序的可部署性和可伸缩性”的引用很好地说明了（重点是我的）：
使用微服务架构的另一个挑战是决定在应用程序生命周期的哪个阶段应该使用这种架构。 在开发应用程序的第一个版本时，您通常不会遇到此体系结构解决的问题。 此外，使用精心设计的分布式架构将减缓开发速度。
Michael Brunton-Spall的“什么是微服务及其重要性”为这种架构风格所涉及的权衡性质提供了更多背景：
微服务交易复杂的单块，用于简单服务的复杂交互系统。
一个巨大的整体可能是如此复杂，以至于很难对某些行为进行推理，但在技术上可以推理它。相互交互的简单服务将表现出紧急行为，而这些行为是不可能完全推理的。
对于复杂系统而言，级联故障更是一个问题，一个简单系统中的故障会导致其他系统出现故障。幸运的是，有一些模式，例如背压，死人的开关等等，可以帮助你减轻这种情况，但你需要考虑这一点。
最后，即使问题发生变化，微服务也可以成为解决问题的解决方案。因此，一旦构建，如果您的需求发生变化以使您的有界上下文调整，正确的解决方案可能是抛出两个当前服务并创建三个来替换它们，但通常更容易简单地尝试修改其中一个或两个。这意味着微服务可以很容易地在较小的情况下进行更改，但需要更多的监督才能在大的情况下进行更改。
引号中“复杂(complicated)”和“复杂(complex)”之间的区别尤为重要。所提到的紧急行为意味着复杂系统的行为只能在回顾中完全解释。这意味着分布式应用程序不能被视为具有部件之间空间的整体件，但必须根据其性质进行设计。这是Jeppe Cramon的一个主要主题，他在TigerTeam网站上围绕微服务的持续工作非常值得一读。
Jeppe在我的帖子的LinkedIn讨论中发表了一对评论。在那次讨论中，Jeppe指出，专注于业务能力的小型服务比整体服务更可取，但这与将几个巨型网络与Web服务连接起来并不相同。然而，主要关注的是服务“拥有”的数据的性质。我在上一篇文章中非常简短地提到了这一点，并提到需要权威性的一些概念（中央治理）。 Jeppe表示赞同，并指出整体结构导致多主数据架构，其中多个系统在同一实体上包含冗余的，可能相互冲突的数据。
底线？在我看来，这种架构风格具有增强企业运营的巨大潜力，前提是它没有过度营销（“SOA治愈秃头，肠易激综合症，促进世界和平......免费!!!”）。服务并不是将遗留系统毫不费力地转变为二十二世纪技术的秘诀。有一些警告，权衡和成本。一种务实的方法，考虑到这些以及潜在的好处，应该比昨天的“如果建立它和他就会来”的哲学更有可能取得成功。
