Sander Hoogendoorn认为，向微服务迁移就意味着向分布式系统进行迁移，在这里，我们必须要处理延迟、认证与授权、无法到达的消息。通过使用微服务，我们能够将大型系统拆分为更小的组件，从而实现对架构的重新掌控。借助于微服务，我们可以通过扩展并部署单个或一组组件的方式，实现小的变更或添加单独的特性。

Hoogendoorn会在9月12至13日举行的SwanseaCon 2016上做最终的主题演讲，这是在南威尔士举行的第二个有关敏捷开发和软件匠艺的会议。InfoQ对他进行了采访，我们讨论了多个话题，包括单体架构的软件产品的问题、如何使用微服务来构建最小化的可行产品、微服务的测试、微服务如何适应持续交付、微服务的优势和劣势，针对希望实现微服务的组织，他还给出了自己的建议。

有很多人针对微服务相关的话题撰写过文章，涵盖了如何使用和测试微服务、因使用微服务而创建的分布式系统所带来的额外复杂性该如何进行处理，并提供了在组织中实现微服务的建议。

InfoQ：在组织中，采用单体架构的软件产品的最大问题是什么？

Sander Hoogendoorn：单体的系统，不管是采用什么语言编写，运行在什么平台上，随着时间的推移都会不断增长。这意味着会有很多不同的人针对它们来开展工作，每个人在写代码的时候，都有其自己的风格。在系统存在的这些年中，会有特性的添加、修改和移除，这通常会导致不稳定架构的出现。另外，系统不是隔离运行的，通常会与更为广泛的系统进行集成，这样的话，会带来大量的外部接口。

因为很难集成新的特性，所以很多的组织在推出某项新特性的时候会耗费很长的时间才能将其推向市场。创新会减缓，经常会很难甚至根本不可能去拥抱新的技术。

InfoQ：微服务是如何为这些问题提供解决方案的呢？

Hoogendoorn：微服务架构的基本理念就是将大型的系统拆分为更小的组件，因此帮助组织实现对系统架构的重新掌控。这些组件之间的交流会通过易于使用的协议来实现，如基于HTTP的REST和JSON。这个词的前缀“微”意味着组件会按照代码行或服务端点的数量来进行衡量，但是我更喜欢采用领域驱动设计范式中的有界上下文（bounded context）来拆分系统，在这里每个组件会负责处理系统领域中一个独立的部分。

在InfoQ关于微服务反模式的文章中，Vijay Alagarasan阐述了微服务与面向服务架构（SOA）之间的关联关系：

如果你没有合适的人、文化和投入的话，SOA不会实现其业务价值。微服务架构与SOA没有本质的差异，它们的目标是一致的，但是微服务的方式更加精细，我可以这样说，微服务就是实现了可扩展性的SOA。

InfoQ：你们如何使用微服务构建最小化的可行产品（Minimum Viable Product）呢？

Hoogendoorn：按照最小化可行产品的思考方式，意味着要持续关注为产品新增价值，这需要通过提供该价值的最小版本来实现。微服务允许我们通过扩展一个或一组组件，为其添加独立的特性，并将它们（独立地）部署到系统之中。如果搭建了对应的持续交付功能，那么部署所修改组件的新版本就可以通过每日的基础代码来进行，当然这需要有相应的自动化测试。按照这种方式，在组织内部就可以持续地实现小的变更。

InfoQ：测试微服务可以采用什么方式呢？

Hoogendoorn：当你将整个系统拆分为很小的组件时，就需要在很多不同的级别来进行测试。首先，单元测试要覆盖到组件内部的所有内容。其次，服务接口需要进行测试，验证它是否会产生正确的输出或文档，比如JSON对象或PDF。下游的应用或其他的组件如果使用该组件所提供的服务，那么它们也需要进行测试，检验组件的输出是否依然正确。在微服务架构中，服务是松耦合的，通常会使用基于HTTP协议的REST和JSON，因此对于某个服务接口的变更，团队不一定马上就能意识得到。在组件的每次变更之后，都要运行自动化测试，这样的话，整个管道（pipeline）就能尽可能快地发现破坏性的变更。随着组件和服务数量的增长，测试的数量也会快速膨胀，在微服务架构中，我推荐让所有的测试都能实现自动化。

在一个关于微服务开发和测试的采访中，来自Redgate软件的Jose Lima则认为在微服务中，你并不需要将所有的测试都实现自动化，可以由其他的人实现功能检查，而不一定通过测试人员来完成：

有些人会认为测试自动化同样也是一项必备的技能，但我并不认同。首先，我不相信测试自动化，其次，检查自动化也可以由团队的其他人员来执行，并非一定要由测试人员来执行。并没有什么所谓的测试自动化，但肯定有检查自动化——对我而言，测试涵盖的内容要比检查更多，检查的过程可以进行自动化，不过只有你理解了要做什么以及这意味着什么之后，你才能够将功能检查做好（不管是否采用自动化），这样的话就能检查它的行为是否符合预期。

InfoQ：微服务是如何与持续交付协作的？

Hoogendoorn：借助持续交付，每项变更都会成为发布版本的备选内容。在微服务架构中，这意味着一个或一组组件会持续有新版本发布出来。因为这些组件会发布到分布式系统或互相协作的服务之中，所以设计良好部署管道就显得尤为重要，管道需要集成自动化测试的功能，这甚至比持续交付与单体架构结合使用时更为重要。你可能会说在理论上持续交付和微服务能够很好地进行协同。但在我的经验中，组织内将会面临大量的配置，这样做并不一定总能让事情变得更简单。

按照Alagarasan的说法，如果你想要采用微服务的话，持续部署和自动化测试是必需的：

如果你还没有采用持续部署的话，那么作为任意一家企业来讲都应该在这方面进行投资，并致力于实现相关的文化变更。至少，如果你无法实现自动化测试和部署的话，那么就不要采用微服务。微服务的目标在于驱动敏捷性，其中会伴随速度的变化；质量保证会涉及到每一个服务，每项服务都要具有自动化的单元、功能、安全以及性能测试。

InfoQ：微服务的优势和劣势是什么呢？

Hoogendoorn：往微服务架构迁移有助于将大型的系统拆分为更小的组件，从而实现对系统架构的重新掌控。这些独立的组件更加易于管理、替换、部署、扩展和测试。采用新的技术，如新语言、框架或数据库，也会变得更加容易，因为它们可以用于较少的一些组件中，而不必一次性地用到整个系统之中。但是，采用微服务也会带来其他的影响。这些小组件之间的通信会大幅增加。实际上，组织必须要意识到往微服务的迁移就意味着往分布式系统进行迁移，在得到它所有收益的同时，也伴随着分布式系统的所有缺点，包括必须要处理延迟、认证与授权、无法抵达的消息。

在InfoQ上一篇名为“微服务：分解应用以实现可部署性和可扩展性”的文章中，Chris Richardson也认为实现微服务就意味着创建分布式系统：

开发人员必须要处理创建分布式系统所带来的额外的复杂性。开发人员必须要实现进程间的通信机制。要实现跨多个服务的用例的话，如果不使用分布式事务是很难完成的。IDE以及其他的开发工具关注于开发单体架构的应用，并没有为开发分布式应用提供明确的支持。编写涉及到多个服务的自动化测试用例也是很有挑战的。在开发整体架构应用时，你无需处理这样的问题。

InfoQ：对于希望实现微服务的组织，你有什么建议要给他们吗？

Hoogendoorn：考虑采用微服务的组织应该有这样做的正当理由，而不仅仅因为这是当下最火的技术。这样做的理由可以包括当前的系统无法维护、新技术或平台需要纳入到系统中或者新特性推向市场的时间需要大幅减少。但是，当我们向微服务架构迁移的时候，还有很多的方面要考虑进来。它会改变我们设计、构建和测试软件的方式，它会改变我们搭建部署管道、认证与授权的方式，还会改变团队运维和协作的方式，这甚至会改变与组织内外利益相关者的交流方式。但是最为重要的是，需要意识到你将要构建的是分布式系统，这并不简单。有时候，另外一种方案就是采用与微服务相同的设计技术来拆分单体应用，然后依然在单体应用中重构和模块化我们的代码。

Alagarasan建议与总经理和高级主管一起协作，推动实现微服务所需的文化变更：

微服务的目标在于解决三个最常见的问题，也就是提升用户体验、应对新需求的高度敏捷性和降低成本，我们借助细粒度的服务来交付业务功能，就可以解决这三个问题。这并不是什么银弹，它需要训练有素的平台，在这里会以敏捷的方式来交付服务，从而使高质量成为了可能。（...）这是我们讨论容器化、云应用等内容之前所必需的一小步。(...)大多数的行为都会带来组织文化的变更，这是你自己所无法完成的，因此需要确保能够与你的总经理和高级主管进行协作。

查看英文原文：Microservices Imply a Distributed System