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 应用程序中，分离应用程序的开发和应用程序的维护相对容易，并且能在两个单独的团队之间拆分开发人员和运营人员的职责。在微服务架构中，情况并非如此，通常会有几十个、几百个或几千个微服务，因此对于微服务开发团队来说，分别雇佣开发人员和运营工程师是没有用的。此外，微服务架构允许开发者快速变动，因此从技术角度考虑也不需要有专门的运营工程师运行服务，开发者是最了解服务的工程师，他们能最好地运行它。
InfoQ：除了开发人员需要掌握的新技能，还要什么文化或组织的改变来支持微服务？
Fowler：真是很好的问题，要回答这个问题需要牵涉到很多内容（我写的书《生产就绪微服务》都是在回答这个问题！）我认为工程组织最要做的事情就是建立非常稳定的、可靠的、先进的应用程序平台基础设施（在微服务架构四层模型的第三层）。
InfoQ：正如你的博文《四层微服务架构》中所述的一样，成功的MSA 需要成熟的基础设施层次。虽然单个微服务并不很有用，但每个系统都要从无到有。那组织如何管理好从遗留系统转换到微服务所需的开销？
Fowler：我认为大多数小公司不一定能从微服务架构中获益，而且我不认为大多数公司应该打破他们的遗留系统而转换到微服务。
在有些情况下，微服务真的非常非常好。首先，如果应用程序或是系统有点复杂，但是它的各种功能之间可以划分出非常清晰的边界，那么转为微服务并不会很痛苦（前提是，如你所述，所需的基础设施能够到位）。我觉得这是比较罕见的情况。
第二种情况是大多数工程师和公司经历的微服务故事：应用程序已经不能再扩展了，可扩展性的限制造成了严重的性能和稳定性问题，不能再对应用程序做些什么了，开发速度停滞不前。在这种奇特的常见场景中，调整微服务所需的额外基础设施工作非常容易：无论是构建基础设施，还是未来应用程序无法规模化。
查看英文原文： Q&A with Susan Fowler on Production-Ready Microservices
评论