作为一个程序员，你真的需要微服务吗？

前言

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

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

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

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

什么是单体应用和微服务

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

这真的是一个新事物吗，或者这只是一个具有时髦名字的面向服务体架构（SOA)? 我们不会在这里进行辩论，毕竟你可以到 Slashdot 和 Hacker News 上讨论这个问题。不过，我们要说的是，微服务方法 ( 或者随便你怎么称呼它 ) 主要对大型组织有益。这是因为非常大的应用程序可以被分割成几个不同的服务，每个服务由各自独立的开发团队管理。

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

你真的需要微服务

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

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

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

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

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

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

例外情况（混合的方式）

有时候微服务是合适的，但是根据我的经验，在这些情况下，可伸碧备哪缩性需求或容错需求超过了必须设计和管理分布式系统的缺点。这里的一个很好的例子是像 Monzo Bank 这样的企业应用，它既需要能够立即按需求进行伸缩，又需要能够确保系统某个区域的故障不会影响悔码到另一个区域 .

我们在 Browser 中多次重复的一个好方法是采用混合方法进行系统设计。这涉及到一个由支持微服务包围的中心整体，但只有在有充分理由的情况下才会如此。例如，我们最近在将 NLP 处理集成 到应用程序中时使用了这种方法。

我们已经构建了几个系统，其中核心业务应用程序作为一个整体构建 ( 通常在 Symfony 中 )，由独立的微服务管道处理繁重的数据处理。这不仅允许我们在不影响核心应用程序性能的情况下处理大量数据量，而且如果需要，我们可以在不影响平台的日常 *** 作前提下，将这些组件下线。

理想情况下，你能够清楚地理解规模和未来的开发需求，这对于决定体系结构非常重要。你想快速进入市场吗？您想要支持数百万滚好用户吗？您是否需要处理 大量的数据流 。

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

微服务架构对于程序员来说是需要掌握的新型技术之一，而其受到追捧的原因就是符合互联网的发展以及其便捷性。今天我们就一起来了解一下，微服务架构带来的变化。

微服务架构给IT系统和团队带来了以下显著的变化：

基础设施的升级，需要引入虚拟化(如Docker)，现存基础设施也需要与之进行适配

系统架构的升级，需要引入服务注册(如Consul)，服务间的交互方式也需要与之进行适配

运维平台的升级，建议引入日志收集(如Fluentd)，分布式跟踪(如Zipkin)和仪表盘(如Vizceral/Grafana)等

运维效率和自动化水平的提升帆竖也迫在眉睫，否则无法应对实例数量，变更频率，系统复杂度的快速增长

观念的转变，基础设施，系统架构和运维平台等的大幅升级，犹如小米加步q换成飞败昌机大炮，相应的战略战术也需要与之相适配才行。

微服务架构下用户面临的监控问题

在转型到微服务架构以后，用户在监控方面主要会面临以下问题。

监控配置的维护成本增加。某个在线系统大概有106个模块，每个模块都需要添加端口监控，进程监控，日志监控和自定义监控不同服务的监控指标，聚合指标，报警阈值，报警依赖，报警接收人，策略级别，处理预案和备注说明也不完全相同如此多的内容，如何确保是否有效，是否生效，是否完整无遗漏。

当前针对维护成本，业界常用的几种方法有：

通过变量的方式尽量减少人工输入

通过监控配置文件解析做一些可标准化的校验

通察轿扒过故障演练验证报警是否符合预期

其次，三方依赖越来越多。昭通电脑培训http://www.kmbdqn.cn/发现例如Docker的可靠性很大程度上取决于宿主机，如果所在的宿主机发生资源争用，网络异常，硬件故障，修改内核参数， *** 作系统补丁升级等，都可能会让Docker莫名其妙地中招。

这个问题已经收藏了一个多月了，一直在考虑如何回答这个问题，总结了很长时间终于有了一些感悟（之前一直都是只可意会不可言传的感觉），和大家分享一下，如果有不同的建议，欢迎大家留言指正。

分布式和微服务

首先，我认为微服务就是分布式框架的一种。

分布式的思想就是把一个系统的不同模块，部署在不同的服务器上，以应对高并发的问题。

SOA是一种分布式拦物架构，把业务系统分成多个子系统，提供不同的服务，再通过服务组合、编排实现业务流程；通常在SOA架构中，ESB企业服务总线扮演了重要的角色。

微服务是SOA的升华，如果非要说点儿不同的，那么微服务更加强调服务的细分和专业，去ESB总线、去中心化，部署粒度更细，服务扩展更灵活。

微服务不只是技术架构

很多同学一说微服务，就说这是一种技术架构，有的推荐使用Dubbo，有的推荐使用SpringCloud。

我认为，微服务不单单是一种睁源技术架构，也涉及到了管理、组织架构。

大多数的公司，需求、开发、测试、运维都是独立的团队，这实际上是有悖于微服务快速迭代的思想；在微服务的架构下，一个服务应该是由一个团队全权负责的简早液。

不过组织架构方面的事情，真的不是我们能说了算的。

必须要用微服务？

我觉得没有必要为了微服务，而微服务；有的公司把服务拆分，但是数据库依然是同一个库，依然是一个项目直接掉另外一个项目的接口，然后对外就宣称完成了微服务的改造...

架构设计还是要根据需求背景、团队开发能力、软硬件实力综合来考虑。

好的架构是可以进化的，而不是一步到位建成的。

我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。

---