通过部署同一个服务的多个实例来获得系统的伸缩性，这是微服务的优点之一。不过，大多数过早采用微服务的公司却在这些微服务背后使用了同一个存储系统。

也就是说，这些服务具备了伸缩性，但整个应用并不具备伸缩性。如果你正打算使用这样的伸缩方式，那为什么不直接在负载均衡器后面部署多个单体实例呢？你可以以更简单的方式达到相同的目的。再者，水平伸缩应该被作为杀手锏来使用。你首先要关注的应该是如何提升应用程序的性能。一些简单的优化常常能带来数百倍的性能提升，这里也包括如何正确地使用其他服务。例如，我在一篇博文里提到的 Redis 性能诊断（文末有链接）。

我们为微服务做好准备了吗？

在讨论架构选型时，人们经常会忽略这个问题，但其他却是最重要的。高级技术人员在了解了开发人员或业务人员的抱怨或痛点之后，开奖，开始在网上找寻找解决方案，他们总是宣称能解决这些问题。但在这些信誓旦旦的观点背后，有很多需要注意的地方。微服务有利也有弊。如果你的企业足够成熟，并且具有一定的技术积累，那么采用微服务所面临的挑战会小很多，并且能够带来更多正面好处。那么怎样才算已经为微服务做好准备了呢？Martin Fowler 在多年前表达了他对微服务先决条件的看法，但是从我的经验来看，大多数成长型初创公司完全忽略了他的观点。Martin 的观点是一个很好的切入点，让我们来逐个说明。

我敢说，大部分成长型初创公司几乎连一个先决条件都无法满足，更不用说满足所有的条件了。如果你的技术团队不具备快速配置、部署和监控能力，那么在迁移到微服务前必须先获得这些能力。接下来让我们更详细地讨论这些先决条件。

1. 快速配置

如果你的开发团队里只有少数几个人可以配置新服务、虚拟环境或其它配套设施，那说明你们还没有为微服务做好准备。你的每个团队里都应该要有几个这样的人，他们具备了配置基础设施和部署服务的能力，而且不需要求助于外部。要注意，光是有一个 DevOps 团队并不意味着你在实施 DevOps，开发人员应该参与管理与应用程序相关的组件，包括基础设施。

类似的，如果你没有灵活的基础设施（易于伸缩并且可以由团队里的不同人员来管理）来支撑当前的架构，那么在迁移到微服务前必须先解决这个问题。你当然可以在裸机上运行微服务，以更低的成本获得出众的性能，但在服务的运维和部署方面也必须具备灵活性。

2. 基本的监控

如果你不曾对你的单体应用进行过性能监控，那么在迁移到微服务时，你的日子会很难过。你需要熟悉系统级别的度量指标（比如 CPU 和内存）、应用级别的度量指标（比如端点的请求延迟或端点的错误）和业务级别的度量指标（比如每秒事务数或每秒收益），这样才可以更好地理解系统的性能。在性能方面，微服务生态系统比单体系统要复杂得多，就更不用提诊断问题的复杂性了。你可以搭建一个监控系统（如 Prometheus），在将单体应用拆分成微服务之前对应用做一些增强，以便进行监控。

3. 快速部署

如果你的单体系统没有一个很好的持续集成流程和部署系统，那么要集成和部署好你的微服务几乎是件不可能的事。想象一下这样的场景：10 个团队和 100 个服务，它们都需要进行手动测试和部署，然后再将这些工作与测试和部署一个单体所需要的工作进行对比。100 个服务会出现多少种问题？而单体系统呢？这些先决条件很好地说明了微服务的复杂性。

Phil Calcado 在 Fowler 的先决条件清单里添加了一些东西，不过我认为它们更像是重要的扩展，而不是真正的先决条件。

如果我们具备了这些先决条件呢？

就算具备了这些条件，仍然需要注意微服务的负面因素，确保微服务能够为你的业务带来真正的帮助。事实上，很多技术人员对微服务中存在的分布式计算谬论视而不见，但为了确保能够成功，这些问题是必须要考虑到的。对于大部分成长型初创公司来说，基于各种原因，他们应该避免使用微服务。

1. 运营成本的增加

快速部署这一先决条件已经涵盖了一部分成本，除此之外，对微服务进行容器化（可能使用 Docker）和使用容器编排系统（比如 Kubernetes）也需要耗费很多成本。Docker 和 Kubernetes 都是很优秀的技术，但是对于大部分成长型初创公司来说，它们都是一种负担。我见过初创公司使用 rsync 作为部署和编排工具，我也见过很多的初创公司陷入运维工具的复杂性泥潭里，他们因此浪费了很多时间，而这些时间本来可以用于为用户开发更多的功能。

2. 你的应用会被拖慢