微服务的优缺点

最近一段时间以来，社区中围绕着微服务产生了很多争论，也充斥着大量的宣传。过去的 10 年间，我们已经实现了很多笨重的 SOA 解决方案，微服务是业界期待已久的解决方案么？或者说微服务要比整体解决方案更加简单？

在讨论这些话题之前，我们最好先对微服务下个定义。在题为微服务的文章中，作者 James Lewis 与 Martin Fowler 是这样定义微服务架构风格的：

开发单个应用作为一系列小型服务的套件，其中每个服务都运行在自己的进程中，并且通过轻量级的机制实现彼此间的通信，这通常是 HTTP 资源 API。这些服务是围绕着业务功能构建的，并且可以通过完全自动化的部署机制进行独立部署。这些服务的集中式管理做到了最小化，每一种服务都可以通过不同的编程语言进行编写，并且可以使用不同的数据存储技术。

微服务的一些优势是显而易见的：

• 每个服务都很简单，只关注于一个业务功能。
• 每个微服务可以由不同的团队独立开发。
• 微服务是松散耦合的。
• 微服务可以通过不同的编程语言与工具进行开发。

这些优势使得微服务看起来是非常完美的解决方案，不过微服务难道就没有缺点么？

Contino 的 CTO Benjamin Wootton 正在基于微服务对一个系统进行架构设计，他遇到了不少困难，并且将遇到的这些问题发表在了题为 Microservices - Not A Free Lunch! 的文章中。下面是文章的一些摘要。

运维成本过高

故障恢复后，20 个服务可能要占据 40——60 个进程，同时弹性问题也浮现出来了。在添加了负载均衡与消息中间件后，进程的数量还会持续增加。运维与编排所有这些服务是个“令人望而却步的任务”，Wootton 说到：

实现所有这些需求需要高质量的监控与运维基础设施。保持一台应用服务器的持续运行就需要专人来负责，但现在我们还得确保几十、甚至是几百个进程都处于运行状态、不能将磁盘空间耗尽、不能出现死锁，还要保证性能。这真是一个非常棘手的任务。

运维的过程需要自动化，不过由于“并没有多少框架和开源工具能够对此提供支持”，结果就是“使用微服务的团队要在他们编写具有业务价值的第一行代码前需要大量使用自定义脚本或是进行开发以管理这些进程”。

DevOps 是必须的

Wootton 认为实现微服务的组织需要 DevOps，这是因为：

你不能简单地将通过这种风格构建的应用抛给运维团队。开发团队需要非常关注运维与产品，因为基于微服务的应用与其环境上下文是非常紧密地集成到了一起的。

由于很多服务可能都需要自己的数据存储，因此开发者还需要“搞清楚如何部署、运行、优化以及支持各种 NoSQL 产品”。

接口不匹配

服务依赖于彼此间的接口进行通信。改变一个服务的接口会对其他服务造成影响，Wootton 谈到：

修改了契约一方的语法或是语义，那么所有其他服务都需要理解这个改变。在微服务环境下，这意味着简单的交叉改变会导致很多不同的组件发生变化，这些组件需要以一种协调一致的方式进行发布。 当然了，我们可以通过向后兼容的方式避免这些变化的发生，不过实际情况却是业务驱动的需求让我们没法实现分阶段的发布。

如果彼此协同的服务向前推进并且不再同步了，比如说使用 canary 发布方式，那么修改消息格式的效果就难以可视化了。

代码重复

为了避免将“同步耦合引入到系统中”，Wootton 认为有时需要向不同服务添加一些代码，这就会导致代码重复，而代码重复“是非常不好的，因为每个代码实例都需要进行测试和维护”。一种解决方案是在服务间使用共享库，不过“在多语言环境下这就行不通了，而且引入了耦合就意味着服务需要并行发布来维护彼此间的隐式接口”。

分布式系统的复杂性

作为一种分布式系统，微服务引入了复杂性和其他若干问题，比如说“网络延迟、容错性、消息序列化、不可靠的网络、异步、版本化、应用层中的负载变化等等”。

异步

Wootton 认为微服务常常会使用异步编程、消息与并行，如果要求某个操作必须是同步且具有事务的，那么这就非常复杂了，这要求我们得“管理好相关联的 ID 以及分布式事务，将各种动作绑定在一起”。

测试

使用微服务架构时，测试是另一个需要考虑的问题，因为“无论是手工测试还是自动化测试，我们都很难以一致的方式重现环境”，Wootton 说到：

当添加了异步与动态消息负载后，要测试以这种风格构建的系统就难上加难了，同时也无法对将要发布到生产的各种服务抱有信心。 我们可以测试每个服务，不过在这种动态环境下，非常微妙的行为都会从服务间的交互中产生出来，这是难以做到可视化的，也不易想清楚，更不必说全面的测试了。

Brady 评论了 Wootton 的文章，谈到了他尝试从整体应用向微服务转变的经历：

正在从事的一个项目就在从一个整体应用向微服务迁移，我们遇到了你在文章中提到的大量问题。最后有大量重复代码（因为这些服务是使用不同语言和框架构建的），遇到了很多“隐式契约”问题。比如说，将一个服务的 User 数据映射到另一个服务上（其中一个服务不一定像另一个服务一样需要所有的数据）。虽然这种方式有一些显而易见的好处，不过在使用之前一定要有非常精心的规划才行。最后，我们所采取的方式是对整体应用进行模块化（这样就可以在模块间共享代码仓库、部署和代码了，同时依然保持良好的松散耦合的组件）并将一些模块放到自己独立的微服务中来实现独立的部署与管理，当然了，我们只在必要的情况下才这么做。

另一位读者 Dennis Ehle 也分享了他在微服务方面的经验，他给出的结论是微服务是有代价的：

我们目前为一个客户实现了一个 CD 管道自动化框架，有 450 个开发人员，50 个服务（或者叫微服务）。对于我来说，这种架构最迷人的地方在于这 450 个开发者都不需要编写一行代码来支持顾客的用户界面。UX 方面的工作是由一个不同的小组完成的。

虽然非常灵活、风险小，并且节省了成本，这个客户也非常喜欢这一点，直接的结果就是从整体架构完全迁移过来了，不过毋庸置疑的是，由于文中提到的众多因素，使用微服务还是需要付出额外的成本的。

此外，读者 Steve Willcox 提到了微服务所引入的一些挑战：

作为从整体 Java 应用转换为 SOA 实现过程中的一名技术领导，我遇到了文中提到的所有问题，不过相对于将其看作是问题，我将他们看作构建更好的软件的机会。 文中提到“需要大量的 DevOps 技术”，我觉得这很好啊。这样，开发者就有机会了解自己编写的代码是如何运行的了。采用 SOA 实现会迫使你成为一名 DevOps，服务团队开发者自己做 DevOps，而不像以前那样“将东西丢给集中化的运维团队”。这对于让开发团队负责自己代码的运维来说是积极的。

没错，相对于整体应用来说，采用微服务会有更多的服务要构建、测试和部署，不过时至今日，这些事情应该都是自动化的了。只要遵循相同的自动化模式，2 个和 20 个的工作量其实差别不大。

关于代码重复，读者 Willcox 认为结果其实没那么差：

对于这一点，我过去是非常纯粹的，认为所有的代码重复都是不好的，不过接下来我认识到这种纯粹性有时会导致更高的代价，更复杂的系统。我现在就变得很实际了，简单性也是非常重要的一个方面。我非常认可 Richard Gabriel 在 The Rise of Worse is Better 一文中对此的论述。

总而言之，微服务架构有很多吸引人的地方，不过在拥抱微服务之前，你需要认清它所带来的挑战。

查看英文原文： The Strengths and Weaknesses of Microservices