開始裝逼之旅之前度宦，請允許我和大家一起再溫習一句話：
這句話適合一切高大上的概念，比如：SOA告匠，DevOps戈抄，DDD，Agile后专，Cloud等等划鸽，包括我現(xiàn)在想要講述的「微服務」。
為什么會這樣？
“專家”太多了裸诽，俗話說的好：「一千個專家眼里嫂用，有一千個哈姆雷特」。
概念聽的多了崭捍，還以為自己見多識廣尸折，最后大多都是迷茫了：「臥槽啰脚！我到底應該信誰殷蛇？」
依老夫看：信誰都不如信自己！
如此紛繁復雜的概念橄浓，真是讓人捉摸不透粒梦，卻又不得不去了解，畢竟互聯(lián)網(wǎng)的圈子里有太多洪水猛獸荸实，稍有懈怠匀们，就會被拍在沙灘上了。
其實准给，意識到自己身處如此險境泄朴，也算是我的后知后覺，或許早有感知露氮，可是遲遲沒有行動祖灰。直至現(xiàn)如今，我才十分強烈地感受到這個時代對我們這些素人深深的惡意畔规。
是的局扶，我得掙扎一下，給未來的自己留下點痕跡叁扫。
縱觀我不算很長的從業(yè)經(jīng)驗三妈，可以總結出六字箴言：
聽說過，沒用過
這將是IT界的技術人員在知識的廣度和深度之間糾結的一個縮影莫绣。
多么痛的領悟畴蒲，有木有！~~
我的生活不少閱歷对室，卻極度匱乏提煉和升華模燥。雖然之前也在社交媒體上零零散散地「矯情」過幾次，但那都是生活成長之感悟软驰，對于自己的專業(yè)技術層面涧窒，還是少之又少。
因此锭亏，為了避免迷失于這一波又一波的互聯(lián)網(wǎng)大潮中纠吴，我決定梳理一下「畢生所學」，剛好最近對微服務有一些實踐經(jīng)驗慧瘤，那就談談我所了解的微服務戴已。
1固该、ALL in ONE
談微服務之前，我習慣先談談曾經(jīng)折磨我三年的開發(fā)模式：ALL in ONE糖儡。
也會有人稱之為：「單體應用」
此處用到了「折磨」一詞伐坏，憎恨之情可謂是溢于言表。
其實這種感受并不是一開始就有握联，而是我在微服務圈子里混了一段時間后發(fā)掘的：
我特么以前是怎么過來的桦沉！
ALL in ONE的開發(fā)模式應該算是我這代互聯(lián)網(wǎng)人認識軟件開發(fā)過程的第一個階段。
打開Eclipse金闽，new一個Dynamic Web Project纯露。
Java代碼放在src下，JSP放在WebContent目錄下代芜，在WEB-INF/lib目錄下還有各種jar包的加持埠褪，多么熟悉的工程目錄結構。
再后來挤庇，有了maven钞速，一個項目分多個module，看起來清爽了不少嫡秕，jar包也一下子少了很多渴语，從SVN上Checkout一個工程明顯更快了，編譯淘菩，打包什么的遵班，明顯更方便了。
想當初潮改，自己引以為傲的Linux命令狭郑，給服務器安裝JDK，Tomcat汇在，MySQL什么的翰萨，都是信手拈來。
當我熟練的將WAR包打出來糕殉，往webapps目錄下一放亩鬼，部署算是完成了。
即便如此阿蝶，這種開發(fā)模式還是比較“穩(wěn)”的：
從開發(fā)者的角度來說雳锋，至少從技術上了解一個項目， 沒有太高的學習成本羡洁，除非你很不幸地遇到了一位愛裝逼的同事玷过。其次，每次的部署也變得出奇的簡單，幾乎不需要操心現(xiàn)在DevOps所面臨的問題辛蚊。
從寫代碼的層面看粤蝎，所有依賴都集中在一個項目中，根本就不需要遠程調(diào)用袋马，拿來即用初澎。
最后，老板要你給一張系統(tǒng)架構圖虑凛，很尷尬的發(fā)現(xiàn)碑宴，原來是這樣的：
既然是單體應用，也就跟集群沒有半毛錢關系了卧檐，當然墓懂，想改造成集群并非不可。
以這么單薄的系統(tǒng)架構霉囚，很難相信其能抗住多大的流量，性能方面可圈可點匕积。
代碼結構上盈罐，到最后會很尷尬地發(fā)現(xiàn)功能模塊間的耦合性越來越高，正所謂「剪不斷闪唆，理還亂」盅粪，到頭來很絕望地問自己：還要不要重構？
如果要寫單元測試悄蕾，跑一個Case就要重啟工程5分鐘票顾，能不抓狂嗎？
對于那些小型站點帆调，以快速交付為目的的項目奠骄，用ALL in ONE的開發(fā)模式未嘗不可。
2番刊、淺談SOA
猶豫了很久含鳞，要不要順帶介紹一下SOA？講真芹务，并不是篇幅所限蝉绷，而是知識所限。以我現(xiàn)有的淺薄知識枣抱，區(qū)分SOA和微服務似乎是一件很吃力的事情熔吗，但我還是試著去了解。萬一哪個瞬間我的任督二脈通了呢佳晶？
還有一個原因桅狠，仔細想想，我們在談微服務的時候，我們在談什么垂攘？SOA大概是一個繞不過的鴻溝吧维雇！
論資歷，SOA絕對算的上老大哥了晒他，于1996年被Gartner大神所提出吱型，2000年才慢慢流行起來。所以我們一提到微服務這個「后起之秀」陨仅，都習慣給SOA加上一個形容詞：「傳統(tǒng)的」津滞。
SOA可以認為是一種架構風格，甚至是一種設計模式灼伤。字面上理解触徐，我們在做系統(tǒng)設計的時候，是以一個服務作為一種組件來設計狐赡。
那什么是服務（Service）撞鹉？服務就是一組動作（業(yè)務活動）的抽象。
SOA主張的是粗粒度颖侄，所以在劃分服務的時候鸟雏，還是需要有所斟酌的。粗粒度性的一個最大好處就是向外提供的服務接口不會太多览祖，以便降低服務之間往復調(diào)用的性能損耗孝鹊。但是同時還要考慮服務的可復用性，服務劃分過于簡單粗暴也不是件好事展蒂。在這兩者之間又活，需要根據(jù)實際的業(yè)務場景找到一個合適的制衡點。
當我們把訂單锰悼、支付柳骄、賬戶等抽象成一個個模塊，這個過程我們就可以看成是在做服務提取松捉，但并不是這樣做就可以完成面向服務的架構夹界，SOA真正的價值是把所有的服務整合起來，使之相對獨立而又能有條不紊的相互協(xié)作隘世，完成一系列的業(yè)務操作可柿。
因此，我眼中的SOA有兩個核心要素：服務和治理丙者。
那么复斥，若干個服務之間是如何取得聯(lián)系的？
這里面的水似乎很深了械媒，涉及到了SOA領域的好幾個概念目锭，我嘗試著去解釋一番评汰。
其中，最著名的當屬SCA和ESB了痢虹。
SCA（Service Component Architecture）被去，是為實現(xiàn) SOA 而產(chǎn)生的一種規(guī)范。該規(guī)范被IBM奖唯、Oracle惨缆、SAP、BEA等大廠所認同丰捷，因此在民間也廣為流傳坯墨。
SCA獨立于任何具體的技術，從編程模型上決定了SOA的實現(xiàn)方式病往。你可以用不同的編程語言構建功能單元或組件捣染，然后將他們通過SOAP、JMS停巷、RMI耍攘、REST或其它協(xié)議暴露為服務。
SCA的基礎構成單元是Component叠穆，可以將它認為是一組接口的implementation的集合少漆，或者是已存在的外部系統(tǒng)。SCA致力于將開發(fā)人員從繁雜的底層協(xié)議處理中解脫出來硼被，屏蔽一切技術細節(jié)，聚焦于業(yè)務功能的實現(xiàn)渗磅∪铝颍基于SCA開發(fā)的一套著名的框架是Apache Tuscany，關于Tuscany始鱼，已不屬于本文討論的范疇了仔掸，就不在此贅述了。附上一張SCA典型的體系結構圖医清，感受一下：
相比較SUN公司提出的JBI（Java Business Integration）起暮，就沒那么幸運了，尤其是SUN被收購后会烙，JBI已經(jīng)陷入了名存實亡的窘境负懦，前景自然就不容樂觀。
JBI一開始的定位就是對已有的Java EE容器的擴展柏腻，并不打算兼容其他平臺的組件纸厉。基于JBI規(guī)范構造出來的結果五嫂，本質(zhì)上還是一種運行容器颗品，其內(nèi)部有消息的分發(fā)引擎肯尺，協(xié)議的轉(zhuǎn)換引擎，所以支持的協(xié)議更多了躯枢，融合了HTTP则吟，RMS，JMI锄蹂。這對于整個JAVA生態(tài)來說氓仲，是非常值得推行的，而對現(xiàn)行的SOA體系來說败匹，就顯得捉襟見肘了寨昙，所以也難以得到重用。
總的來說掀亩，SCA已成為SOA事實上的標準舔哪，提到SOA，基本上都會扯上SCA槽棍。
ESB（Enterprise Service Bus）一罩，業(yè)內(nèi)通常翻譯為「企業(yè)服務總線」励背。我嘗試著百度了一下「ESB」，前面幾條是有企業(yè)做廣告的，大致就是為企業(yè)提供ESB服務郎哭，而百度SCA則不會有任何廣告出現(xiàn)。這從某種意義上證明我的設想驻呐，ESB就是基于SCA規(guī)范的一種具體實現(xiàn)碴犬。
既然是企業(yè)服務的總線，其承載的流量是巨大的按傅，各式各樣的服務以不同的姿勢接入到總線中捉超，所以ESB首當其沖要解決的是不同協(xié)議的支撐和適配問題，其次唯绍，還需要對每個服務進行集成拼岳、編排和監(jiān)控。ESB的出現(xiàn)况芒，可以有效的打破企業(yè)內(nèi)部「信息孤島」的局面惜纸，讓數(shù)據(jù)也能成為企業(yè)的“流動資金”。
如果你能順利閱讀到此處绝骚，其實也就不難理解我在上述提到的SOA兩大核心要素：服務和治理耐版。
3、再談微服務
寫到最后皮壁，最重要的壓軸戲終于出現(xiàn)了椭更！我不禁要把Martin大神拿出來拜上兩拜。
微服務的流行舌狗，Martin功不可沒叽奥，這老頭也是個奇人，特別擅長抽象歸納和制造概念痛侍，我覺的這就是最牛逼的markting啊朝氓，感覺這也是目前國人欠缺的能力。
回到上述的ALL in ONE主届，這種模式下開發(fā)出來的應用赵哲，無論是可擴展性，還是可維護性君丁，都是非常差勁的枫夺，這與微服務的理念是相違背的。
微服務的目的是有效的拆分應用绘闷，實現(xiàn)敏捷開發(fā)和快速部署 橡庞。
以上的這個小方塊，在互聯(lián)網(wǎng)圈子里印蔗，被眾多巨巨們所津津樂道扒最。這是一個三維模型，三個方向分別代表了三種可擴展的維度：
X-axis：Application級別的橫向擴展华嘹。當然吧趣，它們都是躲在Load Balance后面，等待欽點耙厚；
Y-axis：可以看做是應用內(nèi)的擴展再菊，即一個應用內(nèi)的每個服務可以部署多個實例；
Z-axis：和X-axis有些相似颜曾，都是應用級別的擴展，不同的是秉剑，每個副本只訪問部分數(shù)據(jù)泛豪，即多了“分庫分表”的工作。
雖然三個維度是相互垂直的侦鹏，但是并不代表沒有任何關系诡曙，也不是非要三選一不可。
我們可以試著感受一下：
X-axis代表運行多個應用實例略水，外加Load Balance价卤，提升了應用的整體抗壓性；
Y-axis代表將應用進一步分解為微服務渊涝，并部署多個實例慎璧，也就意味著針對應用內(nèi)的某幾個服務床嫌，提升其性能，使其不易觸碰到瓶頸胸私；
當數(shù)據(jù)量大時厌处，還可以用Z-axis將服務按數(shù)據(jù)分區(qū)（分表）。
從這個角度看岁疼，這是應用性能提升的幾個手段阔涉。
再說回微服務。下面引用一段總結性的文字：
Martin自己也說了捷绒，每個人對微服務都可以不盡相同瑰排，不過大概的標準還是有一些的。
1暖侨、分布式服務組成的系統(tǒng)
2椭住、按照業(yè)務而不是技術來劃分組織
3、做有生命的產(chǎn)品而不是項目
4它碎、Smart endpoints and dumb pipes（我的理解是強服務個體和弱通信）
5函荣、自動化運維（DevOps）
6、容錯
7扳肛、快速演化
而在我看來傻挂，微服務這種思想其實對SOA的一種傳承和延伸，微服務吸納了SOA所有的優(yōu)勢之處挖息，并且也具備了SOA沒有的功能金拒。
對于前面三個標準，同樣適用于SOA套腹，而后面的幾點绪抛，則有所分別了。
第4個標準對前面提及的ESB的理念是有所沖擊的电禀。SOA側(cè)重于對服務的治理幢码，服務的治理者自然就成為了系統(tǒng)強勢的一方，以ESB為中心尖飞，如果接入的服務多了症副，ESB將會變得越來越重。所以微服務主張的是去ESB政基，去中心化贞铣，消息的解析放在服務內(nèi)進行。
對于5~7個標準沮明，在SOA中并沒有過多強調(diào)辕坝，因為已經(jīng)不在其標準范疇內(nèi)。而在微服務中荐健，卻是必須的酱畅。
不難看出琳袄，微服務完全具備了這個時代鮮明的特色，這些特色圣贸，在以往是不具備的挚歧，因為不那么被人們所重視。
在現(xiàn)在看來吁峻，有了Docker滑负，DevOps等關鍵技術的加持，整個微服務生態(tài)還是比較完整的用含，也就不難理解微服務為什么這么火了矮慕。
關于微服務的具體實踐，就不在此贅述了啄骇，可以關注我痴鳄，關注后續(xù)文章
想要一起學習交流，或者系統(tǒng)的學習java的可以加企鵝群475820025? ?進群邀請碼 （寂靜）
學習交流C/C++的可以加群??553014383? 進群邀請碼 （寂靜）
每個群內(nèi)都有各種相關學習資源缸夹，還有大神萌新互動交流痪寻。歡迎大家加群
