我所瞭解的微服務

開始裝逼之旅以前，請容許我和你們一塊兒再溫習一句話：

這句話適合一切高大上的概念，好比：SOA，DevOps，DDD，Agile，Cloud等等，包括我如今想要講述的「微服務」。
爲何會這樣？
「專家」太多了，俗話說的好：「一千個專家眼裏，有一千個哈姆雷特」。
概念聽的多了，還覺得本身見多識廣，最後大多都是迷茫了：「臥槽！我到底應該信誰？」
依老夫看：信誰都不如信本身！
如此紛繁複雜的概念，真是讓人捉摸不透，卻又不得不去了解，畢竟互聯網的圈子裏有太多洪水猛獸，稍有懈怠，就會被拍在沙灘上了。
其實，意識到本身身處如此險境，也算是個人後知後覺，或許早有感知，但是遲遲沒有行動。直至現現在，我才十分強烈地感覺到這個時代對咱們這些素人深深的惡意。
是的，我得掙扎一下，給將來的本身留下點痕跡。
縱觀我不算很長的從業經驗，能夠總結出六字箴言：

據說過，沒用過

這將是IT界的技術人員在知識的廣度和深度之間糾結的一個縮影。
多麼痛的領悟，有木有！~~
個人生活很多閱歷，卻極度匱乏提煉和昇華。雖然以前也在社交媒體上零零散散地「矯情」過幾回，但那都是生活成長之感悟，對於本身的專業技術層面，仍是少之又少。
所以，爲了不迷失於這一波又一波的互聯網大潮中，我決定梳理一下「畢生所學」，恰好最近對微服務有一些實踐經驗，那就談談我所瞭解的微服務。

---

一、ALL in ONE

談微服務以前，我習慣先談談曾經摺磨我三年的開發模式：ALL in ONE。
也會有人稱之爲：「單體應用」
此處用到了「折磨」一詞，憎恨之情可謂是溢於言表。

其實這種感覺並非一開始就有，而是我在微服務圈子裏混了一段時間後發掘的：

我特麼之前是怎麼過來的！

ALL in ONE的開發模式應該算是我這代互聯網人認識軟件開發過程的第一個階段。

打開Eclipse，new一個Dynamic Web Project。
Java代碼放在src下，JSP放在WebContent目錄下，在WEB-INF/lib目錄下還有各類jar包的加持，多麼熟悉的工程目錄結構。
再後來，有了maven，一個項目分多個module，看起來清爽了很多，jar包也一會兒少了不少，從SVN上Checkout一個工程明顯更快了，編譯，打包什麼的，明顯更方便了。
想當初，本身引覺得傲的Linux命令，給服務器安裝JDK，Tomcat，MySQL什麼的，都是信手拈來。
當我熟練的將WAR包打出來，往webapps目錄下一放，部署算是完成了。

即使如此，這種開發模式仍是比較「穩」的：
從開發者的角度來講，至少從技術上了解一個項目， 沒有過高的學習成本，除非你很不幸地遇到了一位愛裝逼的同事。其次，每次的部署也變得出奇的簡單，幾乎不須要操心如今DevOps所面臨的問題。
從寫代碼的層面看，全部依賴都集中在一個項目中，根本就不須要遠程調用，拿來即用。
最後，老闆要你給一張系統架構圖，很尷尬的發現，原來是這樣的：

既然是單體應用，也就跟集羣沒有半毛錢關係了，固然，想改形成集羣並不是不可。
以這麼單薄的系統架構，很難相信其能抗住多大的流量，性能方面可圈可點。
代碼結構上，到最後會很尷尬地發現功能模塊間的耦合性愈來愈高，正所謂「剪不斷，理還亂」，到頭來很絕望地問本身：還要不要重構？
若是要寫單元測試，跑一個Case就要重啓工程5分鐘，能不抓狂嗎？
對於那些小型站點，以快速交付爲目的的項目，用ALL in ONE的開發模式何嘗不可。

---

二、淺談SOA

猶豫了好久，要不要順帶介紹一下SOA？講真，並非篇幅所限，而是知識所限。以我現有的淺薄知識，區分SOA和微服務彷佛是一件很吃力的事情，但我仍是試着去了解。萬一哪一個瞬間個人任督二脈通了呢？
還有一個緣由，仔細想一想，咱們在談微服務的時候，咱們在談什麼？SOA大概是一個繞不過的鴻溝吧！
論資歷，SOA絕對算的上老大哥了，於1996年被Gartner大神所提出，2000年才慢慢流行起來。因此咱們一提到微服務這個「後起之秀」，都習慣給SOA加上一個形容詞：「傳統的」。

SOA能夠認爲是一種架構風格，甚至是一種設計模式。字面上理解，咱們在作系統設計的時候，是以一個服務做爲一種組件來設計。
那什麼是服務（Service）？服務就是一組動做（業務活動）的抽象。
SOA主張的是粗粒度，因此在劃分服務的時候，仍是須要有所斟酌的。粗粒度性的一個最大好處就是向外提供的服務接口不會太多，以便下降服務之間往復調用的性能損耗。可是同時還要考慮服務的可複用性，服務劃分過於簡單粗暴也不是件好事。在這二者之間，須要根據實際的業務場景找到一個合適的制衡點。
當咱們把訂單、支付、帳戶等抽象成一個個模塊，這個過程咱們就能夠當作是在作服務提取，但並非這樣作就能夠完成面向服務的架構，SOA真正的價值是把全部的服務整合起來，使之相對獨立而又能有條不紊的相互協做，完成一系列的業務操做。

所以，我眼中的SOA有兩個核心要素：服務和治理。

那麼，若干個服務之間是如何取得聯繫的？
這裏面的水彷佛很深了，涉及到了SOA領域的好幾個概念，我嘗試着去解釋一番。
其中，最著名的當屬SCA和ESB了。

SCA（Service Component Architecture），是爲實現 SOA 而產生的一種規範。該規範被IBM、Oracle、SAP、BEA等大廠所認同，所以在民間也廣爲流傳。
SCA獨立於任何具體的技術，從編程模型上決定了SOA的實現方式。你能夠用不一樣的編程語言構建功能單元或組件，而後將他們經過SOAP、JMS、RMI、REST或其它協議暴露爲服務。
SCA的基礎構成單元是Component，能夠將它認爲是一組接口的implementation的集合，或者是已存在的外部系統。SCA致力於將開發人員從繁雜的底層協議處理中解脫出來，屏蔽一切技術細節，聚焦於業務功能的實現。基於SCA開發的一套著名的框架是Apache Tuscany，關於Tuscany，已不屬於本文討論的範疇了，就不在此贅述了。附上一張SCA典型的體系結構圖，感覺一下：

相比較SUN公司提出的JBI（Java Business Integration），就沒那麼幸運了，尤爲是SUN被收購後，JBI已經陷入了名不副實的窘境，前景天然就不容樂觀。
JBI一開始的定位就是對已有的Java EE容器的擴展，並不打算兼容其餘平臺的組件。基於JBI規範構造出來的結果，本質上仍是一種運行容器，其內部有消息的分發引擎，協議的轉換引擎，因此支持的協議更多了，融合了HTTP，RMS，JMI。這對於整個JAVA生態來講，是很是值得推行的，而對現行的SOA體系來講，就顯得捉襟見肘了，因此也難以獲得重用。

總的來講，SCA已成爲SOA事實上的標準，提到SOA，基本上都會扯上SCA。

ESB（Enterprise Service Bus），業內一般翻譯爲「企業服務總線」。我嘗試着百度了一下「ESB」，前面幾條是有企業作廣告的，大體就是爲企業提供ESB服務，而百度SCA則不會有任何廣告出現。這從某種意義上證實個人設想，ESB就是基於SCA規範的一種具體實現。
既然是企業服務的總線，其承載的流量是巨大的，各式各樣的服務以不一樣的姿式接入到總線中，因此ESB首當其衝要解決的是不一樣協議的支撐和適配問題，其次，還須要對每一個服務進行集成、編排和監控。ESB的出現，能夠有效的打破企業內部「信息孤島」的局面，讓數據也能成爲企業的「流動資金」。

若是你能順利閱讀到此處，其實也就不難理解我在上述提到的SOA兩大核心要素：服務和治理。

---

三、再談微服務

寫到最後，最重要的壓軸戲終於出現了！我不由要把Martin大神拿出來拜上兩拜。

Martin大神在凡間一個蜜汁微笑，Agile誕生了；捋捋鬍鬚，Microservice火了。

回到上述的ALL in ONE，這種模式下開發出來的應用，不管是可擴展性，仍是可維護性，都是很是差勁的，這與微服務的理念是相違背的。
微服務的目的是有效的拆分應用，實現敏捷開發和快速部署 。

以上的這個小方塊，在互聯網圈子裏，被衆多巨巨們所津津樂道。這是一個三維模型，三個方向分別表明了三種可擴展的維度：

X-axis：Application級別的橫向擴展。固然，它們都是躲在Load Balance後面，等待欽點；

Y-axis：能夠看作是應用內的擴展，即一個應用內的每一個服務能夠部署多個實例；

Z-axis：和X-axis有些類似，都是應用級別的擴展，不一樣的是，每一個副本只訪問部分數據，即多了「分庫分表」的工做。

雖然三個維度是相互垂直的，可是並不表明沒有任何關係，也不是非要三選一不可。

咱們能夠試着感覺一下：
X-axis表明運行多個應用實例，外加Load Balance，提高了應用的總體抗壓性；
Y-axis表明將應用進一步分解爲微服務，並部署多個實例，也就意味着針對應用內的某幾個服務，提高其性能，使其不易觸碰到瓶頸；
當數據量大時，還能夠用Z-axis將服務按數據分區（分表）。
從這個角度看，這是應用性能提高的幾個手段。

再說回微服務。下面引用一段總結性的文字：

Martin本身也說了，每一個人對微服務均可以不盡相同，不過大概的標準仍是有一些的。
一、分佈式服務組成的系統
二、按照業務而不是技術來劃分組織
三、作有生命的產品而不是項目
四、Smart endpoints and dumb pipes（個人理解是強服務個體和弱通訊）
五、自動化運維（DevOps）
六、容錯
七、快速演化

而在我看來，微服務這種思想其實對SOA的一種傳承和延伸，微服務吸納了SOA全部的優點之處，而且也具有了SOA沒有的功能。

對於前面三個標準，一樣適用於SOA，然後面的幾點，則有所分別了。
第4個標準對前面說起的ESB的理念是有所衝擊的。SOA側重於對服務的治理，服務的治理者天然就成爲了系統強勢的一方，以ESB爲中心，若是接入的服務多了，ESB將會變得愈來愈重。因此微服務主張的是去ESB，去中心化，消息的解析放在服務內進行。
對於5~7個標準，在SOA中並無過多強調，由於已經不在其標準範疇內。而在微服務中，倒是必須的。

不難看出，微服務徹底具有了這個時代鮮明的特點，這些特點，在以往是不具有的，由於不那麼被人們所重視。
在如今看來，有了Docker，DevOps等關鍵技術的加持，整個微服務生態仍是比較完整的，也就不難理解微服務爲何這麼火了。

關於微服務的治理，就不在此贅述了，打算另起新篇。

---

總結

本篇從ALL in ONE 講到 Microservice，算是我這些年來開發模式的轉變過程。也許從此還會有新的概念不斷涌現，但我仍是始終告誡本身不要在滾滾浪潮中迷失本身。

但願對你有所幫助。

THANKS！

附：

參考文獻：

一、SOA標準之----SCA架構思想

二、SCA 專題——來自IBM

三、轉載：微服務（Microservice）那點事

四、Microservices: Decomposing Applications for Deployability and Scalability