Unix哲學，Microservices和DDD （2）

Microservice是微型－服務的合成詞，一個近年來很新的buzzword。Buzzword意爲每一個人都喜歡講的流行術語（大數據是另外一個有趣的buzzword）。

像其餘工程名詞同樣，微服務並無嚴格的定義。寫這篇筆記的時候搜到一個定義以下：

微服務架構

微服務架構是一種架構模式，它提倡將單一應用程序劃分紅一組小的服務，服務之間互相協調、互相配合，爲用戶提供最終價值。每一個服務運行在其獨立的進程中，服務與服務間採用輕量級的通訊機制互相溝通（一般是基於HTTP協議的RESTful API）。每一個服務都圍繞着具體業務進行構建，而且可以被獨立的部署到生產環境、類生產環境等。另外，應當儘可能避免統一的、集中式的服務管理機制，對具體的一個服務而言，應根據業務上下文，選擇合適的語言、工具對其進行構建。

單純看這樣的描述並不會有什麼感受，所以仍是先介紹下微服務相關的一些技術背景。從上面的定義對進程、協做的強調能夠看出，微服務是強調並行化、可擴展的模式，所以首先從可擴展性角度分析微服務的價值。

可擴展性（scalability）也是被普遍討論的話題。爲了優化軟件的運行速度，能夠縱向擴展（升級運行軟件的硬件），也能夠橫向擴展（增長更多的硬件）。在橫向擴展的基礎上，又有三種可用的策略：

The Scale Cube

• X. 在網絡中部署同一軟件的多個拷貝，並使用負載均衡手段在軟件的各個副本之間分配任務

• Y. 將軟件按照功能模塊拆分，並將不一樣模塊部署到不一樣的機器上

• Z. 數據分區，把每一區的數據放在不一樣的機器上存儲和處理

而應用總的可擴展性（圖中表示爲長方體的體積）與應用在這三個方面的可擴展性相關。傳統網站應用（CRUD/MVC/RDBMS/3-tier/..）較爲容易實現第一種擴展方式。若是要在其餘座標上擴展，則須要首先解答更多的問題：

1. 如何保證拆分軟件模塊的正確性（Y）？

2. 如何保證數據庫的拆分不會下降性能（Z）？

3. 如何對待分佈式系統中的一致性等問題？