原文：
towardsdatascience.com/no-you-dont-need-a-new-microservices-architecture-f0dbda673bae
如果你感觉 AI 生成的文章图片实际上很好地捕捉了你公司的系统架构，那么这篇文章就是为你准备的。
毫无疑问，将复杂任务分解成更小的、可管理的子任务对于任何类型的问题解决都是有帮助的。这也适用于数字化我们业务流程的 IT 系统。因此，架构师遵循了在 IT 中经过验证的“分而治之”的方法，将我们的系统划分为更小的应用程序/服务，以执行不同业务领域的特定任务。
随着我们企业的日益复杂化，代表数字化业务流程的相互连接的应用程序/服务系统也变得过于复杂。因此，我们一直在努力保持秩序和结构，以免整个混乱崩溃并完全停止工作——这就是所谓的企业架构，如果你曾经好奇那些在象牙塔里的人试图通过他们的架构组件图实现什么的话。
企业架构
关于在数字化公司的整体任务分散在整个企业时，如何驯服或预防混乱的正确架构，已经有很多论述。
你可以找到像*The Open Group Architecture Framework (TOGAF)这样的全面框架，它解释了所有可能与你有效建模企业架构相关的内容。还有关于在架构应用程序时应该遵循的正确设计模式的详细描述。企业应用集成 (EAI)定义了企业集成模式，有助于重新整合由孤立应用程序引起的分散信息。而领域驱动设计 (DDD)*甚至教会了我们如何防止隔离一开始就发生。
专门的企业数据架构学科也出现了，提供了越来越多的风格和方法来驯服公司中的数据混乱。这里不再详细说明，但詹姆斯·塞拉（James Serra）已经做出了巨大的努力，来解读今天企业中发现的架构数据。
尽管有这么多框架、开发模式、最佳实践以及来自应用程序和数据专家的大量建议，我们仍然难以创建和维护一个良好的企业架构。我现在有一种印象，关于如何正确行事的大量好建议往往会导致进一步的混乱。
因此，我们一直在寻找下一个改进的、更加全面甚至可能是最终的关于如何最好地组织我们的 IT 系统的建议。
企业级微服务架构？
最近的（或者说现代）方法是微服务架构，它还可以无缝扩展到云端。允许混合使用云服务肯定也是企业架构师必须解决的长期挑战之一。
那么，我们就尽快处理这种现代风格，好吗？
嗯，即使是这样的现代应用架构，我们也已经发现了需要避免的反模式和陷阱——例如，著名的架构老将马克·理查兹收集了这方面的良好建议。
这并不奇怪，因为我们已经为我们的企业架构提供的所有丰富建议同样适用于微服务架构。我甚至可以说，大多数大型公司已经实施了一种某种形式的微服务架构，尽管他们可能没有明确意识到这一点或称之为那样。
我这句话是什么意思？
所有通过企业网络相互连接的不同应用程序、服务和平台实际上可以被视为微服务架构。然而，由于所有这些脆弱且低效的组件交互、扩展问题和维护问题，它是一种相当薄弱且有些混乱的实现方式。
让我们通过关注微服务架构的核心原则来提炼其精髓，以帮助我们认识到我这句话的有效性。
独立部署性为了确保独立部署性，我们需要应用程序/服务尽可能地松散耦合，以便在更改一个应用程序/服务时不会影响其他应用程序/服务。这当然也是我们企业的一个主要目标。毕竟，这是决定在整个企业范围内分散应用程序开发的关键驱动因素。
围绕业务领域建模的一切DDD 框架教导我们如何组织代码和组件，以更好地满足业务领域的需求。这也是适用于微服务架构之外的一般性建议。它已被接受为允许解耦应用程序/服务以实现独立部署的最佳方式。传统的分层架构不再是建议的企业架构结构方式。
无共享状态意识到单个共享数据库无法扩展到企业层面这一事实也并非新鲜事，也不是微服务架构所特有的。对于企业级应用来说，决定哪些数据是共享的，哪些是隐藏的或私有的同样重要。这也允许减少不必要的耦合，并促进独立部署性。
服务的小规模“服务应该有多小？”无疑是围绕微服务架构最常问的问题之一。然而，即使是微服务架构的传道者也同意，服务的实际规模是最不重要的方面。有些人甚至认为，只有接口的大小，而不是服务本身的大小才是相关的。但除了这个问题，每个人都同意大小是相对的，服务的“正确”大小需要随着时间的推移来发展。它不能在代码行数或其他复杂度度量中预先定义。公司中可能仍然存在大型单体应用程序，但从企业全局视角来看，即使是这样的单体应用程序也可能具有满足微服务架构描述的其他核心概念的正确规模。
适应变化和演化的灵活性这是维持成功企业架构的最基本要素。演进的软件架构允许不断将每个新的创新整合到整体软件生态系统中。它足够灵活，足以在每次实施变化时在系统中保持正确的平衡。再次强调，你可以在构建演进式架构中找到来自知名软件架构专家的丰富建议。这些建议对企业和微服务架构都是有效的，并不局限于微服务架构。
因此，关键问题不是微服务架构是否适合我们的组织。在企业级别，没有正确或错误的架构，而是需要做出许多权衡。
微服务架构的核心概念实际上与我们已经学习到的在企业级别维护清晰架构的一切都是一致的。微服务方法中并没有真正的新东西。即使是那些试图标准化实施的平台的出现——Kubernetes 是最突出的一个——也不会革命性地改变我们的企业架构。这只是市场上某个有影响力的供应商推广的另一个平台。这只是供应商打算卖给我们以解决我们所有架构挑战的另一个新产品。
将这种所谓的革命性平台集成到企业架构中的典型方法是大型的灯塔项目。这些项目规模大、成本高，但很少足够全面，可以取代当前生态系统的实质性部分。相反，它们只是通过创造新的技术孤岛进一步复杂化问题。
我已经写过了大型公司试图购买数据平台并将它们像乐高积木一样组装起来，希望实现下一个重大飞跃的遗憾做法。
这根本不适合数据平台或应用平台！
随着时间推移架构原则的演变应该让我们意识到，没有简单的一劳永逸的方法。虽然今天的观点认为微服务是企业级的一个有希望的架构方法，但它将暴露出更多的弱点，并触发需要避免的另一套陷阱和反模式。
关键的收获是，没有任何单一的产品、平台或新的架构风格可以完全取代我们适合我们目的的互联应用企业生态系统。我们可以根据合理的架构原则改变和演进企业系统，但我们不能仅仅购买一个新的企业架构，也不能完全用一种新的方法来替换它。因此，你不需要一个新的微服务架构，而是应该演进你当前的企业架构，以更好地支持列出的核心概念。
还可以参考关于通用数据供应的文章，其中包含我对如何无缝（重新）集成应用架构与数据架构的建议。
