什么时候微服务不是一个好的选择

我们花了很长时间来探索微服务架构的潜在优势。但是在某些场景下，我一点都不建议使用微服务。现在让我们来看一下不建议使用微服务的几种场景。

不清楚业务领域时

错误地定义服务边界的代价很高。错误的服务边界可能导致大量的跨服务更改，过于耦合的组件，并且通常而言情况会比单体系统还要糟糕。 在“Building Microservices”一书中，我分享了ThoughtWorks公司的SnapCI^译注1团队的经验。尽管他们对CI（持续集成）领域非常了解，但他们最初为托管CI解决方案而尝试的服务边界并不正确。这带来了很大的变更成本和管理成本。经过几个月的鏖战，该团队决定将服务合并回一个大应用程序。后来，当应用程序的功能集有所稳定并且团队对CI领域有了更深入的了解时，找到那些稳定的边界就变得容易了。

SnapCI是一个CI/CD的托管工具。该团队以前曾开发过另一个类似的工具Go-CD。Go-CD是一个开源的，可以在本地部署而不是云端托管的CD（持续交付）工具。尽管在SnapCI项目的早期，SnapCI和Go-CD项目之间有一些代码复用，但最终SnapCI变成了一个全新的代码库。尽管如此，该团队在CD工具领域的经验使他们有信心地、更快地确定服务边界，并将系统构建为一组微服务。

然而，几个月后，事情变的明朗起来：SnapCI的使用场景（use cases）和之前想的有所不同，以至于最初对服务边界的划分并不完全正确。这导致了大量的跨服务更改，并带来较高的更改成本。最终，该团队将服务合并回一个单体系统，使他们可以有时间更好地了解边界应该在何处。一年后，该团队便有能力把单体系统拆分为微服务。事实证明，这次拆分的微服务的边界更加稳定。SnapCI的例子还远不是我所看到的过早拆分的唯一例子。过早地将系统拆分为微服务可能会付出高昂的代价，尤其是当我们还是该领域的新手时。在许多方面，拥有要拆分为微服务的现有代码库比尝试从一开始就使用微服务要容易得多。

如果我们认为，我们对自己的领域尚未做到了如指掌，那么在进行系统拆分之前先深入了解业务可能是个好主意。（这是进行领域建模的另一个原因，我们稍后将会讨论。）

初创企业

很多因使用微服务而闻名的公司都被认为是初创企业^译注2，因此初创企业不适合使用微服务这个观点看起来是有争议的。但实际上，这些初创企业——包括Netflix，Airbnb等——都只是在其发展的后期才转向微服务架构。微服务对于“规模企业”^译注3而言可能是一个不错的选择，因为初创企业至少已经建立了产品/市场适应性的基础，现在正在扩大规模以提高（或可能只是实现）盈利能力。

有别于规模企业，初创企业经常尝试各种想法，以期找到用户需求。随着市场空间的探索，产品的原始愿景可能会发生巨大变化，从而导致其产品领域发生巨大变化。

一家真正的初创企业可能是一家资金有限的小企业，需要集中所有精力为其产品找到正确的需求。微服务主要解决初创企业在发现满足用户需求方案之后的问题。换句话说，微服务是解决初创企业成功后会遇到的各种问题的好方法。因此，首先要专注于成功！如果最初的想法不好，那么是否使用微服务构建也就无所谓了。

拆解现有的brownfield^译注4系统要比初创企业创建新的greenfield^译注5系统要容易得多。对于“brownfield”系统而言^译注4，有更多的资源可以提供给我们。我们有可以检查的代码，我们可以与使用和维护该系统的人员交谈。对运行中的系统进行更改，我们也能知道怎样的更改看起来是好的，也使我们能更容易的知晓我们是否在决策过程中犯错或者过于激进。

当然，我并不是说初创企业永远不要选择微服务，而是说这些因素意味着我们应该谨慎。仅围绕一开始就很清晰的边界进行拆分，其余部分则保留在单体之中。这也将使我们有时间从运营的角度来评估我们的成熟度——如果我们管理两个服务都很费劲，那么管理十个服务就将很困难。

需要客户安装并管理的软件

如果我们的软件需要打包并交付给客户，然后由客户自己运维，那么微服务可能是一种糟糕的选择。当迁移到微服务架构时，会给运维领域带来很多复杂度。那些用于监控单体应用并排查单体应用故障的先前的技术很可能不适用于新的分布式系统。现在，迁移到微服务的团队通过采用新技能——或采用新技术——来克服这些挑战。然而，这些通常不是我们的最终客户所期望的。

通常，对于需要客户安装的软件，我们会指定特定的平台。例如，我们可能会说“需要Windows 2016 Server”或“需要macOS 10.12或更高版本”。这些是明确定义的目标部署环境，我们很有可能会使用这些系统的管理人员所熟知的机制来打包单体软件（例如，发布Windows服务，并捆绑在Windows Installer程序包中）。我们的客户可能熟悉以这种方式购买并运行软件。

想像一下，当我们给客户一个程序来运行和管理时所遇到的麻烦，我们还要再给客户10个或20个程序？甚至更激进地，难道我们还期望客户在Kubernetes集群或类似集群上运行我们的软件？

现实情况是，我们不能期望客户拥有管理微服务架构的技能或平台。即使客户这样做了，他们也可能没有我们所需的相同的技能或平台。例如，不同的Kubernetes安装方式之间就有很大的差异。

暂无充分理由时

最后，如果对要实现的目标没有清晰的认识，我们就有最充分的理由不采用微服务。正如我们将要探讨的那样，采用微服务的目标决定我们从何处开始迁移，同时也决定我们如何拆解当前的系统。如果对目标没有清晰的愿景，我们就将在黑暗中摸索。迁移微服务仅仅是因为其他人都在做微服务，这是一个糟糕透顶的主意。

^译注1. Snap目前已经下线了。 ↩

^译注2. 初创企业（startup）: 创新精神的证明，用于证明产品是否符合市场需求。 ↩

^译注3. 规模企业（scale-up）: 介于初创企业（Start-up）和公司（Corporate）之间，是“下一个层次的初创企业”。初创企业是创新精神的证明，而规模企业意味着影响力和激烈的竞争。经合组织（OECD）给规模企业的定义是：三年内员工(或营业额)年平均增长率超过20%，并且在观察期开始时员工人数超过10人的企业。 ↩

^译注4. Brownfield： 指的是在遗留系统之上开发和部署新的软件系统，或者需要与已经在使用的其他软件共存。 ↩

^译注5. Greenfield： 指的是在全新环境中从头开发的软件项目。 ↩