微服務(wù)已經(jīng)火了有一段時間了幻碱，Martin Fowler 在2014年3月也開始發(fā)文對微服務(wù)進行說明和分析捐凭，近兩年各種技術(shù)社區(qū)內(nèi)對微服務(wù)的分享和討論也比比皆是。和其他技術(shù)話題一樣，爭議總是不少的御板，有爭議說明大家都在思考，所以我也參與到大部隊中來牛郑，一邊學(xué)習(xí)一邊談?wù)勎业睦斫狻?/p>
什么是微服務(wù)
我理解微服務(wù)實際上是SOA的一種實現(xiàn)方式怠肋，它并不是什么新東西，也不是什么發(fā)明創(chuàng)造淹朋，只是在近幾年隨著虛擬化技術(shù)笙各、基礎(chǔ)設(shè)施自動化、分布式系統(tǒng)础芍、持續(xù)集成杈抢、領(lǐng)域驅(qū)動設(shè)計等的大量實踐應(yīng)運而生的一種模式，只因這些技術(shù)實踐相結(jié)合讓人們重新思考在軟件產(chǎn)品交付過程中如何做到更快仑性、更靈活惶楼，并擁抱變化，從而總結(jié)出了微服務(wù)的架構(gòu)風(fēng)格。
微服務(wù)特點
既然有個“微”字歼捐，那么很多人就會覺得代碼少就是微服務(wù)何陆，但實際上“微”和代碼量并沒有直接關(guān)系。這里的“微”更應(yīng)該理解為專注豹储，或者說高內(nèi)聚贷盲，一個微服務(wù)只專注于一種業(yè)務(wù)，遵循單一職責(zé)原則剥扣，不要為了小而小晃洒，要根據(jù)實際業(yè)務(wù)來找出服務(wù)邊界。
除了“專注”朦乏，微服務(wù)另一個主要特點就是高度自治球及，首先服務(wù)架構(gòu)要和團隊結(jié)構(gòu)相匹配，此外服務(wù)間是低耦合的呻疹，服務(wù)間通過網(wǎng)絡(luò)進行API調(diào)用吃引，服務(wù)隱藏內(nèi)部實現(xiàn)，修改一個服務(wù)不會對其他服務(wù)帶來影響刽锤，在這些前提下镊尺，團隊可以靈活構(gòu)建服務(wù)，并更快響應(yīng)不斷變化的需求并思。
微服務(wù)與單塊應(yīng)用架構(gòu)比較
先說說開發(fā)方面庐氮。單塊應(yīng)用意味著采用單一的技術(shù)棧，很難對新技術(shù)進行嘗試宋彼，且隨著時間的推進弄砍，單塊應(yīng)用會變得十分臃腫和復(fù)雜，很難保證一個人修改的代碼不影響到其他人的代碼输涕，且開發(fā)者會對修改一些早期的代碼望而卻步音婶，生怕自己的修改對整個系統(tǒng)造成影響。但是單塊應(yīng)用也正因為采用單一技術(shù)棧莱坎，使得團隊在具體技術(shù)層面容易有基本一致的認識衣式，且因為對這一技術(shù)棧的了解和深入，開發(fā)者就能夠更自信的做出穩(wěn)定的程序檐什。微服務(wù)由于服務(wù)間的高內(nèi)聚低耦合及其自治性碴卧，每個服務(wù)是可以獨立演進的，所以團隊更容易嘗試各種新技術(shù)乃正，也更容易對服務(wù)進行修改或重構(gòu)住册，甚至可以對歷史遺留的代碼或服務(wù)直接進行替換，因為代價很小烫葬，且對整個系統(tǒng)帶來影響是可控的界弧，因此就使得團隊的創(chuàng)新和成長能力更加突出。
測試搭综、部署和監(jiān)控垢箕。單塊應(yīng)用所有代碼都是放在一起的，工程中可能有分模塊也可能沒有兑巾，當開發(fā)者提交代碼后条获，CD 系統(tǒng)跑完所有測試，再對整個工程進行構(gòu)建和部署蒋歌，整個流程的配置相對比較簡單帅掘，監(jiān)控需要的一些指標通常運行環(huán)境的各種中間件也已經(jīng)提供了相應(yīng)的接口，應(yīng)用中需要做的事情并不多堂油。但是在大型的單塊應(yīng)用中修档，即使只修改了一行代碼，也需要跑完上述整個流程才能發(fā)布此次變更府框，由于重新發(fā)布整個應(yīng)用帶來的影響較大吱窝，考慮到風(fēng)險，應(yīng)用的發(fā)布頻率會很低迫靖，于是在兩次發(fā)布之間可能會積累了較多的修改和新特性的增加院峡，使得下一次發(fā)布和之前的版本差異很大，出問題的概率也就大大增加系宜。微服務(wù)中的服務(wù)都是獨立的照激，所以一個服務(wù)的發(fā)布不會影響其他服務(wù)，在發(fā)布出現(xiàn)問題的情況下也可以快速回滾盹牧，因此Bug修復(fù)和新特性增加都可以快速上線俩垃。但是由于服務(wù)之間存在著依賴關(guān)系，要對服務(wù)進行測試就需要同時啟動其依賴的服務(wù)汰寓，或者采用一些特殊方式來確保測試能夠走通吆寨，在部署服務(wù)過程中如果出現(xiàn)問題，還需要有服務(wù)降級手段來保障系統(tǒng)可用性踩寇，在監(jiān)控方面也要結(jié)合服務(wù)的運行環(huán)境做較多工作啄清，且由于一項業(yè)務(wù)數(shù)據(jù)可能流經(jīng)多個服務(wù)，為了達到較好的監(jiān)控效果還要對調(diào)用鏈進行維護俺孙。
然后是伸縮性辣卒。單塊應(yīng)用運行起來所有功能都是一個整體，一旦其中一個功能掛掉睛榄，可能整個應(yīng)用就掛掉了荣茫，要提高應(yīng)用可用性，就需要對整個應(yīng)用進行水平伸縮擴展场靴，例如在其他機器上再運行若干個應(yīng)用實例啡莉，并結(jié)合負載均衡等手段港准。另外就是當應(yīng)用性能不足也需要做水平伸縮擴展時，也要對整個應(yīng)用進行擴展咧欣，即便性能不足的只是其中某一個功能浅缸。雖然單塊應(yīng)用的擴展看起來不那么合理，有點浪費系統(tǒng)資源魄咕，但是操作簡單衩椒，維護成本不高。微服務(wù)在伸縮性上能夠更靈活的進行擴展哮兰，符合去中心化的思想毛萌，結(jié)合現(xiàn)如今流行的公有云服務(wù)，可以隨時對需要提高可用性和性能的服務(wù)進行擴展喝滞，但是由于服務(wù)實例的增加阁将，隨之帶來的是服務(wù)管理的復(fù)雜度上升。
再說說性能右遭。單塊應(yīng)用大都是進程內(nèi)調(diào)用冀痕，性能的消耗一方面是系統(tǒng)外的網(wǎng)絡(luò)、IO等開銷狸演，一方面是高并發(fā)的處理言蛇，這些可以通過一些主流的技術(shù)手段來改進，但是由于單塊應(yīng)用內(nèi)部的高耦合和復(fù)雜性宵距，往往對一處進行優(yōu)化的同時可能又帶來其他處的問題腊尚，因此很多大型單塊應(yīng)用的優(yōu)化重構(gòu)經(jīng)常只是不停地有人在說，實際操作起來卻舉步維艱满哪。微服務(wù)由于服務(wù)間都是網(wǎng)絡(luò)調(diào)用婿斥，很多人會覺得增加了太多網(wǎng)絡(luò)開銷，性能堪憂哨鸭，確實網(wǎng)絡(luò)調(diào)用不會比進程內(nèi)調(diào)用快民宿，但是由于微服務(wù)易于重構(gòu)和創(chuàng)新，因此自身的整體性能也易于得到提高像鸡，且提高的性能一般遠超出網(wǎng)絡(luò)的性能開銷活鹰。
除了以上幾點之外，微服務(wù)還需要處理分布式系統(tǒng)帶來的各種復(fù)雜問題只估，甚至要面對分布式事務(wù)或CAP相關(guān)問題等等志群，微服務(wù)相比單塊應(yīng)用確實解決了很多問題，也帶來了一些新的問題蛔钙，如何平衡和取舍锌云，這就是架構(gòu)要考慮的問題，我的想法是取長補短吁脱，結(jié)合自己團隊目前的情況桑涎，設(shè)計符合自己的架構(gòu)彬向，要知道沒有一種放之四海而皆準的架構(gòu)方案，所以不要覺得別人用著好的模式你就可以直接拿來用攻冷，找到適合自己的方法才是架構(gòu)之道娃胆。
本文只是先挖個坑，沒什么內(nèi)容讲衫，以后會展開對微服務(wù)的思考，歡迎高人或?qū)ξ⒎?wù)有興趣的朋友和我交流孵班。
本文同時發(fā)布于我的微信訂閱號
