開始裝逼之旅之前，請允許我和大家一起再溫習一句話：
這句話適合一切高大上的概念，比如：SOA，DevOps，DDD，Agile，Cloud等等，包括我現在想要講述的「微服務」。
為什么會這樣？
“專家”太多了，俗話說的好：「一千個專家眼里，有一千個哈姆雷特」。
概念聽的多了，還以為自己見多識廣，最后大多都是迷茫了：「臥槽！我到底應該信誰？」
依老夫看：信誰都不如信自己！
如此紛繁復雜的概念，真是讓人捉摸不透，卻又不得不去了解，畢竟互聯網的圈子里有太多洪水猛獸，稍有懈怠，就會被拍在沙灘上了。
其實，意識到自己身處如此險境，也算是我的后知后覺，或許早有感知，可是遲遲沒有行動。直至現如今，我才十分強烈地感受到這個時代對我們這些素人深深的惡意。
是的，我得掙扎一下，給未來的自己留下點痕跡。
縱觀我不算很長的從業經驗，可以總結出六字箴言：
聽說過，沒用過
這將是IT界的技術人員在知識的廣度和深度之間糾結的一個縮影。
多么痛的領悟，有木有！~~
我的生活不少閱歷，卻極度匱乏提煉和升華。雖然之前也在社交媒體上零零散散地「矯情」過幾次，但那都是生活成長之感悟，對于自己的專業技術層面，還是少之又少。
因此，為了避免迷失于這一波又一波的互聯網大潮中，我決定梳理一下「畢生所學」，剛好最近對微服務有一些實踐經驗，那就談談我所了解的微服務。
1、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的開發模式未嘗不可。
2、淺談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兩大核心要素：服務和治理。
3、再談微服務
寫到最后，最重要的壓軸戲終于出現了！我不禁要把Martin大神拿出來拜上兩拜。
微服務的流行，Martin功不可沒，這老頭也是個奇人，特別擅長抽象歸納和制造概念，我覺的這就是最牛逼的markting啊，感覺這也是目前國人欠缺的能力。
回到上述的ALL in ONE，這種模式下開發出來的應用，無論是可擴展性，還是可維護性，都是非常差勁的，這與微服務的理念是相違背的。
微服務的目的是有效的拆分應用，實現敏捷開發和快速部署 。
以上的這個小方塊，在互聯網圈子里，被眾多巨巨們所津津樂道。這是一個三維模型，三個方向分別代表了三種可擴展的維度：
X-axis：Application級別的橫向擴展。當然，它們都是躲在Load Balance后面，等待欽點；
Y-axis：可以看做是應用內的擴展，即一個應用內的每個服務可以部署多個實例；
Z-axis：和X-axis有些相似，都是應用級別的擴展，不同的是，每個副本只訪問部分數據，即多了“分庫分表”的工作。
雖然三個維度是相互垂直的，但是并不代表沒有任何關系，也不是非要三選一不可。
我們可以試著感受一下：
X-axis代表運行多個應用實例，外加Load Balance，提升了應用的整體抗壓性；
Y-axis代表將應用進一步分解為微服務，并部署多個實例，也就意味著針對應用內的某幾個服務，提升其性能，使其不易觸碰到瓶頸；
當數據量大時，還可以用Z-axis將服務按數據分區（分表）。
從這個角度看，這是應用性能提升的幾個手段。
再說回微服務。下面引用一段總結性的文字：
Martin自己也說了，每個人對微服務都可以不盡相同，不過大概的標準還是有一些的。
1、分布式服務組成的系統
2、按照業務而不是技術來劃分組織
3、做有生命的產品而不是項目
4、Smart endpoints and dumb pipes（我的理解是強服務個體和弱通信）
5、自動化運維（DevOps）
6、容錯
7、快速演化
而在我看來，微服務這種思想其實對SOA的一種傳承和延伸，微服務吸納了SOA所有的優勢之處，并且也具備了SOA沒有的功能。
對于前面三個標準，同樣適用于SOA，而后面的幾點，則有所分別了。
第4個標準對前面提及的ESB的理念是有所沖擊的。SOA側重于對服務的治理，服務的治理者自然就成為了系統強勢的一方，以ESB為中心，如果接入的服務多了，ESB將會變得越來越重。所以微服務主張的是去ESB，去中心化，消息的解析放在服務內進行。
對于5~7個標準，在SOA中并沒有過多強調，因為已經不在其標準范疇內。而在微服務中，卻是必須的。
不難看出，微服務完全具備了這個時代鮮明的特色，這些特色，在以往是不具備的，因為不那么被人們所重視。
在現在看來，有了Docker，DevOps等關鍵技術的加持，整個微服務生態還是比較完整的，也就不難理解微服務為什么這么火了。
關于微服務的具體實踐，就不在此贅述了，可以關注我，關注后續文章
想要一起學習交流，或者系統的學習java的可以加企鵝群475820025? ?進群邀請碼 （寂靜）
學習交流C/C++的可以加群??553014383? 進群邀請碼 （寂靜）
每個群內都有各種相關學習資源，還有大神萌新互動交流。歡迎大家加群
