一、什么是微服務(wù)
微服務(wù)就是一些協(xié)同工作的小而自治的服務(wù)。它有以下兩個特性：
1.很小铐达，專注于做好一件事
在單體應(yīng)用時代，我們把所有的業(yè)務(wù)模塊都寫在一個系統(tǒng)內(nèi)檬果，隨著新功能的增加瓮孙，系統(tǒng)的代碼庫會越來越大，以至于想要知道該在什么地方做修改都很困難汁汗。雖然系統(tǒng)內(nèi)劃分了模塊衷畦，但事實上這些模塊的界限可能很難維護，相似的代碼隨處可見知牌，使得修復(fù)bug或?qū)崿F(xiàn)更加困難祈争。
內(nèi)聚性是指把因相同原因而變化的東西聚合到一起，把不同原因而變化的東西分離開來角寸。微服務(wù)將這個理念應(yīng)用在獨立的服務(wù)上菩混，根據(jù)業(yè)務(wù)的邊界來確定服務(wù)的邊界，這樣就很容易確定某個功能應(yīng)該放在哪個服務(wù)中扁藕。根據(jù)業(yè)務(wù)模塊拆分之后就可以很好的避免由于系統(tǒng)代碼庫過大而衍生出來的相關(guān)問題沮峡。
關(guān)于服務(wù)拆分的粒度問題，需要考慮的因素：服務(wù)越小亿柑，微服務(wù)架構(gòu)的優(yōu)點和缺點也就越明顯邢疙。服務(wù)越小，獨立性帶來的好處就越多望薄，但是管理大量的服務(wù)也會越復(fù)雜疟游。
2.自治性
微服務(wù)是一個獨立的實體，可以獨立的部署痕支，服務(wù)之間通過網(wǎng)絡(luò)調(diào)用進行通信颁虐。對于一個服務(wù)來說，我們需要考慮的是什么應(yīng)該暴露卧须，什么應(yīng)該隱藏另绩。如果暴露得過多，那么服務(wù)消費方會與該服務(wù)的內(nèi)部實現(xiàn)產(chǎn)生耦合花嘶，從而降低服務(wù)的自治性笋籽。
二、微服務(wù)帶來的好處
1.技術(shù)異構(gòu)性
我們可以在不同的服務(wù)中選擇合適該服務(wù)的技術(shù)實現(xiàn)察绷。
2.彈性
在單體系統(tǒng)中干签，如果部署系統(tǒng)的服務(wù)器出了故障或者系統(tǒng)內(nèi)某個模塊的功能代碼導(dǎo)致CPU/內(nèi)存使用率過高，那么則會導(dǎo)致整個應(yīng)用都不可用拆撼。而微服務(wù)則不會有這種問題容劳，某個服務(wù)出現(xiàn)問題不會影響其他服務(wù)的正常運行喘沿。
3.擴展
單體系統(tǒng)只能作為一個整體進行擴展，即使系統(tǒng)中只有一小部分存在性能問題竭贩，也需要對整個服務(wù)進行擴展蚜印。如果使用微服務(wù)，那么我們只需要針對需要擴展的服務(wù)進行擴展留量，比如訪問率高的服務(wù)我們可以部署多幾個節(jié)點窄赋。
4.簡化部署
單體系統(tǒng)中即使只修改了一行代碼，也需要重新部署整個系統(tǒng)楼熄，影響范圍大忆绰，出問題的可能性更高。微服務(wù)中只需要部署對應(yīng)的服務(wù)可岂，不會對其他服務(wù)產(chǎn)生影響错敢。
5.與組織結(jié)構(gòu)相匹配
各個服務(wù)由小團隊開發(fā)維護，避免出現(xiàn)過大的代碼庫缕粹，從而獲得理想的團隊大小及生產(chǎn)力稚茅。
6.對可替代性的優(yōu)化
在龐大的單體系統(tǒng)中，如果我們要修改/刪除里面的某些代碼帶來問題的可能性更高平斩，而微服務(wù)的代碼量較小亚享，在需要重寫替換時風(fēng)險更小。
三绘面、微服務(wù)帶來的挑戰(zhàn)
1.微服務(wù)的部署與運維
如何能更高效的部署服務(wù)以及保證服務(wù)的高可用性欺税。
2.分布式帶來的復(fù)雜性
需要處理分布式事務(wù)或者與CAP相關(guān)的問題。
3.微服務(wù)的監(jiān)控
包括服務(wù)可用性的監(jiān)控揭璃、服務(wù)調(diào)用鏈路的監(jiān)控魄衅。
以上內(nèi)容根據(jù)《微服務(wù)設(shè)計》整理。
四塘辅、哪些情況下不適合使用微服務(wù)架構(gòu)
結(jié)合本人的經(jīng)歷，總結(jié)了以下幾種情況可能不適合采用微服務(wù)架構(gòu)皆撩。
1.想快速上線產(chǎn)品
如果公司想短時間內(nèi)快速上線一款產(chǎn)品來驗證市場扣墩，那么此時采用微服務(wù)架構(gòu)并不一定合適。因為微服務(wù)架構(gòu)本身帶來的復(fù)雜性扛吞，使得我們不僅要開發(fā)業(yè)務(wù)需求呻惕，還得解決微服務(wù)架構(gòu)方方面面的技術(shù)問題，而其中的某些技術(shù)問題還是很難解決的滥比，比如分布式事務(wù)等問題亚脆，這樣一來必然會拉長項目周期，導(dǎo)致產(chǎn)品無法按時交付市場盲泛。而如果此時采用單體架構(gòu)去開發(fā)濒持，只需要專注業(yè)務(wù)需求即可键耕，待到產(chǎn)品取得成功并逐步發(fā)展時，再轉(zhuǎn)型至微服務(wù)架構(gòu)也不遲柑营。
2.團隊微服務(wù)技術(shù)基礎(chǔ)較薄弱
如果技術(shù)團隊成員沒有良好的微服務(wù)理論或者實踐基礎(chǔ)屈雄，對開發(fā)人員而言：那有可能造成的一個問題是，在他們編寫代碼時官套，還是按照單體應(yīng)用的思想去編寫代碼酒奶，比如在跨服務(wù)跨庫調(diào)用的場景，完全不會考慮到分布式事務(wù)的問題奶赔，容易造成業(yè)務(wù)服務(wù)數(shù)據(jù)的不一致惋嚎，從而引發(fā)故障。對于運維人員而言：如果不具備自動化部署能力站刑，那么要部署N多個服務(wù)另伍，這將是一件痛苦的事。所以在采用微服務(wù)架構(gòu)之前笛钝，請確保團隊成員已經(jīng)具備微服務(wù)架構(gòu)的理論或?qū)嵺`基礎(chǔ)质况。
3.系統(tǒng)規(guī)模較小
如果系統(tǒng)規(guī)模較小，業(yè)務(wù)模塊可能不超過5個玻靡，同樣不適合采用微服務(wù)架構(gòu)结榄。因為對于微服務(wù)架構(gòu)來說，復(fù)雜性是一個重要的考慮因素囤捻，可能要解決微服務(wù)架構(gòu)帶來的復(fù)雜性會比開發(fā)系統(tǒng)需求更難臼朗，這樣未免顯得有些得不償失。
4.只是想體驗微服務(wù)
現(xiàn)在微服務(wù)的熱度很高蝎土，有的技術(shù)團隊可能想體驗一把视哑，于是就準(zhǔn)備在項目中引入微服務(wù)。但是在這之前要先想清楚是否能hold住誊涯，否則只會在采坑的路上越走越遠(yuǎn)挡毅，其實對于公司來說是不關(guān)心具體的技術(shù)實現(xiàn)的，公司領(lǐng)導(dǎo)只關(guān)心業(yè)務(wù)需求能否實現(xiàn)暴构。對我們開發(fā)而言跪呈，也應(yīng)當(dāng)以實現(xiàn)業(yè)務(wù)為主要目標(biāo)。
總的來說取逾，由于微服務(wù)架構(gòu)帶來的開發(fā)與運維的復(fù)雜性耗绿，如果存在上述的一些問題，建議不采用微服務(wù)架構(gòu)砾隅。
五误阻、微服務(wù)的實踐
微服務(wù)架構(gòu)技術(shù)選型包括Spring Cloud和Dubbo，兩者之間的區(qū)別對比在網(wǎng)上有相關(guān)資料，這里不再贅述究反⊙岸ǎ總的來說Spring Cloud是微服務(wù)架構(gòu)的一套完整的解決方案。
Spring Cloud提供了一系列的組件來支撐微服務(wù)奴紧，一些推薦使用的基礎(chǔ)組件包括：
- 服務(wù)注冊發(fā)現(xiàn)：Eureka
- 服務(wù)網(wǎng)關(guān)：Zuul
- 服務(wù)調(diào)用：Feign
- 軟負(fù)載均衡：Ribbon
- 限流熔斷：Hystrix
- 配置中心：Apollo（備：攜程開源特姐，推薦使用）
- 日志監(jiān)控：ELK
- 服務(wù)調(diào)用鏈路監(jiān)控：可選的有CAT、Zipkin黍氮、SkyWalking
雖然Spring Cloud提供了完善的組件唐含，但是在具體的實踐過程中還是會有一些坑要踩。
六沫浆、總結(jié)
在我們享受微服務(wù)帶來好處的同時捷枯，也得接受它帶來的挑戰(zhàn)，能否實施微服務(wù)也要結(jié)合實際情況专执，從實際出發(fā)淮捆。
另外一個很重要的點是，制定開發(fā)規(guī)范本股，提高代碼的質(zhì)量攀痊，別留下太多的技術(shù)債務(wù)，做到這些雖然不容易但是很重要拄显。
如果文章對你有幫助的話苟径，給文章點個贊吧。
如果有寫得不正確的地方躬审，歡迎指出棘街。
文章首發(fā)公眾號：會跳舞的機器人，歡迎掃碼關(guān)注承边。
