1. 微服务架构的优点
- 庞大的单体程序 -> 一套微型程序。 每一个服务有明确的边界(服务之间的消息通讯机制) ，每一个服务都能单独的开发和维护，并且更好理解
- 每一个服务都能由一个团队来开发，当然开发者对技术的选型可以*选择，即使某一个服务的技术过时或者有缺陷，都可以在很小的成本下进行技术升级，减少系统改造的成本
- 每一个服务独立部署，功能开发完成之后可以直接进行部署。
- 每一个服务可以根据当前服务的性质，选择适合的硬件进行部署，比如 对于计算能力强的 但是存储要求不高的模块，可以部署在cpu能力强但是硬件存储少的服务器，对于需要做存储而不需要太多运算的情况，可能选择对应的硬件模式
2.微服务架构的缺点
- 多个服务的产生也会使系统的架构变得复杂，每个服务之间必须实现服务间的通讯协议
- 对于服务间请求慢，或者请求失败的情况，各个服务需要实现对应的错误处理
- 分区数据库架构，服务之间的事物处理，不同服务可能采用的不同的数据库，并且有些nosql数据库根本不支持事物，所以开发人员不得不采用最终一致性来保证数据
- 服务代码的测试，一个服务的测试需要启动跟该服务关联的所以服务，依赖的服务越多，服务的测试就越困难
- 服务的变更，服务之间的依赖导致某一个被依赖的服务如果重启的话，我们所测试的服务也必须重启，并且服务之间的依赖顺序也限制了我们服务的启动顺序
- 服务器的布置，随着服务的增加，服务器的数量呈倍数增长。
- 需要实现服务的发现机制，使得服务能发现需要与之通讯的其他任何服务的位置
TIP: CAP定理
一个分布式系统最多满足，一致性，可用性，分区容错性 三项中的两项 （是指在一个服务中）
- 一致性：是指更新操作成功并返回客户端后，所有节点在同一时刻数据是一致的 （最终结果是一致的）
- 可用性：服务一直可用，并且是正常响应时间 （正常响应的时间间隙，也就是部署的多个同一服务之间的数据库数据在数据同步的这段时间 数据库中的数据可能是不一致的）
- 分区容错性：是指在分布式服务某一个节点故障之后，某个节点仍能对外提供满足 一致性，可用性的服务
那么如何取舍：
- 在大型网络应用，一般选择AP 舍弃 C 但是会用最终一致性来弥补 C
- 在关于钱财方面(银行案例) C是底线 保证CP 舍弃A, 系统可以通过阻止数据的插入来确保CP
3.微服务如何应对高并发
- 垂直扩展
- 增加硬件设备
- 使用缓存替代IO，使用异步来替代同步 等
不管怎么说，对于单体硬件的扩展始终是有极限的，所以垂直扩展的方式并不适用于大型的互联网项目
- 水平扩展
- 增加服务器数量，以请求分发的模式减少服务的压力
TIPS: 数据库分库分表分区 可以根据字段的 某一个位置选择使用 水平扩展出来的某一个库 某一个字段与库1-1对应，再选择一个字段与库中的某一个表 1-1对应 ，再选择一个字段与 表中的分区 1-1对应