Uwe Friedrichsen 关于功能服务设计与观测性的演讲

本文要点

• 微服务的核心理念是支持应用模块独立和快速迭代的属性。这一点经常被实践者所忽略。
• 监控和日志系统需要以反映当前软件架构的方式演进，这既有技术上的影响，也有认知上的影响。
• 许多在传统软件工程教育中学到的关于如何功能划分的知识（例如，“不要重复造轮子”）在分布式系统，例如微服务系统中，并不行得通。
• “微服务”术语本身在将来也许会消失，但是这种新的功能分解式的架构风格会持续下去。
• 将一件事物标准化成一种通用的东西具有巨大价值，而碎片化、缺乏公平性和协作性会损害最终用户的利益。

在德国柏林举行的 microXchg 2017 大会上， Uwe Friedrichsen 发表演讲，讨论了“有弹性的功能服务设计”的核心概念以及如何创造可观测的系统。Friedrichsen 认为，要想开发高效的系统，微服务开发者必须：了解容错设计模式和缓存，但是不要试图使用它们来减缓基础设施很烂（过度耦合）的系统设计；理解领域驱动设计（Domain-Driven Design，DDD）和模块化；将组件的可替代性作为设计目标而不是复用性。

Friedrichsen 是 codecentric 的 CTO，他首先讲到，软件开发的目标是实现商业价值，因此必须意识到，软件一定会运行在生产环境且必须保持高可用性。现代的各种架构风格，例如微服务，意味着现在一切都是分布式的，通常可能会形成至少一个局域网，因此系统异常是普遍发生且不可预测的。开发者必须了解系统弹性（resilience）的基本原理：

系统弹性的基本原理、概念和模式

开发者应该熟悉容错设计模式，例如断路器模式、隔离壁模式、超时重试模式。这些设计模式因 Michael Nygard 的《 Release It! 》一书而流行。缓存虽然也很有用，但是应该小心部署，而且不要仅仅是用来克服一些糟糕的系统设计，例如一个功能的生效需要一条经过涉及许多依赖服务的很长的路径。

Friedrichsen 提出了一系列微服务的设计基础（如下图所示），包括一系列聚焦高内聚、低耦合和相互分离的设计概念。这些设计原则非常重要，适用于各种系统。虽然这些原理早在 20 世纪 70 年代就已经被 David Parnas 很好地整理成文（PDF 链接），但直到现在它们还经常被误解。

Uwe Friedrichsen 服务设计的基础原则

领域驱动设计（Domian-Driven Design，DDD）是一个非常有用的工具，但是许多开发者过度聚焦于领域的静态关系模型，Friedrichsen 称之为“实体驱动设计（Entity DDD）”。但是，系统的动态表现通常更能说明业务活动、领域事件和数据流。

引用 Fred Brooks 的观点，Friedrichsen 针对开发者过去多年追求的软件复用性进行了讨论。Brooks 认为，创建一个可复用组件的工作量通常是创建一个适用单个情景的组件的工作量的三倍。这意味着，任何针对复用性的投入，只有在一个组件不修改就可以至少被使用 4 次，才算是值得的。

Friedrichsen 建议开发者应该放弃复用性，追求可替代性

微服务系统内所使用的通信方式，也会深深影响功能服务设计。Friedrichsen 建议，前期的架构选择应该谨慎，因为它会限制系统未来的可维护性和扩展性。

Friedrichsen 演讲的结论信息和核心卖点是，开发者和架构师在实现分布式系统（例如使用微服务架构的系统）时需要重新认知功能服务设计，因为这些系统的属性决定了它们会加倍暴露出我们过去多年所了解的设计缺陷，并造成更严重的影响。

InfoQ 采访了 Friedrichsen，与他深入讨论了设计有弹性的和可观测的服务所面临的挑战：

InfoQ: Uwe，当前那些实践微服务的组织所面临的最具挑战性的问题是什么？

Friedrichsen: 他们太看重微服务了。

“微服务”已经成为了一个非常流行的主流术语。每个使用 Spring Boot 或者类似东西的人，都声称在做微服务。不要误会：我并不是说 Spring Boot 有什么问题，但是编写一个单独的系统，暴露一些 HTTP 接口，并不意味着你编写了一个微服务。

微服务的核心思想是支持应用模块独立和快速迭代。不幸的事，据我观察，大多数人定义一个微服务时，在这些理念上投入的精力太少了。

微服务是一种架构风格，能够帮助你快速前进。如果你所在的公司处在一个快速变化的市场，并且 IT 部门需要支持业务部门快速适应市场变化，你就需要让 IT 部门能够快速推进。

那些像微服务之类的炒作趋势的问题在于，人们经常尝试使用这些技术，即使这些技术对于他们的情况来说并不是一个恰当的方案。如果你的 IT 部门并不迫切需要变得更快，你也许并不需要微服务。你仍然可以使用 Spring Boot（毕竟，它很有意思），但是你不应该再称它为“微服务”。

InfoQ: Uwe，根据当前开发模式的变化趋势，你能推荐一种技术来鼓励开发者和架构师去思考功能服务设计吗？

Friedrichsen：如果我知道这样一种技术，我就会通过售卖它来赚取很多钱，变得很富有…但是，说良心话，我认为有三个因素，令开发者和架构师很难去思考功能服务设计到他们本来应该达到的程度：

1. 这太难了，真的是非常难。即使软件架构和设计已经发展了 40 多年，人们对此也是知之甚少。

许多人提到领域驱动设计（Domain Driven Design，DDD），它确实是一个很好的起点。但是，仅仅知道一些设计模式，与能够使用这些设计模式为你当前的业务难题创建一个合理的的设计，是完全不同的概念。特别是，当有产品经理或产品负责人经常坐在你旁边，催促你“更加多产”一点。

此外，我们在软件教育中学到的任何关于如何拆分功能的知识，例如，功能分解、“不重复造轮子”（DRY，Don’t Repeat Yourself）和创建可复用的功能，在类似微服务架构的分布式系统中并不可行。如果你使用这些最佳实践的设计，你会发现，最终的设计非常糟糕，会在生产环境严重困扰你。基本上，我们必须重新学习分布式系统的设计，并且根据我个人的观察，我们还需要学习如何正确地实现这一点。

2.IT 人员的真正问题是因为各种更吸引眼球的穿插概念忙的不可开交。

新的框架和编程语言，无休止的关于如何做这个和如何做那个的辩论，各种专家告诉你，如果你不做这个或者不做那个，你做什么都是错的。我们沉浸于各种吸引人的新的事物和观点。参加一场大会，阅读一本 IT 杂志，或者仅仅看看你 Twitter 时间线，你就会知道我的意思。所有这些看起来都比尝试学习如何做好设计更有趣。

3. 我们每 5 年集体失忆一次。

据我观察，我们每 5 年面临一代来自大学校园（或者其它地方）的开发者。从另一个方面，这意味着我们每 5 年集体失忆一次。这些新人不知道那些许多年前曾经为你打开眼界的演讲或者文章。他们不得不自己从各种拼凑的文章中重新学习所有这些知识。

在一些类似功能设计这样的“永恒”话题中，在 IT 领域，糟糕的现象是，“新”被认为是“有价值的”，而“老”被认为是“毫无价值的”。我们的业务在不断变化，不是么？什么知识能够经过 5 年，10 年，甚至 20 年还有价值呢？而且即使有一些人最终认识到并不是所有老的知识都是毫无价值的，我们仍然继续一遍又一遍讲述和遗忘同样的故事，而每年大量加入 IT 行业的新开发者对这些知识仍然是闻所未闻。

InfoQ: 您提到了 IT 行业人员的快速变化，那么微服务架构风格本身的前景如何呢？

Friedrichsen：坦率地讲：我也不知道。可能在大部分供应商、咨询顾问和那些喜欢用新潮的事物标榜自己的人炒作了其它新的术语之后，“微服务”术语本身最终会像其它炒作的术语一样沉寂。但是，架构风格会持续下去。事实上，这些风格在我们称之为“微服务”时其实并不是新的概念；它已经存在许多年了。它只是根据 IT 行业的进步做了一些更新，然后被称作“微服务”罢了。而且也许在下一次更新之后，这个架构风格会被称作不同的东西。

在不久的将来，我们也许会看到一些微服务风格更加不同的特性。并不是每个人都需要一个“纯粹的”微服务风格的所有特性。许多人也许只会使用微服务风格的一部分特性来满足他们的需求。

但是，坦率地讲：最终如何，我也不知道。

Uwe Friedrichsen 的完整演讲视频《有弹性的功能服务设计》可以在InfoQ 查看。

关于采访嘉宾

Uwe Friedrichsen 是 codecentric AG 的 CTO，他专注于系统弹性、可扩展性以及 IT 行业发展前景。Uwe 从事 IT 领域多年，一直研究创新的想法和概念。你可以在技术大会或者他的文章、博文以及 twitter 消息中看到他分享的想法。

查看英文原文： Uwe Friedrichsen on Functional Service Design and Observability

感谢罗远航对本文的审校。