組件化、模塊化、集中式、分佈式、服務化、面向服務的架構、微服務架構

最近最火的詞是什麼？那大概就是微服務（Microservice）了。最近也火的一踏糊塗的Docker、AppOps也都是圍繞着微服務領域的。在微服務領域還有不少相關名詞。這些名詞有一個共同的特色那就是晦澀難懂。他們就像中國古代的道、氣、八卦等詞同樣， 一解釋就懂，一問就不知，一討論就打架。

本文主要來介紹幾個和微服務相關的概念。這些概念的都是博主在瀏覽了大量資料以後總結出的我的看法，若有偏頗，請指正，共勉之。

組件化與模塊化

首先來談兩個前端和移動端比較常見的詞：組件化和 模塊化（後面我會說到爲何要先介紹組件化和 模塊化）。

首先，能夠確定的是，組件化和模塊化的中心思想都是分而治之。目的都是將一個龐大的系統拆分紅多個組件或者說是模塊。

組件化

首先來看維基百科中關於組件化（Component-based software engineering）的介紹：

Component-based software engineering (CBSE), also known as component-based development (CBD), is a branch of software engineering that emphasizes the separation of concerns in respect of the wide-ranging functionality available throughout a given software system. It is a reuse-based approach to defining, implementing and composing loosely coupled independent components into systems. This practice aims to bring about an equally wide-ranging degree of benefits in both the short-term and the long-term for the software itself and for organizations that sponsor such software.

大概意思就是：組件化就是基於可重用的目的，將一個大的軟件系統按照分離關注點的形式，拆分紅多個獨立的組件，主要目的就是減小耦合。

• 一個獨立的組件能夠是一個軟件包、web服務、web資源或者是封裝了一些函數的模塊。這樣，獨立出來的組件能夠單獨維護和升級而不會影響到其餘的組件。

模塊化

維基百科中對模塊化Modular Programming的定義以下：

Modular programming is a software design technique that emphasizes separating the functionality of a program into independent, interchangeable modules, such that each contains everything necessary to execute only one aspect of the desired functionality.

With modular programming, concerns are separated such that modules perform logically discrete functions, interacting through well-defined interfaces.

模塊化的目的在於將一個程序按照其功能作拆分，分紅相互獨立的模塊，以便於每一個模塊只包含與其功能相關的內容，模塊之間經過接口調用。將一個大的系統模塊化以後，每一個模塊均可以被高度複用。

模塊化和組件化的區別

從上面的定義中能夠看出，組件化和模塊化的意思差很少，主要思想都是分而治之。只是一個把拆分以後的每一個片斷叫作組件、另外一個把拆分以後的片斷叫作模塊。那麼這兩種拆分在拆分方式上是否是有什麼不一樣的？

關於組件化和模塊化的區別，我在網上看了好多資料，也沒有人能給出準確的回答。其實沒有準確回答的緣由也比較明顯，那就是大多數時候咱們真的不須要嚴格的區分這兩個名字。咱們要學習的是其中的解耦和分治的思想和目的。

從另一個角度來說，若是真的要區分一下組件化和模塊化的話，那麼能夠認爲這兩種分而治之的目的稍有區別：

模塊化的目的是爲了重用，模塊化後能夠方便重複使用和插撥到不一樣的平臺，不一樣的業務邏輯過程當中。

組件化的目的是爲了解耦，把系統拆分紅多個組件，分離組件邊界和責任，便於獨立升級和維護。

集中式與分佈式

要談微服務，那麼必須創建在分佈式的基礎上，對於一個集中式系統也無需談微服務。在個人另一篇文章初識分佈式系統中介紹過集中式系統和分佈式系統的區別，這裏再簡單回顧一下：

集中式

集中式系統用一句話歸納就是：一個主機帶多個終端。終端沒有數據處理能力，僅負責數據的錄入和輸出。而運算、存儲等所有在主機上進行。

集中式系統的最大的特色就是部署結構很是簡單，底層通常採用從IBM、HP等廠商購買到的昂貴的大型主機。所以無需考慮如何對服務進行多節點的部署，也就不用考慮各節點之間的分佈式協做問題。可是，因爲採用單機部署。極可能帶來系統大而複雜、難於維護、發生單點故障（單個點發生故障的時候會波及到整個系統或者網絡，從而致使整個系統或者網絡的癱瘓）、擴展性差等問題。

分佈式

分佈式就是一羣獨立計算機集合共同對外提供服務，可是對於系統的用戶來講，就像是一臺計算機在提供服務同樣。分佈式意味着能夠採用更多的普通計算機（相對於昂貴的大型機）組成分佈式集羣對外提供服務。計算機越多，CPU、內存、存儲資源等也就越多，可以處理的併發訪問量也就越大。

拿電商網站來講，咱們通常把一個電商網站橫向拆分紅商品模塊、訂單模塊、購物車模塊、消息模塊、支付模塊等。而後咱們把不一樣的模塊部署到不一樣的機器上，各個模塊之間經過遠程服務調用(RPC)等方式進行通訊。以一個分佈式的系統對外提供服務。

服務化

提到分佈式，一個不得不提的詞就是服務化，服務化架構使搭建分佈式系統成爲了可能。

傳統的軟件開發面臨着不少的問題，好比： 代碼重複率高、代碼龐大難以維護、沒法快速迭代、測試成本高、可伸縮性差、可靠性差、模塊間高度依賴。爲了解決上面這些問題，咱們通常採用拆分、解耦、分層、獨立等方式來解決。有了服務化架構，咱們就能夠在很大程度上解決這些問題。

服務化是一種粗粒度、鬆耦合的以服務爲中心的架構，服務之間經過定義明確的協議和接口進行通訊。

這裏說到的「服務」，本質上來講，就是指「RPC」。單純的RPC功能實現，其實很簡單，無非就是client發起調用，中間某個組件（甚至就是client自己）攔截調用信息，序列化後將信息傳輸到server端，server端收到調用請求後反序列化，根據請求詳細發起實際調用後返回響應傳輸回給client端。這樣的RPC很常見，好比常見的存儲過程調用就是一例。可是在一個複雜的業務環境，如何管理和協同這些大量的RPC纔是最麻煩的事情。因此，通常提到的「服務化」更多指的是對RPC的管理。服務化通常關注服務註冊，服務協調，服務可用性，服務通信協議和內容交換等。

面向服務的架構

面向服務架構（Service-Oriented Architecture，SOA）又稱「面向服務的體系結構」，是Gartner於2O世紀9O年代中期提出的面向服務架構的概念。

面向服務架構，從語義上說，它與面向過程、面向對象、面向組件同樣，是一種軟件組建及開發的方式。與以往的軟件開發、架構模式同樣，SOA只是一種體系、一種思想，而不是某種具體的軟件產品。

這裏，咱們經過一個例子來解釋一下到底什麼是SOA？如何作到SOA？

什麼是SOA

SOA也能夠說是一種是設計原則（模式），那麼它包含哪些內容呢？事實上，這方面並無最標準的答案，多數是聽從著名SOA專家Thomas Erl的概括：

標準化的服務契約 Standardized service contract

服務的鬆耦合 Service loose coupling

服務的抽象 Service abstraction

服務的可重用性 Service reusability

服務的自治性 Service autonomy

服務的無狀態性 Service statelessness

服務的可發現性 Service discoverability

服務的可組合性 Service composability

這些原則總的來講要達到的目的是：提升軟件的重用性，減小開發和維護的成本，最終增長一個公司業務的敏捷度。

既然是面向服務的架構，那麼咱們就先來定義一個服務，

public interface Echo {    String echo(String text); } public class EchoImpl implements Echo {    public String echo(String text) {        return text;    } }複製代碼public interface Echo {    String echo(String text); } public class EchoImpl implements Echo {    public String echo(String text) {        return text;    } }

上面這段代碼相信有過JavaWeb開發經驗的人都不會陌生。就是定義了一個服務的接口和實現。

那麼，定義了服務，咱們就作到了SOA了麼？

咱們用Thomas Erl定義的原則來對比一下，用鬆耦合和可重用這幾個原則來嘗試分析一下上面Echo示例：

Echo的服務契約是用Java接口定義，而不是一種與平臺和語言無關的標準化協議，如WSDL， CORBA IDL。固然能夠擡槓，Java也是行業標準，甚至全國牙防組一致認定的東西也是行業標準。

Java接口大大加劇了與Service客戶端的耦合度，即要求客戶端必須也是Java，或者JVM上的動態語言（如Groovy、 Jython）等等……

同時，Echo是一個Java的本地接口，就要求調用者最好在同一個JVM進程以內……

Echo的業務邏輯雖然簡單獨立，但以上技術方面的侷限就致使它沒法之後在其餘場合被輕易重用，好比分佈式環境，異構平臺等等 ESB是SCA思想實現的基礎設施。 ESB主要做用是集中註冊發佈服務，爲服務與傳輸協議之間解耦。並非全部的SOA架構都須要 ESB，ESB是 SCA特有的。固然任何符合ESB特徵的解決方式均可以稱之爲ESB，也不只僅是 SCA內部的。

所以，咱們能夠認爲Echo並不太符合SOA的基本設計原則。

實現SOA

修改一下上面的Echo，添加Java EE的@WebServices註解

@WebServices public class EchoImpl implements Echo {    public String echo(String text) {        return text;    } }複製代碼@WebServices public class EchoImpl implements Echo {    public String echo(String text) {        return text;    } }

如今將Echo發佈爲Java WebServices，並由底層框架自動生成WSDL來做爲標準化的服務契約，這樣就能與遠程的各類語言和平臺互操做了，較好的解決了上面提到的鬆耦合和可重用的問題。按照通常的理解，Echo彷佛就成爲比較理想的SOA service了。

使用WebServices只是一種相對簡單的方案，SOA的最多見的解決方案是 SCA，其次還有JBI， BPEL等。ESB是SCA思想實現的基礎設施。 ESB主要做用是集中註冊發佈服務，爲服務與傳輸協議之間解耦。關於SCA和ESB並非本文的重點，感興趣的朋友能夠從網絡上獲取更多資料。(能夠從上圖中看到ESB在整個SOA架構中所扮演的角色)

面向對象和麪向服務的對比

面向對象（OO）和 面向服務（SO）在基礎理念上有大量共通之處，好比都儘量追求抽象、封裝和低耦合。

但SO相對於OO，又有很是不一樣的典型應用場景，好比：

• 多數OO接口（interface）都只被有限的人使用（好比團隊和部門內），而SO接口（或者叫契約）通常來講都不該該對使用者的範圍做出太多的限定和假設（能夠是不一樣部門，不一樣企業，不一樣國家）。還記得貝佐斯原則嗎？「團隊必須作好規劃與設計，以便將來把接口開放給全世界的程序員，沒有任何例外」。

• 多數OO接口都只在進程內被訪問，而SO接口一般都是被遠程調用。

簡單講，就是SO接口使用範圍比通常OO接口可能普遍得多。咱們用網站打個比方：一個大型網站的web界面就是它整個系統入口點和邊界，可能要面對全世界的訪問者（因此常常會作國際化之類的工做），而系統內部傳統的OO接口和程序則被隱藏在web界面以後，只被內部較小範圍使用。而理想的SO接口和web界面同樣，也是變成系統入口和邊界，可能要對全世界開發者開放，所以SO在設計開發之中與OO相比其實會有不少不一樣。（微觀SOA：服務設計原則及其實踐方式（上篇））

微服務架構

微服務架構(MicroService)是一種服務化架構風格，經過將功能分散到各個離散的服務中以實現對解決方案的解耦。微服務架構強調的第一個重點就是業務系統須要完全的組件化和服務化（這也是咱們爲何要先介紹組件化和服務化的緣由）。微服務的誕生並不是偶然。它是互聯網高速發展，敏捷、精益、持續交付方法論的深刻人心，虛擬化技術與DevOps文化的快速發展以及傳統單塊架構沒法適應快速變化等多重因素的推進下所誕生的產物。

微服務的流行，Martin功不可沒，先看看他是如何定義微服務的：

The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services , which may be written in different programming languages and use different data storage technologies.

總結起來大概如下四點：

• 一些列的獨立的服務共同組成系統

• 單獨部署，跑在本身的進程裏

• 每一個服務爲獨立的業務開發

• 分佈式的管理

Martin本身也說了，每一個人對微服務均可以有本身的理解，不過大概的標準仍是有一些的。

• 分佈式服務組成的系統

• 按照業務而不是技術來劃分組織

• 作有生命的產品而不是項目

• Smart endpoints and dumb pipes（個人理解是強服務個體和弱通訊）

• 自動化運維（DevOps）

• 容錯

• 快速演化

SOA和微服務

看了SOA和微服務，不少人會認爲這不就是一回事兒麼。其實SOA和微服務就是差很少的。

若是一句話來談SOA和微服務的區別，即微服務再也不強調傳統SOA架構裏面比較重的ESB企業服務總線。微服務把全部的「思考」邏輯包括路由、消息解析等放在服務內部，去掉一個大一統的ESB，服務間輕通訊，是比SOA更完全的拆分。（微服務（Microservice）那點事）

關於微服務這裏只是作一個簡單的介紹，要想真正的瞭解微服務還有不少路要走，好比康威定律（我後面會專門寫一篇文章介紹康威定律）、服務間通訊、 服務的註冊與發現、服務治理與服務編排等。。。

總結

本文主要介紹了組件化、模塊化、集中式、 分佈式、服務化、面向服務的架構、微服務架構等概念。可是，正所謂實踐出真知。仍是要在平常工做中實際運用才能真正的掌握。

多位一線互聯網公司架構師聯合出品