你真的需要微服务?

• 原文

我们已经设计和构建了十多年的软件，大部分时间我们一直在使用优秀的 Symfony 框架来实现这一目标。Symfony 是一个传统的 PHP 组件集，受Java Spring的启发，我们发现它非常适合作为我们的企业Web应用程序和数字产品的快速开发。

然而，去年发布的 Symfony 4 代表了该框架的重点逐渐变化; 趋向于微服务方法，这种方法在过去几年中越来越受欢迎。

为了说明这种转变，新版本宣称“微服务优先”，Symfony基金会谈论其新的微内核设计，声称与Symfony 3相比，启动应用程序需要的代码减少70％。

除了其他优点之外，这种变化意味着运行单个应用程序的开销要小得多，这使得Symfony在微服务架构中的使用更具吸引力。

什么是单服务和微服务？

微服务设计基于将大型传统（单片）应用程序分成几个小而不同的应用程序的概念。这些应用程序中的每一个都将处理单个业务功能区域，并与其他组件协作，就好像它们是第三方应用程序一样。

这真的是一个新事物? 还是仅仅是具有现代名称的面向服务架构(SOA)？好吧，我们不会在这里进行辩论 - 毕竟Slashdot和Hacker News可以很好地处理这个问题。我们要说的是，微服务方法（或任何你想称之为的方法）主要对大型组织有益。这是因为非常大的应用程序可以分成几个不同的服务，每个服务由他们自己独立的开发团队管理。

微服务架构的另一个好处是允许灵活扩展一个特定组件的容量，而不是整个应用程序。这非常适合弹性云计算领域，但在大多数情况下，我认为这种效率提升会被一个巨大而明显的问题所淹没。

你真的需要微服务吗？

我认为除非你为Google或Netflix等公司工作，否则你可能不需要微服务。事实上，对于大多数中小型企业而言，采用这种设计路线可能是不合适的。

我会遇到例外，但显然的问题是这种方法的开发和维护成本。我们可以通过一个简单的问题来广泛地确定微服务是否应该是您的起点：

** “系统的单个组件，例如用户管理，其工作量是否要求超过一个开发人员持续全职开发？”**

如果答案是否定的，那么微服务方法可能会浪费你的时间和金钱。相反，如果你足够幸运能够在以后达到这个规模，你可能会负担得起慢慢拆分这些重量级组件。

为什么微服务的开发和管理成本更高？

单片应用程序通常是一个便宜得多的命题，因为您不需要处理大量的分布式系统问题。使用Symfony等框架的Monolith通过提供开箱即用的集成功能提供了许多好处，这些功能随后可以从应用程序的所有区域轻松访问。您几乎可以避免处理以下问题：

• 分布式系统上的身份验证和授权。
• 通过多个独立系统跟踪事务中的复杂问题。
• 分布式锁定
• 服务之间的通讯
• 多个应用程序的附加配置管理

规则的例外（又称混合方法）

有时微服务是合适的，但根据我的经验，这些情况下扩展要求或容错要求超过了必须设计和管理分布式系统的缺点。这里的一个很好的例子是像Monzo Bank这样的企业，他们需要能够立即扩展到需求，并且还能够确保系统某个区域的故障不会影响另一个区域。

我们浏览器重复多次的一个好方法是采用混合方法进行系统设计。这涉及一个由支撑微服务包围的中央服务，但只有在它们有充分理由存在的地方。例如，我们最近在将NLP处理集成到应用程序时使用了这种方法。

我们已经构建了几个系统，其中核心业务应用程序构建为整体（通常在Symfony中），大量数据处理由单独的微服务管道处理。这使我们不仅可以在不影响核心应用程序性能的情况下处理海量数据，而且可以在需要时使这些组件脱机，而不会影响平台的日常运营。

一种经过深思熟虑的方法 - 理想情况下是对规模和未来发展要求的清晰理解 - 对于制定建筑决策至关重要。你想快速上市吗？您想支持数百万用户吗？您需要处理大量数据吗？

尽早做出正确的决定可以使您的产品在最短的时间内获得投资回报的最高机会，而不会妨碍您希望将来探索的选项。计划稍后将组件分成微服务通常更具成本效益，而不是在最初的MVP开发中。

关于浏览器

我们为更好，更高效的工作场所创建企业Web应用程序。我们帮助壳牌，英国航空和英国政府等客户提高了效率并简化了业务。访问浏览器伦敦。
最初于2019年7月1日在https://www.browserlondon.com上发布。