微服务三大特点：高可用、高性能、高并发
轻应用 docker RPC
轻应用
沙箱机制
缺点：微服务成本，可以采用docker缩减
没有银弹：没有简单的方法解决复杂的软件工程问题
微服务需要解决事务一致性，解决高可用，服务阻塞导致雪崩
微服务还是存在依赖性，部署复杂
角色权限基于RBAC
不要考虑使用什么方法，只要这个方法能实现这个目标
paas服务，如阿里的cloud foundry，提供简单方式部署和管理微服务，成本高，云计算
自己开发：集群方案kubernetes,与docker等容器技术相结合。
分布式存在分库分表，表分区，存在事务性问题，耦合问题
CAP定理： 一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（partition tolerance）这三项中的两项。
1、一致性：更新操作成功 并返回客户端完成后，所有节点在同一时间的数据完全一致。
(1)强一致性，要么一起成功，要么一起失败
(2)弱一致性
(3)顺序一致性
2、可用性：服务一直可用，而且是正常响应时。
3：分区容错性：分布式系统在遇到某节点或网络分区故障的时候，仍然能够满足对外提供满足一致性和可用性的服务，（数据同步问题）
通过地区，采取cdn分发
分两种系统：CP系统 金融系统(双花问题，跟钱有关系，必须一致)
AP系统
BASE理论：是CAP理论的延伸，核心思想是即使无法做到强一致性，但应用可以采用合适的方式打到最终一致性（为了解决CAP强约束）
1、基本可用：基本可用是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。例如电商页面访问量激增，部分用户引导到降级页面，服务层也可能只提供降级服务。这就是损失部分可用性的体现。
2、软状态：软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少有三个副本，允许不同节点间副本同步的延时就是软状态的体现。MySQL Replication 的异步不知也是一种体现。
3、最终一致性：最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到的一种状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。
异地多活
异地双活
问：为何异地多活不采用uuid，采用何种办法解决？
答：因为字符串影响数据库搜索，这里采用分布式ID来解决这个问题。