微服務(wù)已經(jīng)火了有一段時間了，Martin Fowler 在2014年3月也開始發(fā)文對微服務(wù)進(jìn)行說明和分析，近兩年各種技術(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ò)進(jìn)行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ù)進(jìn)行嘗試，且隨著時間的推進(jìn)，單塊應(yīng)用會變得十分臃腫和復(fù)雜，很難保證一個人修改的代碼不影響到其他人的代碼，且開發(fā)者會對修改一些早期的代碼望而卻步，生怕自己的修改對整個系統(tǒng)造成影響。但是單塊應(yīng)用也正因為采用單一技術(shù)棧，使得團隊在具體技術(shù)層面容易有基本一致的認(rèn)識，且因為對這一技術(shù)棧的了解和深入，開發(fā)者就能夠更自信的做出穩(wěn)定的程序。微服務(wù)由于服務(wù)間的高內(nèi)聚低耦合及其自治性，每個服務(wù)是可以獨立演進(jìn)的，所以團隊更容易嘗試各種新技術(shù)，也更容易對服務(wù)進(jìn)行修改或重構(gòu)，甚至可以對歷史遺留的代碼或服務(wù)直接進(jìn)行替換，因為代價很小，且對整個系統(tǒng)帶來影響是可控的，因此就使得團隊的創(chuàng)新和成長能力更加突出。
測試、部署和監(jiān)控。單塊應(yīng)用所有代碼都是放在一起的，工程中可能有分模塊也可能沒有，當(dāng)開發(fā)者提交代碼后，CD 系統(tǒng)跑完所有測試，再對整個工程進(jìn)行構(gòu)建和部署，整個流程的配置相對比較簡單，監(jiān)控需要的一些指標(biāo)通常運行環(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ù)進(jìn)行測試就需要同時啟動其依賴的服務(wù)，或者采用一些特殊方式來確保測試能夠走通，在部署服務(wù)過程中如果出現(xiàn)問題，還需要有服務(wù)降級手段來保障系統(tǒng)可用性，在監(jiān)控方面也要結(jié)合服務(wù)的運行環(huán)境做較多工作，且由于一項業(yè)務(wù)數(shù)據(jù)可能流經(jīng)多個服務(wù)，為了達(dá)到較好的監(jiān)控效果還要對調(diào)用鏈進(jìn)行維護。
然后是伸縮性。單塊應(yīng)用運行起來所有功能都是一個整體，一旦其中一個功能掛掉，可能整個應(yīng)用就掛掉了，要提高應(yīng)用可用性，就需要對整個應(yīng)用進(jìn)行水平伸縮擴展，例如在其他機器上再運行若干個應(yīng)用實例，并結(jié)合負(fù)載均衡等手段。另外就是當(dāng)應(yīng)用性能不足也需要做水平伸縮擴展時，也要對整個應(yīng)用進(jìn)行擴展，即便性能不足的只是其中某一個功能。雖然單塊應(yīng)用的擴展看起來不那么合理，有點浪費系統(tǒng)資源，但是操作簡單，維護成本不高。微服務(wù)在伸縮性上能夠更靈活的進(jìn)行擴展，符合去中心化的思想，結(jié)合現(xiàn)如今流行的公有云服務(wù)，可以隨時對需要提高可用性和性能的服務(wù)進(jìn)行擴展，但是由于服務(wù)實例的增加，隨之帶來的是服務(wù)管理的復(fù)雜度上升。
再說說性能。單塊應(yīng)用大都是進(jìn)程內(nèi)調(diào)用，性能的消耗一方面是系統(tǒng)外的網(wǎng)絡(luò)、IO等開銷，一方面是高并發(fā)的處理，這些可以通過一些主流的技術(shù)手段來改進(jìn)，但是由于單塊應(yīng)用內(nèi)部的高耦合和復(fù)雜性，往往對一處進(jìn)行優(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)用不會比進(jìn)程內(nèi)調(diào)用快，但是由于微服務(wù)易于重構(gòu)和創(chuàng)新，因此自身的整體性能也易于得到提高，且提高的性能一般遠(yuǎn)超出網(wǎng)絡(luò)的性能開銷。
除了以上幾點之外，微服務(wù)還需要處理分布式系統(tǒng)帶來的各種復(fù)雜問題，甚至要面對分布式事務(wù)或CAP相關(guān)問題等等，微服務(wù)相比單塊應(yīng)用確實解決了很多問題，也帶來了一些新的問題，如何平衡和取舍，這就是架構(gòu)要考慮的問題，我的想法是取長補短，結(jié)合自己團隊目前的情況，設(shè)計符合自己的架構(gòu)，要知道沒有一種放之四海而皆準(zhǔn)的架構(gòu)方案，所以不要覺得別人用著好的模式你就可以直接拿來用，找到適合自己的方法才是架構(gòu)之道。
本文只是先挖個坑，沒什么內(nèi)容，以后會展開對微服務(wù)的思考，歡迎高人或?qū)ξ⒎?wù)有興趣的朋友和我交流。
本文同時發(fā)布于我的微信訂閱號
