前言

微服務(wù)自從Fred George提出课梳，后續(xù)逐漸由不同的大師如Martin Fowler赘理，Neal Ford等人接力推廣演進(jìn)后，已經(jīng)在業(yè)界如火如荼的流行了好些年险绘，它的目的是有效的拆分應(yīng)用，實(shí)現(xiàn)敏捷開(kāi)發(fā)和部署?誉碴。

　　借用Martin?Fowler的話說(shuō)：

　　微服務(wù)架構(gòu)是一種架構(gòu)模式宦棺，它提倡將單一應(yīng)用程序劃分成一組小的服務(wù)，服務(wù)之間互相協(xié)調(diào)黔帕、互相配合代咸，為用戶提供最終價(jià)值。

　　每個(gè)服務(wù)運(yùn)行在其獨(dú)立的進(jìn)程中成黄，服務(wù)與服務(wù)間采用輕量級(jí)的通信機(jī)制互相協(xié)作（通常是基于HTTP協(xié)議的RESTful API）呐芥。

　　每個(gè)服務(wù)都圍繞著具體業(yè)務(wù)進(jìn)行構(gòu)建，并且能夠被獨(dú)立的部署到生產(chǎn)環(huán)境奋岁、類生產(chǎn)環(huán)境等思瘟。

　　從這里面我們可以看出，這里面的關(guān)鍵字是“小”闻伶，“獨(dú)立”滨攻，“輕量級(jí)”，從中我們可以總結(jié)為：服務(wù)之間是松耦合的，不相互影響的铡买。但“小”絕對(duì)不是字面上理解的小更鲁，我們下面將介紹一個(gè)服務(wù)的小的維度是什么霎箍。

　　單體服務(wù)

　　提到微服務(wù)奇钞，就不能不提到單體應(yīng)用了，我們通常所說(shuō)的單體應(yīng)用漂坏，即將所有功能都打包成在一個(gè)獨(dú)立單元的應(yīng)用程序景埃。

　　一個(gè)典型的單體應(yīng)用就是將所有業(yè)務(wù)場(chǎng)景的表示層、業(yè)務(wù)邏輯層和數(shù)據(jù)訪問(wèn)層放在一個(gè)工程中顶别，最終經(jīng)過(guò)編譯谷徙、打包，部署在一臺(tái)服務(wù)器上驯绎。

?　　在微服務(wù)或者SOA架構(gòu)沒(méi)提出來(lái)之前完慧，業(yè)界應(yīng)該基本都是單體應(yīng)用，分布式系統(tǒng)架構(gòu)在業(yè)界內(nèi)已經(jīng)有較長(zhǎng)的歷史了剩失，但單體應(yīng)用還是占據(jù)著大半壁江山屈尼。

　　存在即合理的

　　所以存在的東西都具備自己的優(yōu)點(diǎn)，我們來(lái)看一下單體應(yīng)用的優(yōu)點(diǎn)拴孤。

　　優(yōu)點(diǎn)

開(kāi)發(fā)方便：集中式管理脾歧，只需要在一個(gè)解決方案中編程和構(gòu)建

測(cè)試相對(duì)簡(jiǎn)單：只需要寫(xiě)一些端到端的測(cè)試用例，啟動(dòng)即可整體聯(lián)調(diào)查找問(wèn)題

部署手段簡(jiǎn)易：只需要把一份構(gòu)建好的文件丟上服務(wù)器

容易橫向擴(kuò)展：可以部署多個(gè)實(shí)例演熟，由負(fù)載均衡器調(diào)度即可

沒(méi)有分布式的管理/調(diào)用開(kāi)銷

　　這些優(yōu)點(diǎn)是顯著的鞭执，它們能給人帶來(lái)明確的掌控感覺(jué)，而不是不可控的飄渺虛無(wú)感芒粹。

　　然而兄纺，它的缺點(diǎn)也是非常明顯的，想想我們現(xiàn)在大部分的項(xiàng)目化漆，伴隨著越來(lái)越快的互聯(lián)網(wǎng)信息時(shí)代估脆，業(yè)務(wù)要的就是靈活變動(dòng)和快速上線，針對(duì)于靈活和快速获三，單體應(yīng)用是無(wú)法提供的旁蔼。

　　缺點(diǎn)

開(kāi)發(fā)效率低：系統(tǒng)龐大復(fù)雜，沒(méi)人能理解全部疙教，且所有的開(kāi)發(fā)在一個(gè)項(xiàng)目改代碼棺聊，代碼沖突不斷

代碼維護(hù)難：代碼功能耦合在一起，牽一發(fā)動(dòng)全身

部署不靈活：構(gòu)建時(shí)間長(zhǎng)贞谓，任何小修改必須重新構(gòu)建整個(gè)項(xiàng)目限佩，這個(gè)周期往往很長(zhǎng)

穩(wěn)定性不高：系統(tǒng)缺乏故障隔離，一個(gè)微不足道的小問(wèn)題，可以導(dǎo)致整個(gè)應(yīng)用掛掉

　　可以肯定的是祟同，一旦你的應(yīng)用變成一個(gè)又大又復(fù)雜的怪物作喘，那開(kāi)發(fā)團(tuán)隊(duì)肯定很痛苦。敏捷開(kāi)發(fā)和部署舉步維艱晕城，每次的開(kāi)發(fā)都會(huì)引出其他問(wèn)題泞坦，因?yàn)樗鼈兊鸟詈闲蕴珡?qiáng)了。

　　其中最主要問(wèn)題就是這個(gè)應(yīng)用太復(fù)雜砖顷，以至于任何單個(gè)開(kāi)發(fā)者都不可能搞懂它贰锁。因此，修正bug和正確的添加新功能變的非常困難滤蝠，并且很耗時(shí)豌熄。

　　另外，團(tuán)隊(duì)士氣也會(huì)走下坡路物咳。如果代碼難于理解锣险，就不可能被正確的修改，最終會(huì)走向巨大的览闰、不可理解的泥潭芯肤。

　　所以在這時(shí)，很多人把目光投向了微服務(wù)焕济。

　　微服務(wù)

　　由來(lái)

　　首先任何的技術(shù)不會(huì)平白無(wú)故的出現(xiàn)纷妆，它們的出現(xiàn)，是某些痛點(diǎn)一直在困擾著大多數(shù)人晴弃，所以這些技術(shù)的出現(xiàn)掩幢，都是有特定背景的。

　　從上面來(lái)看上鞠，有訴求才會(huì)有發(fā)展际邻，沒(méi)有單體式應(yīng)用的痛點(diǎn)折磨，沒(méi)有分布式系統(tǒng)的鋪墊芍阎，沒(méi)有自動(dòng)化工具的應(yīng)用世曾，是不可能出現(xiàn)所謂的微服務(wù)的，所以我們可以說(shuō)谴咸，微服務(wù)架構(gòu)是演進(jìn)過(guò)來(lái)的轮听。

　　微服務(wù)是一種架構(gòu)風(fēng)格

　　微服務(wù)在Chris口中，是一種架構(gòu)設(shè)計(jì)風(fēng)格岭佳，而在國(guó)內(nèi)血巍，更多的開(kāi)發(fā)者視之為具體的某個(gè)服務(wù)，所以我們通常的說(shuō)法是“一個(gè)微服務(wù)”珊随，按照Chris自己的說(shuō)法述寡，系統(tǒng)是采用了微服務(wù)架構(gòu)設(shè)計(jì)風(fēng)格柿隙，由若干個(gè)服務(wù)構(gòu)成，這才是一個(gè)完整的微服務(wù)鲫凶。

　　“微”服務(wù)

　　微服務(wù)這個(gè)術(shù)語(yǔ)讓我們很多人錯(cuò)誤的將關(guān)注點(diǎn)聚焦在“微”上禀崖，它暗示著我們服務(wù)的顆粒度是應(yīng)該非常小的。

實(shí)際上螟炫，大小不是一個(gè)重要的考慮因素波附。

細(xì)想一下微服務(wù)的進(jìn)化鋪墊，我們?yōu)槭裁匆鸱?wù)不恭？是由于單體應(yīng)用的臃腫龐大且耦合性過(guò)高的特性叶雹。所以我們?cè)诓鸱值倪^(guò)程中，更多的考慮方面是在如何避免單體應(yīng)用的耦合問(wèn)題换吧，不然拆出來(lái)的一樣是一個(gè)相互牽扯的單體微應(yīng)用，所以我們的關(guān)注點(diǎn)應(yīng)該是在每個(gè)服務(wù)的松散耦合上钥星，確定好它的邊界沾瓦，讓每個(gè)服務(wù)能做到真正的松耦合，而不僅僅是大小問(wèn)題谦炒。

誠(chéng)然贯莺，小服務(wù)確實(shí)是維護(hù)性更高。但我們微服務(wù)的目標(biāo)宁改，更多的是定義我們的工作方式缕探，比如定義為可由小團(tuán)隊(duì)自主開(kāi)發(fā)，并且交付時(shí)間短还蹲，與其他團(tuán)隊(duì)協(xié)作少爹耗，不會(huì)相互影響的工作方式。

所以我們服務(wù)的設(shè)計(jì)和定義谜喊，需遵循我們的目標(biāo)法則去規(guī)劃的潭兽，而這個(gè)法則就是服務(wù)內(nèi)的高內(nèi)聚和服務(wù)間的低耦合。

　　微服務(wù)架構(gòu)通過(guò)把一些小的斗遏，松耦合的服務(wù)組織在一起山卦，重新定義了我們的應(yīng)用，這樣的結(jié)果是提升了我們開(kāi)發(fā)階段的效率诵次，特別是可維護(hù)性账蓉，可測(cè)試性和可部署性，通過(guò)這樣的方式影響著團(tuán)隊(duì)的效率提升逾一。

?　　服務(wù)的本質(zhì)

　　每個(gè)構(gòu)成微服務(wù)架構(gòu)體系的服務(wù)铸本，本質(zhì)都是一個(gè)可獨(dú)立運(yùn)行的應(yīng)用程序。

　　這個(gè)服務(wù)是由一組邊界清晰嬉荆，高內(nèi)聚的職責(zé)組成归敬，而且它可以做自己的負(fù)載均衡，獨(dú)立部署，獨(dú)立發(fā)布汪茧，能夠快速脫離單體應(yīng)用的局限性快速上線椅亚。

　　這也是微服務(wù)的優(yōu)勢(shì)所在，只要做到接口兼容或者版本兼容舱污，不必做過(guò)多的服務(wù)依賴呀舔。??

　　優(yōu)點(diǎn)

　　微服務(wù)的優(yōu)點(diǎn)眾多，但我認(rèn)為它最重要的是改變著我們的工作方式扩灯，如：

更加契合敏捷開(kāi)發(fā)

　　我們知道媚赖，敏捷開(kāi)發(fā)這種軟件工程方法已經(jīng)在很多公司中采用了，敏捷開(kāi)發(fā)的意義在于更快速的交付可運(yùn)行版本以及迭代做功能最小閉環(huán)珠插，它是這個(gè)信息時(shí)代的必然產(chǎn)物惧磺。當(dāng)我們采用微服務(wù)時(shí)，在團(tuán)隊(duì)自治的同時(shí)捻撑，意味著更快速的開(kāi)發(fā)和交付磨隘。

　　敏捷開(kāi)發(fā)帶來(lái)的不僅僅是開(kāi)發(fā)模式上的改變，也帶來(lái)了組織結(jié)構(gòu)的變化顾患，衍生出更多的小團(tuán)隊(duì)自治番捂，小團(tuán)隊(duì)實(shí)施敏捷開(kāi)發(fā)，帶來(lái)更快的功能迭代和獨(dú)立發(fā)布江解，即使出現(xiàn)問(wèn)題也不會(huì)影響整個(gè)應(yīng)用设预。

Devops文化的推廣

　　在Neal Ford的微服務(wù)理念中，Microservices are the first post DevOps revolution architecture犁河，DevOps所涵蓋的一系列文化和理念鳖枕，是微服務(wù)演進(jìn)過(guò)程中必不可少的先決條件。

　　微服務(wù)的流行呼股，更好的推動(dòng)了Devops文化，它們是相輔相成的彭谁。

　　比較確定的說(shuō)吸奴，在傳統(tǒng)的運(yùn)維模式下，是很難有效實(shí)現(xiàn)微服務(wù)架構(gòu)的缠局，因?yàn)槲⒎?wù)在治理層面需要自動(dòng)化基礎(chǔ)設(shè)施则奥、自動(dòng)化部署、自動(dòng)化驗(yàn)證狭园、以及利用有效的工具完成運(yùn)維读处、監(jiān)控、告警等唱矛。而只有將DevOps與微服務(wù)緊密的結(jié)合起來(lái)罚舱，才能達(dá)到事半功倍的效果井辜。

技術(shù)棧的選擇

　　當(dāng)我們采用單體服務(wù)時(shí)，它所使用的編程語(yǔ)言就已經(jīng)確定了管闷，但微服務(wù)支持使用不同的語(yǔ)言開(kāi)發(fā)粥脚，允許你選擇合適的技術(shù)棧。

　　我們的企業(yè)發(fā)展能存活的根本是什么包个？就是能賺錢才能活下去刷允，換言之也就是對(duì)成本的控制。當(dāng)我們能夠采用適合自己的成本投入方式碧囊，在各個(gè)環(huán)節(jié)和服務(wù)采用最合適的技術(shù)棧树灶，能夠給企業(yè)的投入成本做一定的保障。?

組織結(jié)構(gòu)的變化

　　組織結(jié)構(gòu)變化會(huì)給我們帶來(lái)什么好處糯而？

其實(shí)我們一直在暗示著天通，服務(wù)的職責(zé)要單一，做到專歧蒋，然而這個(gè)專并不僅僅在服務(wù)的職責(zé)層面上土砂，還有在組織結(jié)構(gòu)上， 微服務(wù)勢(shì)必會(huì)影響到我們的中臺(tái)戰(zhàn)略能力谜洽，所以我們更需要不同的組專注于不同的技術(shù)和業(yè)務(wù)。

　　簡(jiǎn)單點(diǎn)說(shuō)吴叶，讓專業(yè)的人做專業(yè)的事阐虚！這樣才能更好的提高整體的生產(chǎn)效率，而不是事事都有牽絆蚌卤。

云生態(tài)下的新技術(shù)沖擊

　　這個(gè)似乎并不是優(yōu)點(diǎn)实束，但我相信對(duì)很多人來(lái)說(shuō)，這又確切是個(gè)優(yōu)點(diǎn)逊彭，因?yàn)檫@些技術(shù)對(duì)所有有技術(shù)抱負(fù)的人來(lái)說(shuō)咸灿，造就了一個(gè)很好的時(shí)代。

　　當(dāng)我們采用微服務(wù)時(shí)侮叮，目光已經(jīng)不能僅局限于應(yīng)用層面的開(kāi)發(fā)了避矢，容器化，服務(wù)編排工具囊榜，服務(wù)網(wǎng)格审胸，云原生等新生的技術(shù)，讓我們知道如何更好的治理好自己的服務(wù)群卸勺，支撐自己的服務(wù)更好的擴(kuò)展砂沛。

?　　挑戰(zhàn)

　微服務(wù)本質(zhì)上是分布式系統(tǒng)，所以在分布式系統(tǒng)中遇到的難點(diǎn)曙求，在微服務(wù)中都會(huì)遇到碍庵，分布式系統(tǒng)進(jìn)程間的通信保證映企，網(wǎng)絡(luò)開(kāi)銷以及事務(wù)處理從來(lái)都是難題

　微服務(wù)的流行，離不開(kāi)容器化和云生態(tài)静浴，離不開(kāi)gRPC堰氓，ServiceMesh，云原生等新技術(shù)的崛起以及實(shí)際生產(chǎn)應(yīng)用马绝。換言之豆赏，你需要了解乃至熟知這些技術(shù)，畢竟傳統(tǒng)的單體應(yīng)用只需要更多的專注于應(yīng)用層面

　微服務(wù)架構(gòu)帶來(lái)過(guò)多的運(yùn)維操作富稻，需要團(tuán)隊(duì)具備一定的 DevOps 技能掷邦，在運(yùn)維層面開(kāi)銷會(huì)很大

? ?治理中心（包括基礎(chǔ)設(shè)施架構(gòu)，集合著CICD椭赋，監(jiān)控等微服務(wù)必要的非功能性需求）

? ?測(cè)試將會(huì)是非常難抚岗，因?yàn)樗辉偈嵌说蕉耍€很大可能會(huì)存在多版本的不同服務(wù)帶來(lái)不同的測(cè)試場(chǎng)景

這些挑戰(zhàn)哪怔，分析一下本質(zhì)宣蔚，就是對(duì)人的要求更高了，所以說(shuō)采用微服務(wù)并不僅僅是技術(shù)層面帶來(lái)的沖擊认境，更多的是對(duì)人帶來(lái)的思想/能力沖擊胚委。

　　微服務(wù)的解剖

　　在實(shí)踐微服務(wù)的過(guò)程中，可以劃分為三部曲：

服務(wù)劃分

服務(wù)開(kāi)發(fā)

服務(wù)治理

　　這三部也是涵蓋了微服務(wù)架構(gòu)落地的全部步驟叉信，每一步都會(huì)有不同的指導(dǎo)方法論用于區(qū)別于傳統(tǒng)的開(kāi)發(fā)思想亩冬，后續(xù)將會(huì)基于這些步驟結(jié)合流行的方法學(xué)來(lái)指導(dǎo)我們服務(wù)落地。

　　總結(jié)

　　微服務(wù)不是銀彈硼身！

　　我特別喜歡說(shuō)的一句話是：任何的技術(shù)硅急，都是有適用場(chǎng)景的。所以我很喜歡看到那些能基于目前的痛點(diǎn)以及中長(zhǎng)期的發(fā)展所面臨的問(wèn)題分析佳遂， 對(duì)比單體架構(gòu)和微服務(wù)架構(gòu)帶來(lái)的收益比营袜。

　　我們需要的是思考技術(shù)能帶來(lái)的價(jià)值，而不是為技術(shù)瘋狂丑罪。

　　任何的技術(shù)手段荚板，都是用來(lái)服務(wù)業(yè)務(wù)的，能支撐業(yè)務(wù)創(chuàng)造價(jià)值的巍糯，才是好技術(shù)啸驯，否則這些技術(shù)一文不值。

不管黑貓白貓祟峦，捉到老鼠的就是好貓罚斗！

　　微服務(wù)架構(gòu)也不例外。

　　所以當(dāng)你想要采用微服務(wù)時(shí)宅楞，問(wèn)一下自己這些問(wèn)題：

為什么團(tuán)隊(duì)想要采用微服務(wù)针姿？采用后團(tuán)隊(duì)將能得到什么袱吆？（說(shuō)明充分了解了單體/微服務(wù)的優(yōu)缺點(diǎn)，并能清晰了解到業(yè)務(wù)以及團(tuán)隊(duì)在中長(zhǎng)期所面臨的問(wèn)題點(diǎn)）

是否組織結(jié)構(gòu)以及文化底蘊(yùn)有一定的支撐距淫？（團(tuán)隊(duì)是否能經(jīng)得起微服務(wù)所帶來(lái)的沖擊）

是否有一定的技術(shù)基礎(chǔ)支撐绞绒？（說(shuō)明能對(duì)微服務(wù)的所面臨的技術(shù)挑戰(zhàn)有了一定的認(rèn)識(shí)）

　　當(dāng)你能做到對(duì)以上問(wèn)題都有清晰答案后，且仍然決定采用微服務(wù)架構(gòu)榕暇，說(shuō)明你已經(jīng)對(duì)微服務(wù)所帶來(lái)的收益比有了自己的判斷蓬衡。

　　Last but not least

在將組織推向微服務(wù)道路之前，最重要的決策人理解了“為什么是微服務(wù)”彤枢，而不是“為什么不是微服務(wù)”狰晚。

文章來(lái)源：http://www.feixueteam.net/