微服務(wù)（Microservice）雖然是當(dāng)下剛興起的比較流行的新名詞，但本質(zhì)上來說脯厨，微服務(wù)并非什么新的概念铅祸。

實(shí)際上，很多 SOA（面向服務(wù)的架構(gòu)）實(shí)施成熟度比較好的企業(yè)合武，已經(jīng)在使用和實(shí)施微服務(wù)了临梗。只不過，它們只是在悶聲發(fā)大財(cái)稼跳，并不介意是否有一個(gè)比較時(shí)髦的名詞來明確表述 SOA 的這個(gè)發(fā)展演化趨勢罷了盟庞。

微服務(wù)其實(shí)就是服務(wù)化思路的一種最佳實(shí)踐方向，遵循 SOA 的思路汤善，各個(gè)企業(yè)在服務(wù)化治理的道路上走的時(shí)間長了什猖，踩的坑多了，整個(gè)軟件交付鏈路上各個(gè)環(huán)節(jié)的基礎(chǔ)設(shè)施逐漸成熟了红淡，微服務(wù)自然而然就誕生了不狮。

當(dāng)然，之所以叫微服務(wù)在旱，是與之前的服務(wù)化思路和實(shí)踐相比較而來的摇零。

早些年的服務(wù)實(shí)現(xiàn)和實(shí)施思路是將很多功能從開發(fā)到交付都打包成一個(gè)很大的服務(wù)單元（一般稱為 Monolith），而微服務(wù)實(shí)現(xiàn)和實(shí)施思路則更強(qiáng)調(diào)功能趨向單一桶蝎，服務(wù)單元小型化和微型化驻仅。

如果用“茶壺煮餃子”來打比方的話，原來我們是在一個(gè)茶壺里煮很多個(gè)餃子登渣，現(xiàn)在（微服務(wù)化之后）則基本上是在一個(gè)茶壺煮一個(gè)餃子噪服，而這些餃子就是服務(wù)的功能，茶壺則是將這些服務(wù)功能打包交付的服務(wù)單元胜茧，如圖 1 所示粘优。

圖 1??論茶壺里煮“餃子”的不同形式

所以，從思路和理念上來講竹揍，微服務(wù)就是要倡導(dǎo)大家盡量將功能進(jìn)行拆分敬飒，將服務(wù)粒度做小，使之可以獨(dú)立承擔(dān)對(duì)外服務(wù)的職責(zé)芬位，沿著這個(gè)思路開發(fā)和交付的軟件服務(wù)實(shí)體就叫作“微服務(wù)”无拗，而圍繞著這個(gè)思路和理念構(gòu)建的一系列基礎(chǔ)設(shè)施和指導(dǎo)思想，筆者將它稱為“微服務(wù)體系”昧碉。

微服務(wù)是怎么來的英染？

微服務(wù)的概念我們應(yīng)該大體了解了揽惹，那么微服務(wù)又是怎么來的？原來將很多功能打包為一個(gè)很大的服務(wù)單元進(jìn)行交付的做法不能滿足需求嗎四康？

實(shí)際上搪搏，并非原來“大一統(tǒng)”（Monolith）的服務(wù)化實(shí)踐不能滿足要求，也不是不好闪金，只是疯溺，它有自己存在的合理場景。

對(duì)于 Monolith 服務(wù)來說哎垦，如果團(tuán)隊(duì)不大囱嫩，軟件復(fù)雜度不高，那么漏设，使用 Monolith 的形式進(jìn)行服務(wù)化治理是比較合適的墨闲，而且，這種方式對(duì)運(yùn)維和各種基礎(chǔ)設(shè)施的要求也不高郑口。

但是鸳碧，隨著軟件系統(tǒng)的復(fù)雜度持續(xù)飆升，軟件交付的效率要求更高犬性，投入的人力以及各項(xiàng)資源越來越多瞻离，基于 Monolith 的服務(wù)化思路就開始“捉襟見肘”。

在開發(fā)階段仔夺，如果我們遵循 Monolith 的服務(wù)化理念琐脏，通常會(huì)將所有功能的實(shí)現(xiàn)都統(tǒng)一歸到一個(gè)開發(fā)項(xiàng)目下攒砖，但隨著功能的膨脹缸兔，這些功能一定會(huì)分發(fā)給不同的研發(fā)人員進(jìn)行開發(fā)，造成的后果就是吹艇，大家在提交代碼的時(shí)候頻繁沖突并需要解決這些沖突惰蜜，單一的開發(fā)項(xiàng)目成為了開發(fā)期間所有人的工作瓶頸。

為了減輕這種苦惱受神，我們自然會(huì)將項(xiàng)目按照要開發(fā)的功能拆分為不同的項(xiàng)目抛猖，從而負(fù)責(zé)不同功能的研發(fā)人員就可以在自己的代碼項(xiàng)目上進(jìn)行開發(fā)，從而解決了大家無法在開發(fā)階段并行開發(fā)的苦惱鼻听。

到了軟件交付階段财著，如果我們遵循 Monolith 的服務(wù)化理念，那么撑碴，我們一定是將所有這些開發(fā)階段并行開發(fā)的項(xiàng)目集合到一起進(jìn)行交付撑教。

這就涉及服務(wù)化早期實(shí)踐中比較有名的“火車模型”，即交付的服務(wù)就像一輛火車醉拓，而這個(gè)服務(wù)相關(guān)的所有功能對(duì)應(yīng)的項(xiàng)目成果伟姐，就是要裝上火車車廂的一件件貨物收苏，交付的列車只有等到所有項(xiàng)目都開發(fā)測試完成后才可以裝車出發(fā)，完成整個(gè)服務(wù)的交付愤兵。

很顯然鹿霸，只要有一個(gè)車廂沒有準(zhǔn)備好貨物（即功能項(xiàng)目未開發(fā)測試完成），火車就不能發(fā)車秆乳，服務(wù)就不能交付懦鼠，這大大降低了服務(wù)的交付效率。如果每個(gè)功能項(xiàng)目可以各自獨(dú)立交付屹堰，那么就不需要都等同一輛火車葛闷，各自出發(fā)就可以了。

順著這個(gè)思路双藕，自然而然地淑趾，大家逐漸各自獨(dú)立，每一個(gè)功能或者少數(shù)相近的功能作為單一項(xiàng)目開發(fā)完成后將作為一個(gè)獨(dú)立的服務(wù)單元進(jìn)行交付忧陪，從而在服務(wù)交付階段扣泊，大家也能夠并行不悖，各自演化而不受影響嘶摊。

所以延蟹，隨著服務(wù)和系統(tǒng)的復(fù)雜度逐漸飆升，為了能夠在整個(gè)軟件的交付鏈路上高效擴(kuò)展叶堆，將獨(dú)立的功能和服務(wù)單元進(jìn)行拆分阱飘，從而形成一個(gè)一個(gè)的微服務(wù)是自然而然發(fā)生的事情。

這就像打不同的戰(zhàn)役一樣虱颗，在雙方兵力不多沥匈、戰(zhàn)場復(fù)雜度不高的情況下，Monolith 的統(tǒng)一指揮調(diào)度方式是合適的忘渔。而一旦要打大的戰(zhàn)役（類似于系統(tǒng)復(fù)雜度提升）高帖，雙方一定會(huì)投入大量的兵力（軟件研發(fā)團(tuán)隊(duì)的規(guī)模增長），如果還是在狹小甚至固定的戰(zhàn)場上進(jìn)行廝殺畦粮，顯然施展不開散址！

所以，小戰(zhàn)役有小戰(zhàn)役的打法宣赔，大戰(zhàn)役有大戰(zhàn)役的戰(zhàn)法预麸，而微服務(wù)實(shí)際上就是一種幫助擴(kuò)展組織能力、提升團(tuán)隊(duì)效率的應(yīng)對(duì)“大戰(zhàn)役”的方法儒将，它幫助我們從軟件開發(fā)到交付吏祸，進(jìn)而到團(tuán)隊(duì)和組織層面多方位進(jìn)行擴(kuò)展。

總的來說椅棺，一方面微服務(wù)可以幫助我們應(yīng)對(duì)飆升的系統(tǒng)復(fù)雜度犁罩；另一個(gè)方面齐蔽，微服務(wù)可以幫助我們進(jìn)行更大范圍的擴(kuò)展，從開發(fā)階段項(xiàng)目并行開發(fā)的擴(kuò)展床估，到交付階段并行交付的擴(kuò)展含滴，再到相應(yīng)的組織結(jié)構(gòu)和組織能力的擴(kuò)展，皆因微服務(wù)而受惠丐巫。