微服务不是灵丹妙药，有一利必有一弊，就象同样的事情，交给一个人做与交给一群人做，差别巨大。
一个人做的好处是无沟通协调的成本，出了问题只需找一个人，一个人多半就能搞定，坏处是没有备份，容易过载和出现瓶颈，只能串行，无法并行，能做多快，做多好，得看个人能力，态度，甚至心情。
一群人做的好处是可以群策群力, 发挥集体的力量与智慧, 齐头并进, 一两人请假或者状态不好, 其他人可以顶上.坏处也不言而喻, 一颗老鼠屎可以坏了一锅汤, 沟通协作成本直线上升, 出了问题搞不清谁该负责, 诊断问题得找多个人, 工作上形成依赖关系的也会有瓶颈和串行等待的情况.
微服务的好处不必多言
- 微服务架构给开发者一定的自由来自主开发和部署服务
- 微服务可以由一个相当小的团队开发
- 不同服务的代码可以用不同的语言编写（也别太多, 三四种足矣, 我们这边只用 C++, Java 和 Python）
- 易于集成和自动部署（使用开源持续集成工具，如Jenkins，Hudson等）
- 易于理解和修改, 新人可以快速上手
- 开发者可以利用最新的技术
- 代码围绕业务功能进行组织
- 更快速地启动，所以部署速度也更快
- 当应用程序的某个部分需要更改时，只需修改和重新部署相关服务, 而无需修改和重新部署整个应用程序
- 更好的故障隔离：如果一个微服务出现故障，另一个将继续工作（但如果被依赖的其他也可能出问题, 从而危及整个系统）
- 易于扩展和与第三方服务集成
- 没有长期的技术栈要求和限制
它的局限也很明显
- 由于分布式部署, 测试变得更加复杂和麻烦
- 不断增长的微服务数量会导致信息屏障, 可以没人能搞得清所有微服务是干什么的
- 必须应对分布式系统固有的各种常见故障, 处理各种网络延迟, 抖动, 丢包, 分流, 重试, 超时, 一个也不能少
- 为高可用需要做足够的备份, 冗余, 为防止雪崩效应, 还要容错, 分流, 限流, 断流, 必要的故障与灾难恢复
- 在一起协作的微服务越多, 整个产品的集成和管理会越复杂, 微服务简单了, 整个系统却复杂了
- 为应对分布式系统的复杂性, 状态和事务管理不同步的问题会更加突出
- 问题的发现与诊断更加困难, 需要多个微服务和相关团队共同协作解决
- 微服务的无状态架构可能会导致由网络和存储读取变多而引起性能上的损失
