你真的需要微服务吗？

去年发布的 Symfony 4 代表了该框架的重点逐渐变化 ; 这变化体现在其远离单体架构和向 微服务 靠拢，这种变化背后的方法论在过去几年中越来越受欢迎。

为了说明这一转变，新版本在默认情况下使用了微内核(micro by default), Symfony 组织大力宣传其新的微内核设计，声称与 Symfony 3 相比，编写应用程序所需的代码减少了 70%。

除了这些优点外，这一变化意味着运行单个应用程序的开销要小得多，这使得 Symfony 对于微服务体系结构的使用更具吸引力。

什么是单体应用和微服务

微服务设计基于将大型传统(单体)应用程序拆分为几个小型、不同的应用程序的概念。这些应用程序将处理单个业务功能领域，并与其他组件协作，就像它们是第三方应用程序一个新事物吗，或者这只是一个具有时髦名字的面向服务体架构(SOA)? 我们不会在这里进行辩论，毕竟你可以到 Slashdot 和 Hacker News 上讨论这个问题。不过，我们要说的是，微服务方法 ( 或者随便你怎么称呼它 ) 主要对大型组织有益。这是因为非常大的应用程序可以被分割成几个不同的服务，每个服务由各自独立的开发团队管理。

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

你真的需要微服务

我的观点是，除非你在 Google 或 Netflix 等拥有数百名软件开发人员的公司工作，否则你可能不需要微服务。事实上，对于大多数中小型企业来说，采用这种设计可能非常不合适。

我将会讲到一些例外，但是微服务的开发和维护成本是很多人都注意到的却又很少谈及的问题。我们可以用一个简单的问题来决定是否适合把微服务作为你的起点 : (译者注：这句子的原文中有个词语叫 房间里的大象 ，是指所有人都注意到却又不被提及的问题)

你系统中的某个组件(例如用户管理)是否足够复杂，以致于需要多个开发人员全职进行持续开发?

如果答案是否定的，那么微服务方法可能会浪费您的时间和金钱。相反，如果你足够幸运，能够在以后达到这个规模，你可能就可以慢慢地把那些需要多人开发的部分分离出来。

为什么微服务在开发和运维上开销更大

由于您不需要处理大量的分布式系统问题，因此单体应用程序通常是一个开销更少的方案。使用像 Symfony 这样的单体框架所通过提供开箱即用的集成特性提供了许多好处，这些特性可以方便地从应用程序的所有区域访问。你基本上可以避免处理以下的这些问题 :

• 分布式系统上的身份验证和授权
• 跟踪多个独立系统上的复杂事务
• 分布式锁
• 服务间的通信
• 多个应用程序上的额外配置管理

例外情况(混合的方式)

有时候微服务是合适的，但是根据我的经验，在这些情况下，可伸

（编辑：唐山站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!