微服務入門指南(一)——走進微服務的世界

本文是微服務入門系列的第三篇文章，本系列一共有以下內容：
1.《走進微服務的世界》
2.《微服務架構下的分佈式事務基礎入門》
3.《微服務架構下的分佈式事務解決方案》
4.《數據庫的服務化切分》
5.《服務部署》

1. 什麼是微服務？

咱們首先給出微服務的定義，而後再對該定義給出詳細的解釋。

微服務就是一些可獨立運行、可協同工做的小的服務。

從概念中咱們能夠提取三個關鍵詞：可獨立運行、可協同工做、小。這三個詞高度歸納了微服務的核心特性。下面咱們就對這三個詞做詳細解釋。

1. 可獨立運行

   微服務是一個個能夠獨立開發、獨立部署、獨立運行的系統或者進程。

2. 可協同工做

   採用了微服務架構後，整個系統被拆分紅多個微服務，這些服務之間每每不是徹底獨立的，在業務上存在必定的耦合，即一個服務可能須要使用另外一個服務所提供的功能。這就是所謂的「可協同工做」。與單服務應用不一樣的是，多個微服務之間的調用時經過RPC通訊來實現，而非單服務的本地調用，因此通訊的成本相對要高一些，但帶來的好處也是可觀的。

3. 小而美

   微服務的思想是，將一個擁有複雜功能的龐大系統，按照業務功能，拆分紅多個相互獨立的子系統，這些子系統則被稱爲「微服務」。每一個微服務只承擔某一項職責，從而相對於單服務應用來講，微服務的體積是「小」的。小也就意味着每一個服務承擔的職責變少，根據單一職責原則，咱們在系統設計時，要儘可能使得每一項服務只承擔一項職責，從而實現系統的「高內聚」。

2. 微服務的優勢

1. 易於擴展

在單服務應用中，若是目前性能到達瓶頸，沒法支撐目前的業務量，此時通常採用集羣模式，即增長服務器集羣的節點，並將這個單服務應用「複製」到全部的節點上，從而提高總體性能。然而這種擴展的粒度是比較粗糙的。若是隻是系統中某一小部分存在性能問題，在單服務應用中，也要將整個應用進行擴展，這種方式簡單粗暴，沒法對症下藥。而當咱們使用了微服務架構後，若是某一項服務的性能到達瓶頸，那麼咱們只須要增長該服務的節點數便可，其餘服務無需變化。這種擴展更加具備針對性，可以充分利用計算機硬件/軟件資源。並且只擴展單個服務影響的範圍較小，從而系統出錯的機率也就越低。

2. 部署簡單

對於單服務應用而言，全部代碼均在一個項目中，從而致使任何微小的改變都須要將整個項目打包、發佈、部署，而這一系列操做的代價是高昂的。久而久之，團隊爲了下降發佈的頻率，會使得每次發佈都伴隨着大量的修改，修改越多也就意味着出錯的機率也越大。
當咱們採用微服務架構之後，每一個服務只承擔少數職責，從而每次只須要發佈發生修改的系統，其餘系統依然可以正常運行，波及範圍較小。此外，相對於單服務應用而言，每一個微服務系統修改的代碼相對較少，從而部署後出現錯誤的機率也相對較低。

3. 技術異構性

對於單服務應用而言，一個系統的全部模塊均整合在一個項目中，因此這些模塊只能選擇相同的技術。但有些時候，單一技術沒辦法知足不一樣的業務需求。如對於項目的算法團隊而言，函數試編程語言可能更適合算法的開發，而對於業務開發團隊而言，相似於Java的強類型語言具備更高的穩定性。然而在單服務應用中只能互相權衡，選擇同一種語言，而當咱們使用微服務結構後，這個問題就可以引刃而解。咱們將一個完整的系統拆分紅了多個獨立的服務，從而每一個服務均可以根據各自不一樣的特色，選擇最爲合適的技術體系。

固然，並非全部的微服務系統都具有技術異構性，要實現技術異構性，必須保證全部服務都提供通用接口。咱們知道，在微服務系統中，服務之間採用RPC接口通訊，而實現RPC通訊的方式有不少。有一些RPC通訊方式與語言強耦合，如Java的RMI技術，它就要求通訊的雙方都必須採用Java語言開發。固然，也有一些RPC通訊方式與語言無關，如基於HTTP協議的REST。這種通訊方式對通訊雙方所採用的語言沒有作任何限制，只要通訊過程當中傳輸的數據遵循REST規範便可。固然，與語言無關也就意味着通訊雙方沒有類型檢查，從而會提升出錯的機率。因此，究竟選擇與語言無關的RPC通訊方式，仍是選擇與語言強耦合的RPC通訊方式，須要咱們根據實際的業務場景合理地分析。