大話微服務架構

一：什麼是微服務？什麼是微服務架構？？

　　微服務：

微服務架構：是一種架構概念，旨在經過將功能分解到各個離散的服務中以實現對解決方案的解耦。你能夠將其看做是在架構層次而非獲取服務的。微服務架構是個頗有趣的概念，它的主要做用是將功能分解到離散的各個服務當中，從而下降系統的耦合性，並提供更加靈活的服務支持。

二：微服務的好處？？（不足）

　　好處：

 在傳統的IT行業軟件大多都是各類獨立系統的堆砌，這些系統的問題總結來講就是擴展性差，可靠性不高，維護成本高。到後面引入了SOA服務化，可是，因爲 SOA 早期均使用了總線模式，這種總線模式是與某種技術棧強綁定的，好比：J2EE。這致使不少企業的遺留系統很難對接，切換時間太長，成本過高，新系統穩定性的收斂也須要一些時間。最終 SOA 看起來很美，但卻成爲了企業級奢侈品，中小公司都望而生畏。

首先，經過分解巨大單體式應用爲多個服務方法解決了複雜性問題。在功能不變的狀況下，應用被分解爲多個可管理的分支或服務。每一個服務都有一個用RPC-或者消息驅動API定義清楚的邊界。微服務架構模式給採用單體式編碼方式很難實現的功能提供了模塊化的解決方案，由此，單個服務很容易開發、理解和維護。

第二，這種架構使得每一個服務均可以有專門開發團隊來開發。開發者能夠自由選擇開發技術，提供API服務。固然，許多公司試圖避免混亂，只提供某些技術選擇。而後，這種自由意味着開發者不須要被迫使用某項目開始時採用的過期技術，他們能夠選擇如今的技術。甚至於，由於服務都是相對簡單，即便用如今技術重寫之前代碼也不是很困難的事情。

第三，微服務架構模式是每一個微服務獨立的部署。開發者再也不須要協調其它服務部署對本服務的影響。這種改變能夠加快部署速度。UI團隊能夠採用AB測試，快速的部署變化。微服務架構模式使得持續化部署成爲可能。

最後，微服務架構模式使得每一個服務獨立擴展。你能夠根據每一個服務的規模來部署知足需求的規模。甚至於，你可使用更適合於服務資源需求的硬件。好比，你能夠在EC2 Compute Optimized instances上部署CPU敏感的服務，而在EC2 memory-optimized instances上部署內存數據庫。

不足：

其中一個跟他的名字相似，『微服務』強調了服務大小，實際上，有一些開發者鼓吹創建稍微大一些的，10-100 LOC服務組。儘管小服務更樂於被採用，可是不要忘了這只是終端的選擇而不是最終的目的。微服務的目的是有效的拆分應用，實現敏捷開發和部署。

另一個主要的不足是，微服務應用是分佈式系統，由此會帶來固有的複雜性。開發者須要在RPC或者消息傳遞之間選擇並完成進程間通信機制。更甚於，他們必須寫代碼來處理消息傳遞中速度過慢或者不可用等局部失效問題。固然這並非什麼難事，但相對於單體式應用中經過語言層級的方法或者進程調用，微服務下這種技術顯得更復雜一些。

另一個關於微服務的挑戰來自於分區的數據庫架構。商業交易中同時給多個業務分主體更新消息很廣泛。這種交易對於單體式應用來講很容易，由於只有一個數據庫。在微服務架構應用中，須要更新不一樣服務所使用的不一樣的數據庫。使用分佈式交易並不必定是好的選擇，不只僅是由於CAP理論，還由於今天高擴展性的NoSQL數據庫和消息傳遞中間件並不支持這一需求。最終你不得不使用一個最終一致性的方法，從而對開發者提出了更高的要求和挑戰。

測試一個基於微服務架構的應用也是很複雜的任務。好比，採用流行的Spring Boot架構，對一個單體式web應用，測試它的REST API，是很容易的事情。反過來，一樣的服務測試須要啓動和它有關的全部服務（至少須要這些服務的stubs）。再重申一次，不能低估了採用微服務架構帶來的複雜性。

另一個挑戰在於，微服務架構模式應用的改變將會波及多個服務。好比，假設你在完成一個案例，須要修改服務A、B、C，而A依賴B，B依賴C。在單體式應用中，你只須要改變相關模塊，整合變化，部署就行了。對比之下，微服務架構模式就須要考慮相關改變對不一樣服務的影響。好比，你須要更新服務C，而後是B，最後纔是A，幸運的是，許多改變通常隻影響一個服務，而須要協調多服務的改變不多。

部署一個微服務應用也很複雜，一個分佈式應用只須要簡單在複雜均衡器後面部署各自的服務器就行了。每一個應用實例是須要配置諸如數據庫和消息中間件等基礎服務。相對比，一個微服務應用通常由大批服務構成。例如，根據Adrian Cockcroft，Hailo有160個不一樣服務構成，NetFlix有大約600個服務。每一個服務都有多個實例。這就形成許多須要配置、部署、擴展和監控的部分，除此以外，你還須要完成一個服務發現機制（後續文章中發表），以用來發現與它通信服務的地址（包括服務器地址和端口）。傳統的解決問題辦法不能用於解決這麼複雜的問題。接續而來，成功部署一個微服務應用須要開發者有足夠的控制部署方法，並高度自動化。

三：傳統開發模式與微服務的區別

　　

 四：經常使用的微服務框架