微服務（Microservices）是業界最近的流行語，每個人好像都在以這樣或那樣的方式談論它。現在讓我們理解什麼是微服務？在本篇教程中，我們會試著理解微服務的定義、概念以及原則。
微服務的定義
今天，微服務是SOA(面向服務的架構體系)之後日趨流行的架構體系之一。如果你緊跟業界趨勢，你會發現商業機構不再像幾年前那樣開發大型應用來管理它們的端對端業務功能，而是選擇那些快速而且敏捷的應用，這樣可以花費更少的成本。
微服務有助於打破大型應用的侷限並且可以在系統裡面構建邏輯獨立的更小的系統。比如說，通過使用Amazon AWS，你可以毫不費力地構建一個雲應用。這是一個說明微服務能幹什麼事情的非常好的例子。
單體架構VS微服務架構
通常情況，微服務通過使用被廣泛接受的輕量協議來互動，比如HTTP和REST,或者訊息協議，比如JMS(Java Message Service)或者AMQP(Advanced Message Queuing Protocol)。在某些特定的場景，開發者也可以使用更多的特殊協議。
微服務的原則
現在讓我們檢查微服務“必須擁有”(must have)的原則。
-
單一職責原則
單一職責原則是 SOLID design pattern其中原則之一。它表示一個單元、一個類、一個函式或者一個微服務有且只有唯一指責。
在任何時候，一個微服務都不應該擁有多個指責。
-
基於業務能力構建
微服務應該注重特定的業務功能並且保證它能夠解決問題。一個微服務永遠也不應該限制它選擇合適的技術棧或者最適合解決業務目標的後端資料庫。
為了解決許多業務問題，在某些方面需要做出一些妥協，這通常是我們設計單體應用的約束和限制。微服務能夠讓你在解決手頭上問題的時候選擇最優方案。
-
你構建它，你擁有它！
另一個這種設計的重要方面與開發前後的責任相關。在大型組織當中，通常一個團隊開發完應用，在一些知識交接過後，就會把它交給運維團隊。然而在微服務當中，開發團隊不僅僅是開發應用——擁有它，並且對它未來的運維負責。
You build it,you own it!
這樣會使開發者與他們軟體的日常運維接觸，並且對他們是怎麼構建被使用者在真實世界中使用的產品有更好的理解。
-
基礎設施自動化
準備和建設微服務的基礎設施是另外一個十分重要的需求。一個服務應該是可獨立部署的並且擁有所有的依賴，包括庫依賴，甚至是像web伺服器、容器或或者抽象化物理資源的虛擬機器。
一個微服務和SOA的主要區別之一在於它們的自治級別。大多數的SOA實現提供了服務級別的抽象，然而微服務則更加深入，它抽象了環境的實現和執行。
在傳統的應用開發中，我們構建一個WAR或者EAR，然後將它部署到JEE應用伺服器，比如JBoss、WebLogic和WebSphere等等。我們也許會部署多個應用到同一個JEE容器。在微服務架構的理想條件下，每個微服務被構建成一個fat Jar，嵌入所有的依賴並且以一個獨立的Java程式執行。
-
為失敗設計
在設計一個微服務時，我們應該把各種失敗的可能性放在心上。我們應該經常問自己，如果服務有時候失效了或者當機了怎麼辦？這些是非常重要的問題，並且我們需在開始實際編碼前解決它們——準確評估服務失效會多大程度地影響使用者體驗。
Fail fast（快速失敗）是另外一個用來構建可容錯性、彈性系統的概念。這種哲學倡導構建可能出錯的系統，而不是永不出錯的系統。由於服務可能在任何時間失效，所以能夠快速檢測出失效非常重要。當然如果可以的話，最好還能夠讓服務自動恢復。
微服務著重於應用的實時監控，用於檢查系統元素（比如資料庫每秒收到多少個請求）和業務相關指標（比如每秒收到多個訂單）。語義監控可以提供一個檢測錯誤的告警系統，來讓開發團隊及時跟進以及查明錯誤。
微服務的好處
相比傳統的多層級單體架構，微服務提供了許多的好處。讓我們把它們列出來：
- 在微服務設計中，架構師和開發者可以選擇最適合每個微服務的架構和技術。這樣將最大限度地提高解決問題的靈活性。
- 微服務實現了可選擇的擴充套件性。比如說每個服務可以獨立地擴充套件或者減少，並且比單體設計方法花費更少的成本。
- 微服務是獨立的獨立部署模組，當某個微服務不能按照我們的需要執行時，可以用另一個類似的微服務替換該微服務。它有助於採取正確的購買與構建決策，這通常是許多企業面臨的挑戰。
- 微服務可以幫助我們構建有機的系統（有機系統指的是通過新增越來越多的功能，在一段時期內橫向擴充套件的系統）。由於微服務都是關於可獨立管理的服務——它可以在我們需要的時候增加服務卻不影響現有的服務。
- 技術更新是軟體開發的障礙之一。然而在微服務當中，我們可以獨立地升級每個微服務的技術而不是整個應用。
- 由於微服務將服務執行環境和服務本身一起打包，所以這可以使得多個不同版本的服務共存在同一環境。
- 最後，微服務能使短小精悍，迅速敏捷團隊用於開發。同時團隊將以微服務的邊界進行組織。
原教程一共13篇，後續會陸續翻譯(ban yun)過來。