初入微服務，時代在召喚，現在開始！

隨著網際網路的進步，流量越來越龐大，單一系統逐漸向分散式，微服務化發展，以避免單一系統宕機引起的服務停滯！而向微服務遷移也並不是一帆風順的，會有服務架構不穩定，資料一致性難保證等問題！

微服務的優點:

1，服務之間解耦！

2，單個服務可獨立擴充套件！

3，各個服務單獨部署，甚至做成負載均衡系統

4，對外透明！

既然已經選擇了微服務，肯定是知道其有點的，但是存在哪些挑戰呢？

1，單個服務獨立部署，運維成本高！

2，單個服務容易宕機，停止服務！

3，機器太多，問題更難定位！

4，雪崩問題:（單個服務宕機引起整個系統的崩潰）

5，資料一致性難保證！

運維暫且不談！

如何防止單個服務宕機和雪崩？①對併發壓力大的單個服務利用nginx搭建服務叢集，保證單個服務的穩定性！②使用hystrix熔斷器，防止反覆呼叫引起雪崩！

問題怎麼定位？問題日誌可能分佈在一個集群裡面N臺機器上，一個一個開啟找日誌？NO！使用集中式日誌處理，將日誌在統一的機器上進行列印和檔案

1，基於XA協議的兩階段提交方案！

2，TCC方案（try，confirm，cancel）！

3，基於分散式訊息系統的最終一致性方案！

4，阿里的GTS！

因為系統是分散式的，所以沒法保證事務的同時進行，所有的這些分散式事務都是非同步呼叫，確認的解決方案！各種解決方案也會出現不同的問題，比如應用侵入性強，開發量大，效能影響等！

選擇合適的方案加上合理的架構，對單個服務使用負載均衡，使用熔斷器，根據業務合理的進行介面重試，冪等性原則防止資料重複，增加外掛手動補償等方式解決雪崩和資料一致性問題！由於篇幅原因，具體的解決方案會在以後提及！

本人一直致力於分散式，微服務，訊息中介軟體，多執行緒等的研究和應用，如果你感興趣，敬請關注。。。

微服務架構系統靈活性，健壯性，擴充套件性好，特別適合需求變化迅速的場景。但系統複雜度高，部署，管理難度大。微服務除了開發期框架之外，還有需要一系列的執行期中介軟體支撐，如API閘道器，服務註冊中心，統一配置中心等。 目前國內比較成熟的吧，東軟有一支團隊在做，他們網站是 https://platform.neusoft.com/