從微服務架構定義的歷史可以看出，這些概念來源都是提出者對個人實際工作工面臨問題的解決方案的總結，是那些技術專家對十多年前工作中遇到問題的解決方案，在他們提出後不斷被髮展，進而成了現在流行的微服務架構。

 相信很多朋友瞭解微服務架構都是從Martin Fowler的那篇文章開始。而實際上，Martin卻並不是最早談及微服務架構的，本篇文章就和你聊聊微服務架構定義的那點事。

最易懂的版本

Martin Fowler的這篇文章《Microservices》通俗易懂的講解了什麼是微服務架構.

微服務架構是一種架構模式，它提倡將單一應用程式劃分成一組

我在2015年4月QCon的《基於微服務架構，改造企業遺留系統的實踐》演講上，將這四個特性定義抽象為“小、獨、輕、鬆”。最後一個字之所以定義成鬆，是為了讀起來能朗朗上口。確切的講，鬆所代表的含義其實是服務具備獨立的流水線，能夠被獨立的構建，並且被獨立的部署。實際上，Martin Fowler並不是最早提出微服務架構概念的人。

最早期的版本

最早提出微服務架構概念的，是Fred George。他一位非常傳奇的人物，從業40多年，接觸過70+程式語言，就職過IBM、TW等多家公司，並在社群和大會上做過很多分享。後來成立獨立的諮詢公司，為金融、電信、保險、航空等多個行業提供敏捷、持續交付、DevOps等轉型服務，他也是最早實踐XP、Scrum、和看板的人之一.

在2012年3月的Agile India上，Fred George分享了題為

“Micro (u)Services Architecture -small, short lived services rather than SOA.

的演講。在演講中，他描述了從2005~2009年期間，他和所在的團隊是如何將100萬行的傳統J2EE程式，通過解耦、自動化驗證等實踐，逐漸分解成20多個5K行程式碼的小服務，又分解成200多個500行程式碼的服務的過程，而其中，也大談了基於Kafka的訊息解耦服務間依賴。我認為，這是對微服務定義的最早版本了。

最簡潔的版本

Adrain Cockcroft，Netflix的雲架構師，主導了Netflix從2009到2016年服務化拆分、從資料中心遷移到雲平臺、以及組織、流程、工具等的演進等.

他對微服務的定義是:

Loosely coupled service oriented architecture with bounded contexts.

其中兩個核心點Loosely coupled 和 Bounded context。Loosely coupled表明，服務之間是鬆耦合的。什麼叫鬆耦合?就是指服務能夠被獨立更新。如果不能被獨立更新，那證明服務就不是鬆耦合的。Bounded context，源於DDD(領域驅動設計)，表明對於服務而言，它的業務是獨立的，我們不需要知道它的依賴者，根據介面就可以更新服務的程式碼。我認為，這是對微服務定義的最簡潔版本了。

最與時俱進的版本

第三個版本，來自Neal Ford，他是TW的資深技術專家，《卓有成效的程式設計師》作者，也是TW技術雷達的發起者和維護者之一。

他對微服務架構的定義是

“Microservices are the first post DevOps revolution architecture.”

這是第一次將微服務和DevOps緊密關聯起來的版本。

實際上，DevOps作為一場開發與運維手拉手，心連心的運動，正在席捲著整個社群。DevOps所涵蓋的一系列文化、實踐以及自動化的理念(CALMS)，是微服務演進過程中必不可少的先決條件。可以說，在傳統的運維模式下，有效實現微服務架構幾乎是不可能的，因為微服務的實施需要自動化基礎設施、自動化部署、自動化驗證、以及利用有效的工具完成運維、監控、告警等。而只有將DevOps與微服務緊密的結合起來，才能達到事半功倍的效果。

總結

如上就是我認為微服務演進過程中，最具有代表性的幾個定義，當然，除了這3位大師，還有很多其他大師，譬如Sam Newman，James Lewis等發表的見解。

感興趣的朋友可以繼續挖掘一下，瞭解微服務架構演進過程中，大師們是如何看待微服務架構的。

王磊：前ThoughtWorks首席諮詢師，《微服務架構與實踐》作者，翻譯有《DevOps Handbook》,國內較早倡導和實踐微服務的先行者。