Node.js微服務實踐(一)

什麼是微服務

微服務是一種架構風格，一個大型複雜軟件應用由一個或多個微服務組成。系統中的各個微服務可被獨立部署，各個微服務之間是鬆耦合的。每一個微服務僅關注於完成一件任務並很好地完成該任務。在全部狀況下，每一個任務表明着一個小的業務能力。

微服務的概念源於2014年3月Martin Fowler所寫的一篇文章「Microservices」(martinfowler.com/articles/mi…)。

儘管「微服務」這種架構風格沒有精確的定義，但其具備一些共同的特性，如圍繞業務能力組織服務、自動化部署、智能端點、對語言及數據的「去集中化」控制等等。微服務架構的思考是從與總體應用對比而產生的。

一般，在一家公司隨着業務需求的增加爲逐步發展（天然增加）的過程當中，前期每每是以單塊架構的方式來組織系統的。由於對於軟件的初期構建來講，單塊架構的方式是最容易且最高效的。可是若干年（甚至是幾個月）後，受限於前期既有單塊軟件系統內部耦合性，再向該系統加新功能變得愈來愈艱難。

單塊軟件

企業應用，由於服務於衆多業務需求，所以會有些特定的軟件應用提供許多功能，而通常慣例是把這些功能都堆在單個單片應用中。例如，ERP，CRM和其餘各類軟件系統被規劃構建爲具備數百個功能的總體。這種帶坑應用一經部署，在日後的故障排除、擴展和升級場景中就是一場接一場的惡夢了。

面向服務架構（SOA）旨在經過引入「服務」的概念來克服以上的限制，「服務」是從應用程序提供的相似功能中提取出來的聚合和分組。所以，使用SOA，軟件應用程序就會被設計爲「粗粒度」服務的組合。然而，SOA中服務的範圍很是普遍，這又引出了複雜而龐大的服務與一大堆操做（功能）以及複雜無比的消息格式和標準（如WS *標準）。

多數狀況下，SOA中的服務彼此獨立，只不過它們與全部其餘服務一塊兒部署在相同的運行時間裏（只需考慮將部署到同一個Tomcat實例中的多個Web應用）。和單片軟件應用相似，這些服務經過積累各類功而具備隨時間推移的習慣。圖1是一個很是好的一個單片架構的例子，顯示了包括多個服務的零售軟件應用，全部這些服務都能部署到同一應用程序。

說了那麼多，你們是否是有點不明因此？我總結了一些重點，如下就是基於單快軟件架構的應用程序的一些特性概括：

• 單片應用程序被設計、開發和部署爲單個單元。
• 單片應用相對複雜，致使維護，升級和新特性困難重重。
• 難以用單片架構來實踐敏捷開發和交付方法。
• 想更新某部分，極可能要從新部署整個應用。
• 規模需求衝突的狀況下，若想作單點擴展，要作好多倍資源甚至推倒重來的準備（例如，想給A服務更多CPU，B服務可能要重作，也可能要補兩三倍memory）
• 可靠性：一個不穩定的服務能夠拖慢整個應用性能。
• 難創新：採用新技術和框架很是困難，由於全部的功能必須創建在均勻的技術/框架上。

面向微服務的架構

面向微服務的架構擁有一些特質。任意規模的大中型公司若是想讓自身IT系統保持彈性，並但願隨時均可以對系統規模進行伸縮的話，一定會對這些特質趨之若鶩。

爲何面向微服務的架構更好

微服務架構（MSA）的基礎是將單片應用做爲一套小型和獨立服務來開發，這些服務都在本身的空間獨立開發、部署和運行。在微服務體系結構的大多數定義中，它廣泛被解釋爲將巨大的可用服務隔離成一套獨立服務的過程。

可是面向微服務的架構並是不工程的聖盃。彈性、可組合性以及靈活性是面向微服務架構設計的關鍵原則。若是不遵照你將失去一個完美的解決方案，並最終在單塊應用分拆多臺機器上時遇到大量的問題。

不足之處

事無絕對，微服務也會有幾下問題：

• 網絡延遲：微服務具備分佈式的特性，從而無可避免地會存在網絡延遲
• 運維負擔：更多的服務器也意味着須要更多的維護工做
• 最終一致性：在一個對事務性要求較高的系統中，考慮到實現的侷限性，各個節點在某一時間內可能會出現數據不一致

關鍵設計原則

通常來講，咱們能夠肯定一下設計原則：

• 單一責任原則（SRP）：爲微服務提供有限和重點突出的業務範圍，有助於咱們知足開發和提供服務的敏捷性。
• 在微服務的設計階段，咱們應該找到各服務的邊界，並將其與業務能力（也稱爲域驅動設計中的有界環境 ）保持一致。
• 微服務設計要確保敏捷/獨立開發和部署服務的絲滑穩定。
• 咱們的重點應該放在微服務的範圍上，而不是使服務更"小"。服務的大小應該是指所需的範圍大小，以促進給定的業務能力。
• 與SOA中的服務不一樣，給定的微服務應該具備不多的操做/功能和簡單的消息格式。
• 隨着時間的推移，首先開始具備相對普遍的服務邊界，重構到較小的服務界限（基於業務需求），這是一個很好的作法。

關鍵的好處

如今咱們看幾項關鍵的好處。

彈性

維基百科將彈性定義爲系統處理變化的能力。我對彈性的理解是在問題被解決後系統從異常狀態或者壓力期中優雅的恢復，同時又不會影響系統性能的能力。

這雖然看上去很簡單，可是在構建面向微服務軟件的時候，問題源會因爲系統的分佈式特性而被放大，有時很難防止全部的異常狀況。

彈性是從錯誤中優雅回覆的能力。可是一樣也爲系統帶來了新的複雜度：若是一個微服務出現了問題，咱們可否防止系統的常規故障？理想狀況下，咱們應該以這樣一種方式來構建服務：僅對服務響應進行降級而非讓系統出現常規故障，即便這樣作也並不容易。

可伸縮性

現在各大公司的一個通病是系統存在可伸縮性的問題。一般，這些問題並不涉及應用的每一層次或全部子系統。每每只有個別子系統或服務會明顯鰻魚其他部分，一旦沒有處理好容量問題就會致使整個應用發生故障。

下圖描述瞭如何對微服務進行擴展（擴展成兩個郵件服務）的，同時又不牽扯系統的其他部分：

技術的多樣性

軟件世界每幾個月就出更新系統。新語言進入業界成爲某類系統事實標準的節奏片刻位停。

• Golang：因其結合了強大的性能與優雅簡潔的語法而成爲當前一種趨勢，任何只要擁有一門編程語言經驗的人均可以在幾天學會它。
• Java：自從Sping Boot 發佈之後，他成爲在編寫敏捷服務方面至關有吸引力的技術棧。
• DJango：是一款強大且可用於編寫微服務的Python的框架，與Ruby on Raile 很是類似。
• Node.js：利用了著名的JavaScript 的優點，建立了一個新的服務端技術棧，從而改變了工程師們編寫新軟件的方式。

那麼，將這些語言的技術棧結合起來會有什麼問題嗎？平心而論，這是一個優點：咱們能夠選擇合適的工具來作相對應的工做。只要待集成的技術是標準化的，面向微服務的架構即可以幫你實現這一點。

下圖展現了微服務是如何隱藏數據的存取邏輯的，兩個服務在存取數據方面共用同一個通訊點，從而能很好地互相解耦：

Node.js 並非一門適合執行並行任務的語言。針對那些處於壓力之下的微服務來講，咱們能夠選擇一門更適合的語言來進行開發，好比 Erlang，從而能夠以一種更加優雅的方式來管理併發。

可替換性

可替換性是指替換系統中某個組件而不影響系統行爲的一種能力。 當咱們在討論軟件的時候，可替換性每每是與低耦合密不可分的。在編寫微服務的時候不能講內部邏輯暴露給調用服務，服務實現對客戶端來講是透明的，客戶端只須要了解的只有接口。

獨立性

全部服務應該都是獨立的，他們經過接口進行交互。除了協定確認接口這一環節以外，不一樣的工程師團隊能夠在無需交流的狀況下完成對服務的開發。

易於部署

微服務應當易於部署，緣由以下：

• 少許的業務邏輯，致使更易於部署。
• 微服務是自治的工做單元，因此升級一個服務對於複雜的系統來講是一個局部可控的問題。無需從新部署整個系統。
• 微服務架構中的基礎設施和配置都應該儘量的自動化（如 Docker 來部署微服務）。

SOA 與微服務的比較

面向微服務架構（SOA）與微服務架構很是想象的。那麼他們之間的區別究竟是什麼呢？

微服務是細粒度的 SOA 組件。換句話說，某個單個SOA組件能夠拆成多個微服務，而這些微服務經過分工協做，能夠提供與原SOA組件相同級別的功能，以下圖：

微服務與 SOA 之間的另外一個不一樣之處是服務互聯和編寫服務時所使用的技術。而另外一方面，微服務推崇執行的標準（例如 HTTP）倒是人民普遍瞭解並共同使用的。咱們能夠經過選擇合適的語言或者工做來構建某個組件（微服務），進而得到 技術多樣性 提到的關鍵好處。

除了技術棧和服務規模以外，在SOA於微服務之間還有一個更大的區別：領域模型。在一個機遇微服務的軟件中，每一個微服務應該在本地存儲自身管理數據，並將領域模型分別隔離到單個服務中。而在面向SOA的軟件中，數據每每存儲在單個大型的數據庫中，服務之間會共享領域模型。

爲何選擇 Node.js

Node.js 是一門新型技術棧，對於不少人而言，它僅僅只是一個趨勢，離做爲解決問題的實際工具還欠點火候。

讓咱們來看重點看看 Node.js 。 Node.js 是用來構建面向微服務的架構的絕佳選擇，緣由以下：

• 學習門檻低（若是想要精通仍是有必定門檻的）
• 易於擴展
• 對測試友好
• 易於部署
• 能夠經過 npm 進行依賴管理
• 有着大量與主流標準協議相集成的庫

API 聚合

API 聚合是一項用於將不一樣功能（插件、方法等）組合成一個接口的高級技術。例子：

const express = require('express');
const app = express();

app.get('/sayhello', function (req, res) {
  res.send('Hello World!');
});
app.get('/saygoodbye', function(req, res) {
  res.send('Bye bye!');
}

const server = app.listen(3000, function () {

  let host = server.address().address;
  let port = server.address().port;

  console.log('Example app listening at http://%s:%s', host, port);

});

複製代碼

前面的例子使用了 Express, 這是一個在Node.js技術棧中廣爲流行的 Web 框架。該框架一樣也是圍繞API聚合來構建的。

讓咱們來看下 第四行和第七行。在這些代碼裏，開發者註冊了兩個方法。當某人以 GET 請求的方式分別請求 URL：/sayhello 和 /saygoodbye 時，這兩個對應的方法將被執行。在該例子中，該接口就是一個在3000端口上監聽的app。

小結

在本文中你瞭解一些面向微服務的架構的關鍵好處，好比能夠爲相應的服務選擇合適的語言（語言多樣性）；以及一些可能會加劇咱們負擔的誤區，好比如何有面向微服務的架構分佈式特性而帶來的運維方面開銷。

最後，咱們討論了 Node.js 是用來構建微服務的強大工具，以及如何經過利用像 API 聚合這樣的技術來從 JavaScript 獲益，從而構建出高質量的軟件組件。