微服务架构的优缺点，适合场景。

参考：here，here。

优点：

1. 易于开发和维护：一个服务只关注一个特定的业务功能，代码量少。
2. 单个服务启动快(因为代码量少)
3. 局部修改易部署：对单体架构而言，只要有修改，就得重新部署整个应用，微服务解决了整个问题，对某个微服务进行修改，只需要重新部署这个服务即可。
4. 技术栈不受限：在微服务架构中，可结合业务和团队特点合理选用技术栈。例如部分服务可以使用关系型数据库MySQL，部分服务可以使用非关系型数据库Redis，甚至可根据需求，部分服务使用Java开发，部分微服务使用Node.js开发。
5. 按需收缩：可以根据需求，实现细粒度的扩展。(例如系统中的某某个微服务遇到了瓶颈，可以结合微服务的特点，增加内存、升级CPU或增加节点。)

缺点：

1. 运维要求高：更多服务意味着更多的运维投入，在单体架构中，只需要保证一个应用的运行即可，在微服务架构中，需要保证几十甚至几百个服务器的正常运行和协作。
2. 分户式固有的复杂性：使用微服务架构的是分布式系统。对于一个分布式系统，系统容错，网络延迟都会带来巨大挑战。
3. 接口成本高：微服务之间通过接口进行通信。

应用场景：

　　淘宝+支付宝+微信+微博(目前苹果或者安卓系统手机上的应用，基本上都是微服务架构，其业务模式决定了架构不可能采用一种单体架构取解决所有问题。)

　　电商类、微博微信社交类、支付类、直播类、游戏类等业务都适合，一个架构的拆分，本质上反映的是一个业务的拆分。

【Over】