花8年转型微服务却得不到回报，问题出在哪儿？

市场上的新技术层出不穷，但有些新技术只有在特定情境下才能带来好处，在其他情况下可能会适得其反。微服务是其中之一。Davide Taibi 博士是芬兰奥卢大学的教授，长期致力于研究从单体架构到微服务架构的转换，以及云原生系统架构及其中的技术债务的发现与检测。他深入研究了许多软件工程案例。在 Davide Taibi 博士参加上海 ArchSummit 大会之际，InfoQ 采访了他，了解他对当前技术热点的看法。

Davide Taibi：微服务的大肆宣传并未结束。但是，十年前一些企业受此宣传和炒作的影响转向微服务，很多情况也只是盲从竞争者的脚步。而如今，大多企业都已对微服务的优劣了如指掌。

在我们看来，这些转向的企业的一个最大的问题是在开始阶段对微服务带来的好处的过高期待。企业相信微服务可以轻松降低开发成本和维护难度并提升速度和可扩展性。可过了一段时间却发现微服务的开销甚至还高于传统单体架构，而且并不是默认自动规模化。支持高可扩展性也是需要手动采用扩展机制才行。

Davide Taibi：绝大部分的设计模式会逐渐被新的模式取代，就像之前流行的 MVC(模型、视图和控制器) 以及 SOA(面向服务的架构)。微服务可以被看做是一种恰当地实现的面向服务的架构，尽管还是有一些区别。

近些年，新的风口又转向了无服务方法并引领企业转向了“纳米服务”。但是，试探之后很多企业又选择退回到微服务，或使用无服务方法来创建微服务。

Davide Taibi：基于我们的经验，向微服务的转型需要很长时间，一般是几年。我们了解的实例中有一些拥有大型代码库的公司花了八年来转型。其中的优势一般在于各团队的高独立性，而并不是简单的低开销低维护成本。在很多实例中，转型都没得到应有的回报，期待的好处也没能实现。

Davide Taibi：就我个人而言，最坑的反模式存在于组织中，而非技术之罪。

技术上的反模式很容易修复 (如，循环依赖)，而解决组织上的问题没那么简单。比如，错误的开发团队分组将团队按水平功能划分而不是垂直划分 (分成数据库团队、前端团队、后台团队)。

另一种组织结构问题可被称为“微服务贪心（Microservice Greedy）”，指的是开发者对于任何可能的功能都创建新的微服务。他们都没有查看是否能重用代码，甚至确认这个功能是不是已经存在就开始实现了。结果就导致微服务数量暴涨，结构迅速退化，维护的复杂度和成本也随之激增。

Davide Taibi：在我看来，“分布式单体”只是对于“维护不了的分布式系统”的一种误导性的称呼。

我坚决同意一个设计优良具有模块化功能的单体系统维护起来可以很简单。但主要的问题不是软件本身而在于组织结构。过大的组织结构将导致团队缺少独立部署的能力。

Davide Taibi：我相信模块化单体系统已存在有 20 多年了。我并不期待有革命性地变化。我觉得模块化单体的目标系统要比那些受益于微服务的系统要小一些。

Davide Taibi：这可能会影响.Net 应用的未来趋势。不过我觉得现在做预测还是为时尚早。

Davide Taibi：云服务其实也仅是一项支持软件系统开发和运行的技术。不幸的是，其技术负债需要单独处理。一个值得考量的重要方面是，只要更多的“可以动”部件（moving parts）被应用到系统中，更高的技术负债将会累积。

Davide Taibi：我认为企业之间应该共享他们的经验，特别是开始在一些在线授课平台和维基百科收集经验。

主要的问题是新的技术总会最终应用到市场，软件架构师应该不停地扩充知识，与时俱进。

Davide Taibi：我相信边缘计算和云到边系统会很快成为主流。同时，我期望看到服务网格很快成为焦点。

目前，架构或架构分解可能是最具挑战性的任务。原因是，在我看来，要指定架构，我们需要用自然语言提出问题，正确解释需求，并理解系统应该如何组成。

无论如何，我预计未来几年架构分析将出现质的飞跃，这要归功于新的 AI 技术，而不仅仅是 GPT。

Davide Taibi：我给一些还不确定时候应用云原生架构的企业的建议是，真实考量你的需求，你的组织结构，以及公司开发者的经验。

如果有庞大数量的开发团队致力于不同的系统功能，你可以考虑微服务。如果有些功能你需要极限可扩展性，那么你可以考虑无服务方法。其他的情形都需要准确地考量。

考虑到架构迁移的成本和影响，雇佣有经验的咨询顾问是很明智的。他们会提供一个“外来人”的视角在作出重要决定之前对企业和系统进行合理评估。