在 Martin Fowler & James Lewis 的文章(參考[1])裏給出了微服務架構的壹個定義:
微服務架構即是采用壹組小服務來構建應用的方法。
每個服務運行在獨立的進程中，不同服務通過壹些輕量級交互機制來通信， 例如 RPC、HTTP 等。
服務圍繞業務能力來構建，並依賴自動部署機制來獨立部署。
這個定義相對還是模糊，但還是勾勒出了微服務的壹些關鍵概念：小，獨立進程，自動化。
起源
從微服務的定義，我們感覺似曾相識。早在 1994 年 Mike Gancarz 曾提出了 9 條著名原則(參考[4])，其中前 4 條和微服務架構理念特別接近。微服務就像把 UNIX 哲學應用到了分布式系統（參考[3]）。
Small is beautiful.
Make each program do one thing well.
Build a prototype as soon as possible.
Choose portability over efficiency.
小即是美：小的服務代碼少，bug 也少，易測試，易維護，也更容易不斷叠代完善的精致進而美妙。
壹個程序只做好壹件事：壹個服務也只需要做好壹件好，專註才能做好。
盡可能早地創建原型：盡可能早的提供服務 API，建立服務契約，達成服務間溝通的壹致性約定，至於實現和完善可以慢慢再做。
可移植性比效率更重要：服務間的輕量級交互協議在效率和可移植性二者間，首要依然考慮兼容性和移植性。
可見微服務其實不是憑空產生的，它自有其歷史的淵源。而在微服務之前的十年，大家經常談論的是壹個叫 SOA（面向服務）的架構模式，它和微服務又是什麽關系？在 Sam Newman 的《Building Microservices》（參考[2]）壹書中，作者對 SOA 和 Micorservices 的區別給出了定義：
You should instead think of Microservices as a specific approach for SOA in the same way that XP or Scrum are specific approaches for Agile software development.
妳可以把微服務想成是 SOA 的壹種實踐方式，正如 XP 或 Scrum 是敏捷軟件開發的實踐方式。我對這個定義是認同的，面向服務架構（SOA）的概念已有十多年，它提出了壹種架構設計思想， 但沒有給出標準的參考實現，而早期企業軟件業界自己摸索了壹套實踐方式 —— 企業服務總線（ESB）。 但歷史證明 ESB 的實現方案甚至在傳統企業軟件行業也未取得成功，Martin Fowler 在文中說正是因為 ESB 當年搞砸了很多項目， 投入幾百萬美金，產出幾乎為零，因此 SOA 這個概念也蒙上了不詳的標簽，所以當微服務架構出現時， 其擁護者開始拒絕使用包裹著失敗陰影的 SOA 這個標簽，而直接稱其為微服務架構（Microservices Architecture Style）， 讓人以為是壹套全新的架構思想，但事實上它的本質依然是 SOA 的壹種實踐方式。
特征
壹個按微服務架構理念構建的系統應該具備什麽樣的特征呢？Martin 在其文章（參考[1]）中做了詳盡的闡述，我這裏簡單歸納下。
組件服務化
傳統實現組件的方式是通過庫（library），庫是和應用壹起運行在進程中，庫的局部變化意味著整個應用的重新部署。 通過服務來實現組件，意味著將應用拆散為壹系列的服務運行在不同的進程中，那麽單壹服務的局部變化只需重新部署對應的服務進程。
按業務能力組織服務
按業務能力組織服務的意思是服務提供的能力和業務功能對應，比如：訂單服務和數據訪問服務，前者反應了真實的訂單相關業務，後者是壹種技術抽象服務不反應真實的業務。所以按微服務架構理念來劃分服務時，是不應該存在數據訪問服務這樣壹個服務的。
Melvin Conway 在 1967 年觀察到壹個現象並總結出了壹條著名的康威定律（參考[5]）:
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.
設計系統的組織，最終產生的設計等價於組織的溝通結構。傳統開發方式中，我們將工程師按技能專長分層為前端層、中間層、數據層，前端對應的角色為 UI、頁面構建師等，中間層對應的角色為後端業務開發工程師，數據層對應著 DBA 等角色。
事實上傳統應用設計架構的分層結構正反應了不同角色的溝通結構。所以若要按微服務的方式來構建應用，也需要對應調整團隊的組織架構。每個服務背後的小團隊的組織是跨功能的，包含實現業務所需的全面的技能。
服務即產品
傳統的應用開發都是基於項目模式的，開發團隊根據壹堆功能列表開發出壹個軟件應用並交付給客戶後，該軟件應用就進入維護模式，由另壹個維護團隊負責，開發團隊的職責結束。 而微服務架構建議避免采用這種項目模式，更傾向於讓開發團隊負責整個產品的全部生命周期。Amazon 對此提出了壹個觀點：
You build it, you run it.
開發團隊對軟件在生產環境的運行負全部責任，讓服務的開發者與服務的使用者（客戶）形成每日的交流反饋，來自直接客戶的反饋有助於開發者提升服務的品質。