一、麼是微服務？
微服務可理解爲一種新的軟件架構方法。
傳統的軟件架構被稱爲單體架構系統，也就是說整個應用最終被打包成一個部署包（如war包）進行部署。這種架構易於開發、測試和部署，但在擴展性、可靠性上上有較大的不足。特別是在功能龐大且不斷擴展的情況下，開發、維護、性能上都有較大的缺陷。在設計上，單體架構系統通常以技術分層，譬如邏輯層、數據層等。
微服務是指從業務角度出發，將完整的功能分解爲一個個小型的服務（如訂單管理、賬號管理），每個服務都有自己的處理和輕量通訊機制（通常是基於HTTP協議的RESTful API），可獨立開發（採用不同開發語音、不同開發框架）、獨立測試、獨立部署、獨立升級。
微服務更傾向於圍繞業務功能對服務結構進行劃分、拆解。這樣的服務，是針對業務領域有着關完整實現的軟件，它包含使用接口、持久存儲、以及系統間的交互。因此這個團隊應該是跨職能的，包含完整的開發技術：用戶體驗、數據庫、以及項目管理。
二、微服務的核心
l 小, 且專注於做一件事情
l 獨立開發、測試、部署、升級、維護
l 每個微服務都有自己的存儲能力，可以有自己的數據庫
l 輕量級的通信機制（Restful API）
l 鬆耦合
三、微服務與SOA
|
SOA實現 |
微服務架構實現 |
|
企業級，自頂向下開展實施 |
團隊級，自底向上開展實施 |
|
服務由多個子系統組成，粒度大 |
一個系統被拆分成多個服務，粒度細 |
|
企業服務總線，集中式的服務架構 |
無集中式總線，鬆散的服務架構 |
|
集成方式複雜（ESB/WS/SOAP） |
集成方式簡單（HTTP/REST/JSON） |
|
單塊架構系統，相互依賴，部署複雜 |
服務都能獨立部署 |
四、微服務開發示例
(一) 架構設計
以一個租車系統爲例。使用單體架構設計的系統結構如下：
使用微服務的思想設計的系統結構如下：
一個微服務一般完成某個特定的功能，比如下單管理、客戶管理等等。每一個微服務都是微型六角形應用，都有自己的業務邏輯和適配器。一些微服務還會發布API給其它微服務和應用客戶端使用。其它微服務完成一個Web UI，運行時，每一個實例可能是一個雲VM或者是Docker容器。
每一個應用功能區都使用微服務完成，另外，Web應用會被拆分成一系列簡單的Web應用（比如一個對乘客，一個對出租車駕駛員）。這樣的拆分對於不同用戶、設備和特殊應用場景部署都更容易。
每一個後臺服務開放一個REST API，許多服務本身也採用了其它服務提供的API。比如，駕駛員管理使用了告知駕駛員一個潛在需求的通知服務。UI服務激活其它服務來更新Web頁面。所有服務都是採用異步的，基於消息的通訊。微服務內部機制將會在後續系列中討論。一些REST API也對乘客和駕駛員採用的移動應用開放。這些應用並不直接訪問後臺服務，而是通過API Gateway來傳遞中間消息。API Gateway負責負載均衡、緩存、訪問控制、API 計費監控等等任務，可以通過NGINX方便實現，後續文章將會介紹到API Gateway。
這種微服務架構模式深刻影響了應用和數據庫之間的關係，不像傳統多個服務共享一個數據庫，微服務架構每個服務都有自己的數據庫。另外，這種思路也影響到了企業級數據模式。同時，這種模式意味着多份數據，但是，如果你想獲得微服務帶來的好處，每個服務獨有一個數據庫是必須的，因爲這種架構需要這種鬆耦合。下面的圖演示示例應用數據庫架構。
每種服務都有自己的數據庫。另外，每種服務可以用更適合自己的數據庫類型，也被稱作多語言一致性架構。比如，駕駛員管理（發現哪個駕駛員更靠近乘客），必須使用支持地理信息查詢的數據庫。
表面上看來，微服務架構模式有點像SOA，他們都由多個服務構成。但是，可以從另外一個角度看此問題，微服務架構模式是一個不包含Web服務（WS-）和ESB服務的SOA。微服務應用樂於採用簡單輕量級協議，比如REST，而不是WS-，在微服務內部避免使用ESB以及ESB類似功能。微服務架構模式也拒絕使用canonical schema等SOA概念。
(二) 微服務之間的通信方式
通過使用HTTP/REST，數據格式使用JSON 或 Protobuf(Binary protocol)，通訊協議是自由的。
五、優點
l 每個微服務都很小，這樣能聚焦一個指定的業務功能或業務需求。
l 微服務能夠被小團隊單獨開發，這個小團隊是2到5人的開發人員組成。
l 微服務是鬆耦合的，是有功能意義的服務，無論是在開發階段或部署階段都是獨立的。
l 各個微服務能使用不同的語言開發。
l 微服務允許容易且靈活的方式集成自動部署，通過持續集成工具，如Jenkins, Hudson,bamboo 。
l 一個團隊的新成員能夠更快投入生產。
l 微服務易於被一個開發人員理解，修改和維護，這樣小團隊能夠更關注自己的工作成果。無需通過合作才能體現價值。
l 微服務允許你利用融合最新技術。
l 微服務只是業務邏輯的代碼，不會和HTML,CSS 或其他界面組件混合。
l 微服務能夠即時被要求擴展。
l 微服務能部署中低端配置的服務器上。
l 易於和第三方集成。
l 每個微服務都有自己的存儲能力，可以有自己的數據庫。也可以有統一數據庫。
六、缺點
l 微服務架構可能帶來過多的操作。
l 需要DevOps技巧(http://en.wikipedia.org/wiki/DevOps).
l 可能雙倍的努力。
l 分佈式系統可能複雜難以管理。
l 因爲分佈部署跟蹤問題難。
l 當服務數量增加，管理複雜性增加。