系统软件架构中，现在很流行微服务，那么使用微服务就一定好么？微服务有哪些缺点呢？

“微服务”不是银弹，解决不了所有问题，有其自己的适应场景。我大致总结了如下场景：

• 业务发展较快，希望能在后期快速的支撑爆发增长的访问量（首先确认是不是真的业务发展很快）
• 业务非常复杂，且有很多不确定性，可以考虑领域驱动设计+微服务实现
• 项目很大，人员很多，考虑切分为多个小组进行微服务开发
• 需要整合很多的老系统，可以考虑微服务的sidecar模式或者SOA
• 希望在公司层面构建一套统一的业务技术平台。登陆，文件服务，日终服务等，由业务平台提供，开发人员只需要关注业务服务

相对的，需要快速落地的简单业务就不适合微服务，后期维护成本远超成本。

就像，大型超市有多个收银台，小超市也搞多个收银台，营业额还不够发人员工资的。

微服务在使用过程中开发、测试、部署等环节十分便捷，整体是以松耦合高内聚的形式存在，符合IT技术思想。但是在实际使用过程中，还是存在一些不足，比如在开发微服务时，对于服务粒度的设计需要对业务理解比较深刻；客户端调用微服务耗时比较严重，随着需求的迭代，管理难度越来越大，服务间耦合度开始增强，代码难以复用和修改等等。