明明
初入微服务，时代在召唤，现在开始！
随着互联网的进步，流量越来越庞大，单一系统逐渐向分布式，微服务化发展，以避免单一系统宕机引起的服务停滞！而向微服务迁移也并不是一帆风顺的，会有服务架构不稳定，数据一致性难保证等问题！
微服务的优点:
1，服务之间解耦！
2，单个服务可独立扩展！
3，各个服务单独部署，甚至做成负载均衡系统
4，对外透明！
既然已经选择了微服务，肯定是知道其有点的，但是存在哪些挑战呢？
1，单个服务独立部署，运维成本高！
2，单个服务容易宕机，停止服务！
3，机器太多，问题更难定位！
4，雪崩问题:（单个服务宕机引起整个系统的崩溃）
5，数据一致性难保证！
运维暂且不谈！
如何防止单个服务宕机和雪崩？①对并发压力大的单个服务利用nginx搭建服务集群，保证单个服务的稳定性！②使用hystrix熔断器，防止反复调用引起雪崩！
问题怎么定位？问题日志可能分布在一个集群里面N台机器上，一个一个打开找日志？NO！使用集中式日志处理，将日志在统一的机器上进行打印和文件
数据一致性怎么保证？由于网络延迟，硬件故障等引起分布式系统上的数据不能保持一致的问题，可以说是经久不衰的讨论话题，而长期以来的解决方案一共有下面四种:
1，基于XA协议的两阶段提交方案！
2，TCC方案（try，confirm，cancel）！
3，基于分布式消息系统的最终一致性方案！
4，阿里的GTS！
因为系统是分布式的，所以没法保证事务的同时进行，所有的这些分布式事务都是异步调用，确认的解决方案！各种解决方案也会出现不同的问题，比如应用侵入性强，开发量大，性能影响等！ 
选择合适的方案加上合理的架构，对单个服务使用负载均衡，使用熔断器，根据业务合理的进行接口重试，幂等性原则防止数据重复，增加外挂手动补偿等方式解决雪崩和数据一致性问题！由于篇幅原因，具体的解决方案会在以后提及！
本人一直致力于分布式，微服务，消息中间件，多线程等的研究和应用，如果你感兴趣，敬请关注。。。
