明明
初入微服務，時代在召喚，現在開始！
隨著互聯網的進步，流量越來越龐大，單一系統逐漸向分佈式，微服務化發展，以避免單一系統宕機引起的服務停滯！而向微服務遷移也並不是一帆風順的，會有服務架構不穩定，數據一致性難保證等問題！
微服務的優點:
1，服務之間解耦！
2，單個服務可獨立擴展！
3，各個服務單獨部署，甚至做成負載均衡系統
4，對外透明！
既然已經選擇了微服務，肯定是知道其有點的，但是存在哪些挑戰呢？
1，單個服務獨立部署，運維成本高！
2，單個服務容易宕機，停止服務！
3，機器太多，問題更難定位！
4，雪崩問題:（單個服務宕機引起整個系統的崩潰）
5，數據一致性難保證！
運維暫且不談！
如何防止單個服務宕機和雪崩？①對併發壓力大的單個服務利用nginx搭建服務集群，保證單個服務的穩定性！②使用hystrix熔斷器，防止反覆調用引起雪崩！
問題怎麼定位？問題日誌可能分佈在一個集群裡面N臺機器上，一個一個打開找日誌？NO！使用集中式日誌處理，將日誌在統一的機器上進行打印和文件
數據一致性怎麼保證？由於網絡延遲，硬件故障等引起分佈式系統上的數據不能保持一致的問題，可以說是經久不衰的討論話題，而長期以來的解決方案一共有下面四種:
1，基於XA協議的兩階段提交方案！
2，TCC方案（try，confirm，cancel）！
3，基於分佈式消息系統的最終一致性方案！
4，阿里的GTS！
因為系統是分佈式的，所以沒法保證事務的同時進行，所有的這些分佈式事務都是異步調用，確認的解決方案！各種解決方案也會出現不同的問題，比如應用侵入性強，開發量大，性能影響等！ 
選擇合適的方案加上合理的架構，對單個服務使用負載均衡，使用熔斷器，根據業務合理的進行接口重試，冪等性原則防止數據重複，增加外掛手動補償等方式解決雪崩和數據一致性問題！由於篇幅原因，具體的解決方案會在以後提及！
本人一直致力於分佈式，微服務，消息中間件，多線程等的研究和應用，如果你感興趣，敬請關注。。。
