1.微服务之间通信

　　http 

2.动态伸缩 解决并发量的问题

　　consul 注册中心

3.容错机制 解决高可用的问题

　　故障转移 while 

　　3.1while有个缺点，当实例全部宕机的时候出现死循环，消耗性能，直到内存耗尽

　　3.2改为for循环，设定一个阀值，超出阀值则抛出异常

　　3.2.1恰巧取到的地址都是宕机的地址，而正常却没有调用到

　　设置一个异常列表，服务检查（排除异常的服务），以保证每次请求都是正常的地址

　　3.2.2如果宕机的服务正常了，怎么动态移除异常列表中的数据

　　通过consul watch

　　3.2.1.1 for 阀值 还有缺陷 ，全部宕机，希望直接返回，而不是一直重试，这个时候可以使用熔断机制

　　polly

4.网关 ocelot

5.配置中心

consul  nacos

6.微服务事务

 　　一.2pc

　　　　预提交与提交

　　　　协调器与参与者都是单体的

　　　　缺点：单点故障问题、阻塞问题、数据一致性问题

　　二.3pc 　　

　　　　检查提交  预提交  提交 

　　　　加了一个新阶段：目的保证数据一致性，防止数据库在调用过程中被锁住

　　　　超时机制：解决阻塞问题，如果协调器等待参与者超时，则回滚

　　　　　　　　　　　　　　　　如果参与者等待协调器超时，则事务提交

　　　　缺点：也存在数据不一致性的问题

　　三.TCC（2阶段补偿事务）

　　　　2pc\3pc时时刻刻都要保证数据一致性（协调器与参与者永远可以运行-网络永远可以连通）

　　　　最终一致性

　　　　try commit cancel

　　　　缺点：脏数据、业务复杂性、Tcc性能瓶颈

　　四。Sage  

　　　　TCC一个数据交互，涉及到3次数据库业务操作（Sage3次变2次）

　　　　TCC协调器必须等待参与者执行完成try，才能进行下一步，如果并发量起来，就会出问题（Sage不等待）

　　　　1.所有事务都是独立的