转载

与Susan Fowler探讨生产就绪微服务之问答

Microservices.com Practitioners峰会是为从业者量身定制的微服务会议，峰会专注于介绍大规模采用微服务的实际应用。峰会将会于2017年1月31日在旧金山举行。演讲者包括来自Uber、New Relic、Lyft、PayPal和Google的微服务从业者。

Susan Fowler是 Stripe 的工程师，她是《生产就绪微服务》一书的作者，并受邀会在峰会上发言。在 Uber 的时候，Fowler致力于标准化微服务，并将微服务嵌入各种关键业务团队，帮助他们的服务变得更加可靠。

在峰会之前，InfoQ采访了Fowler，和她讨论了成功实施微服务架构的技术、业务和文化挑战。

InfoQ：可以在哪里看到微服务架构的理念和大多数组织的实际系统相关联，甚至是产生冲突？

Susan Fowler：在相关联方面，我认为采用微服务架构是很多软件应用程序发展的自然步骤。Monorepos（monoliths）很难大规模使用，许多工程组织可以发现，并确实发现现在规模化发展受到了限制（没有并发性，没有分区等等）。他们还发现，开发速度停滞不前，因为一旦应用程序很庞大且有很多工程师同时工作于相同的应用程序上时，在monorepo上部署开发就变得不太可能（从组织的角度来看）。一旦真的发生这种情况，最简单、最容易规模化的方法就是采用微服务架构。

这也正是大多数冲突发生的地方。由于采用微服务往往是软件系统发展的“下一步”，所以大多数系统的设计中都没有考虑到微服务架构，这会产生很多问题，其中一些是组织性的，另一些是技术性的。

比如说，从组织的角度上看，最终会有很多孤立的、没有关联的团队，除非你事先计划了很多跨团队协作，否则他们闷头做自己的微服务工作，但不知道系统的其他部分工作。最终微服务开发团队之间还会缺乏相互信任，他们不确定自己的服务所依赖的其他微服务是否是可靠的、稳定的、规模化的等等。

你也可能发现（与许多公司做的一样），很难在微服务生态系统中雇佣并运营单独的运营组织，开发人员需要学习接管他们微服务的运营职责（很多人可能会不习惯，或没受过培训，或准备开始做）。

在技术方面，比如说你可能会碰到很多奇怪的微服务，这些微服务没有什么意义，相互之间没有很好联系。这是因为它们之间的边界和它们的功能从没有在原来的monolith中恰当地定义过。

我经常能看到的另一个技术挑战是，微服务的基础设施需要非常复杂的微服务架构才能成功，许多习惯于运行monolithic应用程序的公司通常没有考虑到这些方面。

InfoQ：对于拥有传统monolithic系统工作经验的开发人员，他们想要转到写微服务需要学习的最重要技能是什么？

Fowler：当他们的组织开始采用微服务架构时，开发人员需要学习的最重要技能是他们最需要的操作技能。Monolithic应用程序中，分离应用程序的开发和应用程序的维护相对容易，并且能在两个单独的团队之间拆分开发人员和运营人员的职责。在微服务架构中，情况并非如此，通常会有几十个、几百个或几千个微服务，因此对于微服务开发团队来说，分别雇佣开发人员和运营工程师是没有用的。此外，微服务架构允许开发者快速变动，因此从技术角度考虑也不需要有专门的运营工程师运行服务，开发者是最了解服务的工程师，他们能最好地运行它。