微服務架構與實踐
概述:
傳統架構中，一個項目的開發 測試 發佈都是在單一節點完成的，這樣做的好處是開發簡單，測試方便，部署也是打包就一鍵部署了，隨着項目的不斷變大以，業務的縱向延伸以及節點的橫向擴展，開發的難度在數量級的倍增，單節點的開發不在合適中大型項目，微服務架構應運而生。
相比傳統的單節點的開發，微服務架構把項目各種切割成很多微服務，微服務可以單獨部署發佈，不同微服務之間可以通過輕量級的通信機制進行溝通，業務解耦合，分佈式開發是微服務的精髓
微服務的本質和特性
1.1 服務作爲組件
劃分的不同單元模塊可以進行獨立部署，不影響其他服務
1.2 技術多樣性單一架構的項目很難使用不同的語言，微服務之間可以通過接口進行輕量級通信，不同服務對語言沒有要求，可以選擇最合適的語言進行
1.3業務獨立性
傳統業務架構傾向於使用數據存儲平臺來進行不同系統之間的集成，微服務架構可以根據不同微服務選擇合適自己的數據庫，
提供業務數據接口集成微服務之路並不是一馬平川的，微服務的挑戰
2.1 性能
微服務的互相通信需要跨網絡，跨進程，網絡延遲和性能會影響業務的運行
2.2 可靠性
單節點故障造成的系統無法運行
2.3 異步對於需要及時返回的通信請求，會使用異步進行處理以免造成消息阻塞，但同時增加了開發的難度
2.4 數據一致性
分佈式系統中爲了保證數據一致性通常會使用分佈式事務管理，由於分佈式事務管理會在多個節點保證事務的一致性因爲比起
單節點的架構的事務，其成本要高的多。通常我們也會考慮數據的最終一致性來解決數據的瞬時一致性造成的
系統的不可用。
3微服架構的基礎組件
3.1 分佈式日誌收集合並 splunk
將分佈式的日誌收集合併到一個節點，強大的搜索查詢功能，可設置報警告知等
3.2 本機狀態監控報警 nagios
本機性能監控，監控cpu，網絡服務，主機資源，有web頁面，學習成本低
3.3 一次鏡像 到處安裝 Docker
開源的liunx應用容器，安裝部署一次docker鏡像，能夠在各個節點上進行部署運行，降低了維護成本
3.4 異步通信 MQ或者後臺處理系統
在節點之間通信的時候，通常是http，其基於tcp/ip 並不是一個低延遲的方式，如果需要低延遲，可以藉助第三方組件，如rabbitmq，activemq。如果覺得這種方式比較重，那麼可以考慮採用輕量級後臺任務處理系統
小結:
<<微服務架構和實踐>> 一書的實戰性極強，簡述了搭建微服務的基本知識面，適合初次接觸的學者，書中知識面廣，深度不深，適合初學者。