花8年转型微服务却得不到回报，问题出在哪儿？
我预计未来几年架构分析将出现质的飞跃，这要归功于新的AI技术。
市场上的新技术层出不穷，但有些新技术只有在特定情境下才能带来好处，在其他情况下可能会适得其反。微服务是其中之一。Davide Taibi博士是芬兰奥卢大学的教授，长期致力于研究从单体架构到微服务架构的转换，以及云原生系统架构及其中的技术债务的发现与检测。他深入研究了许多软件工程案例。在Davide Taibi博士参加上海ArchSummit大会之际，InfoQ采访了他，了解他对当前技术热点的看法。
InfoQ：从微服务得到明确定义发展到现在，差不多十年了。结合您的演讲主题来看，您认为在微服务这个架构领域是否还有炒作行为？
Davide Taibi：微服务的大肆宣传并未结束。但是，十年前一些企业受此宣传和炒作的影响转向微服务，很多情况也只是盲从竞争者的脚步。而如今，大多企业都已对微服务的优劣了如指掌。
在我们看来，这些转向的企业的一个最大的问题是在开始阶段对微服务带来的好处的过高期待。企业相信微服务可以轻松降低开发成本和维护难度并提升速度和可扩展性。可过了一段时间却发现微服务的开销甚至还高于传统单体架构，而且并不是默认自动规模化。支持高可扩展性也是需要手动采用扩展机制才行。
InfoQ：过去有很多企业选择了从单体迁移到微服务，看起来是一个单向的发展过程。那么在您看来，在这十几年间，架构设计模式有着什么样的演进原则，有没有哪些以前认为是“良好”的架构设计风格在演进中逐渐消失了的？
Davide Taibi：绝大部分的设计模式会逐渐被新的模式取代，就像之前流行的MVC（模型、视图和控制器）以及SOA（面向服务的架构）。微服务可以被看做是一种恰当地实现的面向服务的架构，尽管还是有一些区别。
近些年，新的风口又转向了无服务方法并引领企业转向了“纳米服务”。但是，试探之后很多企业又选择退回到微服务，或使用无服务方法来创建微服务。
InfoQ：您有一篇论文，讲到您们采访过很多从单体迁移到微服务案例相关开发人员，虽然迁移前大家无法清楚判断利弊，但多年后再次回顾这些案例的话，您认为这些迁移都是值得的吗？
Davide Taibi：基于我们的经验，向微服务的转型需要很长时间，一般是几年。我们了解的实例中有一些拥有大型代码库的公司花了八年来转型。其中的优势一般在于各团队的高独立性，而并不是简单的低开销低维护成本。在很多实例中，转型都没得到应有的回报，期待的好处也没能实现。
InfoQ：您的论文“On the Definition of Microservice Bad Smells”涉及非常多的微服务不良做法，但如果要用几个大类别来列举危害性比较大的微服务反模式，您认为会是哪几类？另外，您能再大概分析说明下造成这个几个反模式的原因吗？
Davide Taibi：就我个人而言，最坑的反模式存在于组织中，而非技术之罪。
技术上的反模式很容易修复（如，循环依赖），而解决组织上的问题没那么简单。比如，错误的开发团队分组将团队按水平功能划分而不是垂直划分（分成数据库团队、前端团队、后台团队）。
另一种组织结构问题可被称为“微服务贪心（Microservice Greedy）”，指的是开发者对于任何可能的功能都创建新的微服务。他们都没有查看是否能重用代码，甚至确认这个功能是不是已经存在就开始实现了。结果就导致微服务数量暴涨，结构迅速退化，维护的复杂度和成本也随之激增。
InfoQ：最近谷歌开源了Service Weaver，谷歌称此框架为模块化单体（modular monolith），称其能兼顾单体应用的开发速度，以及微服务的可扩展性、安全性和容错性。但有人认为这就是一种“分布式单体”。您能解析对比分布式单体与模块化单体之间的异同吗？
Davide Taibi：在我看来，“分布式单体”只是对于“维护不了的分布式系统”的一种误导性的称呼。
我坚决同意一个设计优良具有模块化功能的单体系统维护起来可以很简单。但主要的问题不是软件本身而在于组织结构。过大的组织结构将导致团队缺少独立部署的能力。
InfoQ：您如何看待这种模块化单体方法？它能解决单体和微服务架构的痛点吗？模块化单体会成为一种主流发展趋势吗？
Davide Taibi：我相信模块化单体系统已存在有20多年了。我并不期待有革命性地变化。我觉得模块化单体的目标系统要比那些受益于微服务的系统要小一些。
InfoQ：微软的Dapr框架如今也已进入大厂实践，许多架构师在更多地考虑Dapr级别的东西，这是否说明这条路是走得通的？它会影响到微服务技术的未来发展走向吗？
Davide Taibi：这可能会影响.Net应用的未来趋势。不过我觉得现在做预测还是为时尚早。
InfoQ：微服务发展几乎是伴随着云服务的，像Netflix当年的改造，也是云+微服务同时进行的，那么在微服务的发展过程中，您认为微服务的复杂性主要来自哪里？跟技术债务相关吗？
Davide Taibi：云服务其实也仅是一项支持软件系统开发和运行的技术。不幸的是，其技术负债需要单独处理。一个值得考量的重要方面是，只要更多的“可以动”部件（moving parts）被应用到系统中，更高的技术负债将会累积。
InfoQ：云原生架构也意味着“技术大爆炸”，涉及到了多个方面，开发人员认知负荷很重，如果我们希望自己成为架构师，那我们如何去学习这些知识？企业应该如何去传承云原生领域的架构知识和实践经验？
Davide Taibi：我认为企业之间应该共享他们的经验，特别是开始在一些在线授课平台和维基百科收集经验。
主要的问题是新的技术总会最终应用到市场，软件架构师应该不停地扩充知识，与时俱进。
InfoQ：对架构的未来发展趋势，您有怎么样的判断？结合当前的GPT的热点，“架构”是否是最难被AI改造的领域？
Davide Taibi：我相信边缘计算和云到边系统会很快成为主流。同时，我期望看到服务网格很快成为焦点。
目前，架构或架构分解可能是最具挑战性的任务。原因是，在我看来，要指定架构，我们需要用自然语言提出问题，正确解释需求，并理解系统应该如何组成。
无论如何，我预计未来几年架构分析将出现质的飞跃，这要归功于新的AI技术，而不仅仅是GPT。
InfoQ：对于当前并不确定是否要选择云原生架构的企业，您有哪些建议？
Davide Taibi：我给一些还不确定时候应用云原生架构的企业的建议是，真实考量你的需求，你的组织结构，以及公司开发者的经验。
如果有庞大数量的开发团队致力于不同的系统功能，你可以考虑微服务。如果有些功能你需要极限可扩展性，那么你可以考虑无服务方法。其他的情形都需要准确地考量。
考虑到架构迁移的成本和影响，雇佣有经验的咨询顾问是很明智的。他们会提供一个“外来人”的视角在作出重要决定之前对企业和系统进行合理评估。