微服務架構定義那點事

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

---

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

最易懂的版本

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

微服務架構是一種架構模式，它提倡將單一應用程序劃分紅一組小的服務，服務之間互相協調、互相配合，爲用戶提供最終價值。每一個服務運行在其獨立的進程中，服務與服務間採用輕量級的通訊機制互相協做（一般是基於HTTP協議的RESTful API）。每一個服務都圍繞着具體業務進行構建，而且可以被獨立的部署到生產環境、類生產環境等。

我在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》,國內較早倡導和實踐微服務的先行者。