本文主要來介紹幾個和微服務相關的概念。這些概念的都是博主在瀏覽了大量資料之後總結出的個人見解，如有偏頗，請指正，共勉之。
組件化與模塊化
首先來談兩個前端和移動端比較常見的詞：組件化和模塊化（後面我會說到為什麼要先介紹組件化和模塊化）。
首先，可以肯定的是，組件化和模塊化的中心思想都是分而治之。目的都是將一個龐大的系統拆分成多個組件或者說是模塊。
組件化
首先來看維基百科中關於組件化（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;
}
}
上面這段代碼相信有過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;
}
}
現在將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）那點事）
關於微服務這裡只是做一個簡單的介紹，要想真正的瞭解微服務還有很多路要走，比如康威定律（我後面會專門寫一篇文章介紹康威定律）、服務間通信、服務的註冊與發現、
服務治理與服務編排等。。。總結
本文主要介紹了組件化、模塊化、集中式、分佈式、服務化、面向服務的架構、微服務架構等概念。但是，正所謂實踐出真知。還是要在日常工作中實際運用才能真正的掌握。
閱讀更多 牛旦教育IT課堂 的文章
