微服务的未来：功能性服务设计和可观测性

为了准备将于柏林举行的第 16 届和第 17 届 microXchg 会议，InfoQ 与 Uwe Friedrichsen 和 Adrian Cole 一同讨论了功能性服务设计（functional service design）和对于监测分布式系统的新挑战，以及未来微服务架构的类型应该是怎样的。

同 Uwe Friedrichsen（codecentric 的 CEO）和 Adrian Cole（Pivotal 的软件工程师）谈话的关键信息总结如下：

• 和微服务相关的关键理念，一个是支持独立性的特性，支持应用生态中另外部分的独立性，另一个是支持快速演化的特性。这些是经常被实现者们所忽略的。
• 监测系统和记录系统应该以反映当前软件架构的方式进行演化，同时这会产生技术上和认知上的影响。
• 在传统的软件工程教育中学到的如何进行功能划分的许多东西（比如“不要写重复的代码”）在分布式系统中是不适用的，例如微服务。
• “微服务”这个术语本身可能会在将来出现，但是功能分解的新架构形式已经被大家所接收。
• 使已经成为商品的事物标准化是很有价值的，然而分裂化、缺乏公平和缺少交互性会引起终端用户价值损失。

采访的全部内容如下所示：

InfoQ：Uwe，当前的各个组织机构实现微服务遇到的最有挑战性的问题是什么呢？

Friedrichsen：是他们在一开始就在做微服务。

“微服务”成为了流行的、主流的术语，在使用 Spring Boot 的人或者使用类似 Spring Boot 的人都声称他们在做微服务。不过，别曲解我的意思：Spring Boot 没有任何问题，但是写一个独立的、暴露了几个 HTTP 接口的应用并不意味着你在做微服务。

和微服务相关的关键理念一个是支持独立性的特性，支持应用生态中另外部分的独立性，另一个是支持快速演化的特性。不幸的是，就我的观察而言，大家并没有在这些定义了微服务的特性上花很大的功夫。

微服务是一种能帮你快速演化的架构类型。如果你的公司在一个发展非常快的市场中，如果你的业务需要信息技术的支持才能快速发展，你就必须要在信息技术领域快速进步、演化。但是，即便如此，不仅仅是架构类型需要像信息技术一样快速演化，还有许多东西也需要像信息技术一样快速发展。

像微服务目前这样的炒作趋势存在的问题是，即使微服务不能充分解决他们的问题，他们也会使用微服务。如果你并不需要更快的信息技术，那么你可能并不需要微服务。你可以继续使用 Spring Boot（这很有趣），但是你不应该把它称为“微服务”。

InfoQ：Adrian，谈到快速演化（并不是说拔苗助长），有多少传统的系统监测方法在演化，对分布式应用提供有价值的监测？

Cole：监测系统和记录系统应该以反映当前软件架构的方式进行演化，或者以反映他们正在实践的架构的方式进行演化。例如，从一个更小的范围来看，从微服务到各个功能都会产生技术上和认知上的影响。例如，如果可视化和交付的度量指标不能捕获到短期的管理函数，这就是有问题的。

我们也必须强调认知负担。例如，我们向发送错误报告的操作中添加分布式的交易上下文，然后用更多的上下文不断堆积，再进行进一步解释。这是一个困难的任务，因为演化需要针对系统或者认知负担进行平衡。

InfoQ：我们已经听 Uwe 谈了关于像 Spring Boot（和 go-micro，Seneca.js）这些“微服务”架构的使用；在一个现代的开发环境中实现可观测性容易吗？

Cole：正因如此，我正在 microxchg 上做一个关于 Zipkin 分布式监测的访谈，其中会谈到一点有关 Java 和 Spring Boot 的内容。添加“sleuth”是很容易的，“sleuth”是 Spring Boot 上的一款分布式监测插件，是由 Marcin Grzejszczak 带头实现的。使用 start.spring.io ，你只需要通过字面意思，点击像 Zipkin 这样的文字就能得到一个不错的结果。从我所看到的已发布博客来判断，我认为大家都觉得这已经足够简单了。

在 golang 中，我没有听到太多关于“微”和“监测”这样的字眼，但是 Peter Bourgon 的 go-kit 工具包通过实现了一个叫 OpenTracing 项目的类库接口，提供了对监测的支持。文档中提到 appdash 和 Zipkin 是开箱即用的。后者由 Bas van Beek 进一步确保可用性，Bas van Beek 是 Zipkin 的 golang 常驻支持者。

InfoQ：Uwe，现在演化这个词对于开发模式也有很大帮助，你能推荐一种激励开发者和架构师考虑功能性服务设计的技术吗？

Friedrichsen：如果我知道这种技术的话，我会把它卖掉，换很多钱，变成富翁…但是，老实地说，我发现了三个因素，这三个因素在某种程度上影响了开发者们和架构师们需要考虑到的功能性服务设计：

1. 这是一件很难、非常难的事情，甚至对于 40 年以后的软件架构师来说也很难，这是一种很难理解的设计。

很多人后来谈到了 DDD（领域驱动设计 Domain Driven Design），DDD 确实是一个很好的出发点。然而，仅仅知道这个模式完全不同于你将这个模式应用到你的当前业务问题中，尤其是当你的产品经理或产品负责人成天坐在你旁边，一直催促你要“更高效”。

同时，我们在软件工程教育中所学到的如何进行功能划分的知识，例如，功能分解，DRY（不要写重复的代码 Don’t Repeat Yourself），或者是创建可重用功能，这些对于像微服务这种分布式系统来说是不可用的。如果你使用这些所谓的设计最佳实践，你最终会得到一个很糟糕的设计，会让你对它的效率困扰不已。我们基本上要重新学习对于分布式系统的设计和基于个人定制的监控系统的设计，我们仍然需要学习许多东西，学习怎样才能正确实现它。
2. 真正的问题是，信息技术的发展受到了许多更具诱惑力的、昙花一现的技术的阻碍。

新的框架、新的编程语言、无穷无尽的辩论，该怎么做这个，该怎么做那个，还有一群固执己见的人告诉你说，如果你不这样做、不那样做，你就是错的。我们被各种新鲜的事物和观点淹没。你去参加一场会议，你去读一本 IT 杂志，或者去看看你的推特上的时间线，你就会明白我说的是什么意思。所有的这些都比学习如何设计一个更好的系统有趣得多。
3. 我们每五年就会丢掉我们的共同记忆（collective memory）。

据我的观察，我们大约每五年就会迎来一批新的来自大学（或者来自其它地方）的开发者。从另一个角度来看，这意味着我们每五年就会丢掉我们的共同记忆。这些人没有看过几年前开拓你眼界的那些访谈和文章。他们需要从头重新学习，向从前那些开拓信息技术的所有人学习。

使得情况更糟糕的是像功能设计这种“永恒的”话题。在信息技术中，“新的”被认为是“有价值的”，“旧的”就被认为是“无价值的”。我们正在一个快速发展的商业社会中，不是吗？五年以前、十年以前、甚至二十年以前的旧知识还有哪些价值？即便有人意识到不是所有的旧的知识都是无价值的，我们也要一遍一遍的重述然后再忽略这些知识，每年加入 IT 行业的新开发者们大部分都没有听说过这些知识。

InfoQ：你谈到了 IT 工业中的人们都在快速改变：微服务架构类型的未来是什么？

Friedrichsen：坦白地说：我不知道。“微服务”这个词语最终可能会像所有被大肆宣传的那些词一样爆发，尤其在一些人开始用之后，像那些大多数的供销商、咨询师，和那些想要用一些很新、很酷的词包装自己的那些人。另一方面，这个架构类型是没有变的。事实上，当我们开始称它为“微服务”时，它就不是什么新鲜的事物了，它已经存在了许多年。它只是由于信息技术的进步而进行升级了，然后被称为“微服务”。并且有可能在下次更新换代之后，它又有了其它的什么新的名字。

在不远的将来，我们可能会看到微服务类型的分化。并不是所有人都需要一个“纯净”微服务的所有特性。一些人可能仅仅需要微服务特性的一个子集，仅仅为了满足他们当前问题的需求。

但是，在最后，我坦率地说，我不知道。

InfoQ：在最后，Adrian，谈到微服务类型的未来，你对这个领域开放的标准是怎么看的呢，对于建立一个管理这些的组织 / 基金会你又怎么看呢？

Cole：这个问题是最难回答的！在实践中，我们对开放（Open）和标准（Standard）这两个词的使用是非常宽泛的，所以这个问题是很难回答的。例如，有许多小工作团体都用开放这个词来修饰各种事物，每一个修饰都有着不同的标准，不同的对于开放的定义以及不同的开放的程度。同样也有标准说，不要把开放这个词用到它们身上去，还有一些标准的开放程度似乎与像 IETF 这样的正式团体相媲美。例如，我对提出 reactive streams 标准的工作组印象深刻，并且如果你去看看他们的网站，你会发现提到开放这个词的地方只有“开放一个问题（Open an issue）”。

回到重点，使已经成为商品的事物标准化是很有价值的，然而分裂化、缺乏公平和缺少交互性会引起终端用户价值损失。各种基金会和组织有助于创造标准，因为，严格来说，标准是需要长期不断更新变化的。这并不意味着标准不能从不周全的计划开始，也不意味着标准不能在必要的时候从计划不周过渡到正式，更不意味着一个一开始不周全的标准不会成功。这仅仅是我的拙见…

InfoQ 会对柏林二月第 16 届和第 17 届的 microXchg 带来最新报道。更多细节和大会日程请参阅大会网站。

查看英文原文： The Future of Microservices: Functional Service Design and Observability

感谢刘志勇对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。