InfoQ：您的论文“On the Definition of Microservice Bad Smells”涉及非常多的微服务不良做法，但如果要用几个大类别来列举危害性比较大的微服务反模式，您认为会是哪几类？另外，您能再大概分析说明下造成这个几个反模式的原因吗？

Davide Taibi：就我个人而言，最坑的反模式存在于组织中，而非技术之罪。技术上的反模式很容易修复(如，循环依赖)，而解决组织上的问题没那么简单。比如，错误的开发团队分组将团队按水平功能划分而不是垂直划分(分成数据库团队、前端团队、后台团队)。
另一种组织结构问题可被称为“微服务贪心（Microservice Greedy）”，指的是开发者对于任何可能的功能都创建新的微服务。他们都没有查看是否能重用代码，甚至确认这个功能是不是已经存在就开始实现了。结果就导致微服务数量暴涨，结构迅速退化， 维护的复杂度和成本也随之激增。

InfoQ：对于当前并不确定是否要选择云原生架构的企业，您有哪些建议？
Davide Taibi：我给一些还不确定时候应用云原生架构的企业的建议是，真实考量
你的需求，你的组织结构，以及公司开发者的经验。
如果有庞大数量的开发团队致力于不同的系统功能，你可以考虑微服务。如果有些
功能你需要极限可扩展性，那么你可以考虑无服务方法。其他的情形都需要准确地考量。
考虑到架构迁移的成本和影响，雇佣有经验的咨询顾问是很明智的。他们会提供一
个“外来人”的视角在作出重要决定之前对企业和系统进行合理评估。

InfoQ：最近谷歌开源了Service Weaver，谷歌称此框架为模块化单体（modular monolith），称其能兼顾单体应用的开发速度，以及微服务的可扩展性、安全性和容错性。但有人认为这就是一种“分布式单体”。您能解析对比分布式单体与模块化单体 之间的异同吗？
Davide Taibi：在我看来，“分布式单体”只是对于“维护不了的分布式系统”的一种误导性的称呼。
我坚决同意一个设计优良具有模块化功能的单体系统维护起来可以很简单。但主要的问题不是软件本身而在于组织结构。过大的组织结构将导致团队缺少独立部署的能力。