住手！！你不需要微服务！

受益者将微服务架构应用于他们即将推出的产品，他们寻求一番肯定。

仲裁小组中相当多的人不懂技术。而随着交谈的“技术性越来越强”，交谈对于仲裁变得无关紧要了。

长时间的停顿和无人提问表明大家对Web服务不熟悉，对微服务不熟悉更不用说了。

增加了复杂性——当然，复杂性无法量化，只能以相对的方式进行比较。虽然微服务原本旨在通过将应用程序分解成小组件来降低复杂性，但架构本身部署和维护起来却很复杂。

分布成本——微服务是具有模块性的分布式系统。但是同样的分布确实要付出代价。你的整体式服务会部署在大型虚拟机或首选容器上。但如果是微服务，除了多个虚拟机或容器外，服务需要独立部署[在理想的环境上]。当然服务可能很小，但你可以计算一下总成本。记住，我甚至还没有谈到服务编排和维护涉及的成本。

改编Devops——这可能有益也可能有害，取决于你所站的角度。Devops是一种被广泛接受且经过验证的运维解决方案。但如果你是小型企业组织的成员，成立一支Devops团队会是弊大于利。不过有一点倒可以肯定，要是没有专门的devops团队，你就无法维护和监控微服务。

集成紧密——一些应用程序天生就紧密耦合。将它们分开来以“适应”架构将会带来灾难。

缺乏经验——缺乏经验对任何问题来说都是重要因素，并不仅限于SOA。但是说到微服务，由于拥有抽象定义，造成的危害尤其大。如果你的微服务部署因部署顺序而将你逼到被动的地步，或者某一个依赖项服务出故障后导致崩溃，那么你为时已晚。

端到端测试——一个典型的整体式应用程序将使你可以几乎立即启动并运行测试。若没有切实可行的编排，有多个相互依赖的服务会延误测试。

混乱的数据合约——在团队内部设计和订有数据合约与团队之间共享数据合约大不相同。你在接触微服务时，你的团队可能不在同一个地区，更不要说团队成员都采用同一种编程语言了。为特定要求制定数据合约会耗费你的时间和空间。

遗留代码库——老实说吧。对于我们大多数人来说，处理遗留代码库是一项日常工作。它是大多数企业组织的立足之本。迅速变化的技术进步让我们处于领先，而同时也使我们离遗留代码库渐行渐远。

你确信刚开发的RabbitMQ框架可以与托管在IBM AIX服务器上的遗留应用程序很好地兼容吗？

调试令人痛苦——每个服务都会有自己的一组日志文件要审查。更多服务意味着更多的日志文件。