MicroXchg柏林座谈会：微服务的成熟度

在MicroXchg 2018柏林微服务座谈会上，一个专家组探讨了微服务的现状，并分析了炒作期是否已经结束，微服务是否已经成为一项成熟的技术。座谈会由Susanne Kaiser主持，他在讨论开始时提了一个问题，使用微服务需要具备什么前提条件。由Stefan Tilkov、Chris Richardson、Elisabeth Engel和Daniel Bryant组成的专家组指出，重要的是要知道为什么希望使用微服务架构风格。有迁移需求吗？微服务主要是为了解决问题，而不是一项高端的新技术。

• Bryant是一名独立顾问兼InfoQ编辑，对于更多的技术前提，他援引了Martin Fowler和Phil Calçado的说法，但他重点强调了理解自己的领域模型的重要性。对于一家并不真正地知道自己在构建什么的初创企业，他会选择效率最高的技术，而这通常不是微服务。
• Engel是来自Gutefrage的UX和软件工程师，她指出，如果当前的架构没有让你觉得痛苦，那么也许你应该继续使用。
• Richardson是Eventuate的创始人，他指出，如果当前的架构拖了你的后腿，那么这是迁移到微服务架构的好时机。
• Tilkov是INNOQ的联合创始人，他指出，没有微服务也可以构建出优秀的系统，甚至，有时候使用单体可以构建出更好的软件。

接下来，Kaiser问道，采用微服务的最大障碍是什么以及如何克服它们。

• Tilkov认为，一个主要的障碍是你把服务边界或规模弄错了。这改起来太难，团队往往会接受最初的实现，即使那不是很棒。
• 在Richardson看来，采用微服务时的根本问题是如何分解成一个有意义的服务集。另一方面，当和有几百万行代码的单体应用程序打交道时，开发人员每天都要面对那种复杂的情况。而和单个服务打交道就简单多了。
• Engel认为复杂度是最难的部分。在她看来，成功的关键是要有东西让开发人员查阅、理解和使用。
• Bryant指出，我们一定不能忘记和微服务有关的所有技术，而且，设计和构建系统的方法和架构本身一样重要。

在探讨引入微服务后前端面临的挑战时，Engel指出，应用程序的用户仍然将其视为一个东西，因此，你必须保证，当内容来自不同的后端服务时，显示要保持一致。一项挑战是，前端技术不是为微服务后端而构建的。通常，其解决方案使用像了iframe、framesets这样的旧技术，为此，就需要一些基于JavaScript的新技术。Tilkov则指出，架构师必须更多地关注前端，认识到它的重要性。在他看来，前端通常比后端更重要。

接下来的问题比较笼统，就是微服务是否已经成为构建企业级应用程序的首选方式？

• Richardson和Tilkov认为，微服务不应该成为第一选择，他们强调，架构必须取决于上下文。对于单个的小型团队，单体几乎总是更好。涉及多个团队时，你可能应该考虑下某种形式的服务分解。
• Engel喜欢先准备一个单体架构，然后留有接口，在需要的时候可以分解。
• 在Bryant看来，演化架构非常有意义，有利于将来的架构迁移。

除了微服务外，Kaiser还问，无服务器架构是否是构建系统的下一步方案以及它们如何与微服务搭配使用。

• Richardson认为，无服务器和微服务互不相关，在他看来，无服务器是一种微服务部署方式——是容器将来的替代方案。
• 在Tilkov看来，无服务器是完美的部署选项；他认为，从今五年之后，我们将不再部署Kubernetes集群。不过，他有一个问题，就是他不清楚如何构建一个由其中100个函数组成的大型系统。他认为，我们需要某种东西把它们聚合成一个更大的单元，并和仅使用数据库触发器调用存储过程构建大型系统进行了比较。
• Bryant提到，类似Camunda这样的新技术是使用领域专属语言（DSL）描述函数交互的业务流程管理器（BPM）的下一次进化。它们允许业务函数组合成业务流程，可能是把简单的高度事件驱动的函数组装成工作流的一种方式。

当问到，微服务是否会退潮，并进化成其他东西时，专家组一致认为，我们总是需要缩小规模、降低复杂度。技术和平台会进化，但微服务中边界这个核心理念以及看问题的内外视角很长一段时间都不会变。Bryant认为，更标准的函数会被放入平台里，让开发人员可以更多地关注业务——也许，在不远的将来，软件工程师将和业务人员一起参加这个大会。

在近日举行的QCon伦敦2018大会上，有一个座谈会讨论了微服务和分布式系统的未来。

大会演讲已经录音；有的已经发布，后续还会有更多内容。

查看英文原文：The Maturity of Microservices: MicroXchg Berlin Panel Discussion