公司转型微服务，真的有必要吗？
戳藍(lán)字“CSDN云計(jì)算”關(guān)注我們哦！
作者：謙鎰
轉(zhuǎn)自：架構(gòu)師技術(shù)聯(lián)盟
?
現(xiàn)在，在互聯(lián)網(wǎng)圈子里，不知道何時(shí)微服務(wù)這個(gè)概念已經(jīng)深入到了我們?nèi)?nèi)的各個(gè)角落，似乎如果不趕上這個(gè)潮流，公司的產(chǎn)品就將被淘汰了。
這個(gè)專場(chǎng)開(kāi)場(chǎng)時(shí)，老師給我們說(shuō)了個(gè)他的一段經(jīng)歷。
一天他鄰居問(wèn)他：“你的微服務(wù)課程我可以去聽(tīng)么？”
老師很是驚訝，說(shuō)：“你做微商的怎么這么好學(xué)呀，你知道啥是微服務(wù)么？”
鄰居說(shuō)：“微服務(wù)不是為微商服務(wù)的么？”
當(dāng)然這略帶有點(diǎn)喜劇性了，不過(guò)對(duì)于微服務(wù)，真的是和我們理解的那樣么？我在聽(tīng)這場(chǎng)分享之前我一直認(rèn)為，微服務(wù)不就是把業(yè)務(wù)按照功能模塊切割，讓他獨(dú)立出來(lái)么？
聽(tīng)完這場(chǎng)分享，對(duì)微服務(wù)的定義，有了全新的認(rèn)識(shí)。
1、微服務(wù)不是簡(jiǎn)單的模塊切割
目前業(yè)內(nèi)對(duì)微服務(wù)存在的誤解有很多，這里ThoughtWorks的架構(gòu)師和堅(jiān)老師給我們列出來(lái)幾點(diǎn)：
構(gòu)建HTTP服務(wù)，實(shí)用Docker容器運(yùn)行它，并且用Kubernets做集群管理，就是微服務(wù)
使用API Gateway和服務(wù)發(fā)現(xiàn)以及服務(wù)registry，這就是微服務(wù)
使用Spring Boot框架構(gòu)建http服務(wù)，并使用Netflix OSS，這就是微服務(wù)
使用Azure Service Fabric 構(gòu)建并且運(yùn)行應(yīng)用程序，這就是微服務(wù)
構(gòu)建輕量級(jí)的RESTful API，這就是微服務(wù)
有很多框架聲稱是微服務(wù)框架。使用這些框架的任意一種來(lái)構(gòu)建應(yīng)用程序，這就是微服務(wù)
看完這些，我就有點(diǎn)蒙圈了，那到底怎樣的才算微服務(wù)呢？下面是老師對(duì)微服務(wù)的一個(gè)概括：
微服務(wù)架構(gòu)是一種架構(gòu)模式，它提倡將單一應(yīng)用程序劃分成一組小的服務(wù)，每個(gè)服務(wù)運(yùn)行在其獨(dú)立的進(jìn)程中，服務(wù)間采用輕量級(jí)的通信機(jī)制互相溝通(通常是基于HTTP協(xié)議的RESTful API)。每個(gè)服務(wù)都圍繞著具體業(yè)務(wù)進(jìn)行構(gòu)建，并且能夠被獨(dú)立的部署到生產(chǎn)環(huán)境、類生產(chǎn)環(huán)境等。
同時(shí)和堅(jiān)老師給我們分享了微服務(wù)具有以下幾點(diǎn)特點(diǎn)：
通過(guò)服務(wù)進(jìn)行組件化
圍繞業(yè)務(wù)能力組織
做產(chǎn)品而不是做項(xiàng)目
只能端點(diǎn)與傻瓜管道
去中心化地治理技術(shù)
去中心化地管理數(shù)據(jù)
基礎(chǔ)設(shè)施自動(dòng)化
容錯(cuò)設(shè)計(jì)
演進(jìn)式設(shè)計(jì)
我這里的理解是微服務(wù)其實(shí)是圍繞業(yè)務(wù)能力組織進(jìn)行劃分的一整套服務(wù)集群，但是該怎么劃分呢？他的粒度是什么呢？
2、別一不小心把微服務(wù)切成了小的單體
假設(shè)有一天你的系統(tǒng)已經(jīng)進(jìn)行了“微服務(wù)”改造，由于你的業(yè)務(wù)發(fā)展，新的需求如潮水般涌來(lái)，漸漸的發(fā)現(xiàn)某些“微服務(wù)”開(kāi)始慢慢的膨脹起來(lái)。
發(fā)現(xiàn)膨脹的“微服務(wù)”有一部分業(yè)務(wù)又需要拆分了，而且這個(gè)服務(wù)內(nèi)部還高度耦合，這不就又變成了，拆分之前的服務(wù)了么？
你拆分成的不是微服務(wù)，而是一個(gè)小的單體。
關(guān)于怎么拆分微服務(wù)，和堅(jiān)老師給我推薦了一個(gè)叫DDD服務(wù)設(shè)計(jì)的思想：
要求我們從業(yè)務(wù)視角去分離復(fù)雜度，最終目標(biāo)都是為最求高響應(yīng)力。
讓業(yè)務(wù)架構(gòu)和系統(tǒng)架構(gòu)形成綁定關(guān)系，從而當(dāng)我們?nèi)ロ憫?yīng)業(yè)務(wù)變化調(diào)整業(yè)務(wù)架構(gòu)時(shí)，系統(tǒng)架構(gòu)的改變是隨之而發(fā)的。
雖然短短的兩句話，但是要理解做好，真不是那么容易，還待深入學(xué)習(xí)。
目前微服務(wù)只存在一個(gè)概念性的階段，要想將我們現(xiàn)有的服務(wù)切分成微服務(wù)，按照什么標(biāo)準(zhǔn)進(jìn)行切分，不同的行業(yè)，不同的業(yè)務(wù)場(chǎng)景，將是不同的，這是一個(gè)難題？
當(dāng)我們辛辛苦苦的把業(yè)務(wù)切成了一個(gè)一個(gè)小的服務(wù)在跑時(shí)，如果哪天業(yè)務(wù)發(fā)展，發(fā)現(xiàn)這兩個(gè)服務(wù)還是和在一起跑比較好，這時(shí)，你將面臨的不是單單的把兩個(gè)代碼合在一起這么簡(jiǎn)單。
代碼上的沖突，修改上下游的依賴，部署架構(gòu)都將是一個(gè)挑戰(zhàn)。微服務(wù)的合并，比拆分更難。
3、一個(gè)完整的微服務(wù)離不開(kāi)完善的自動(dòng)化運(yùn)維
當(dāng)我們的項(xiàng)目被拆分成了微服務(wù)在線上跑了，我們的開(kāi)發(fā)看到的將不再是一整個(gè)業(yè)務(wù)的代碼，而是一個(gè)一個(gè)小的模塊服務(wù)。
我們的開(kāi)發(fā)將面臨：我們得把整體的所有服務(wù)了解個(gè)遍，或者相關(guān)的服務(wù)模塊了解完。
如果不能了解完，將會(huì)出現(xiàn)：在版本迭代時(shí)，我們修改的代碼，能保證這個(gè)服務(wù)上沒(méi)問(wèn)題，不能保證上線后對(duì)其他的業(yè)務(wù)不會(huì)有影響。
對(duì)于這個(gè)問(wèn)題，微軟的MVP陳鋒逸老師提出了一個(gè)建議，借助一些代碼即架構(gòu)的工具來(lái)彌補(bǔ)這塊。
微服務(wù)落地，我們還將面臨，我們的服務(wù)散落在各個(gè)地方，運(yùn)維的同事將怎么進(jìn)行監(jiān)控，怎么知道此時(shí)此刻哪個(gè)服務(wù)掛了，哪個(gè)服務(wù)超載了，超載時(shí)我們?cè)趺催M(jìn)行擴(kuò)容，這都是我們要解決的問(wèn)題。
還有，如果我們辛辛苦苦做成了微服務(wù)，在版本發(fā)布時(shí)，怎么保證線上所有容器的版本一直性，也是要解決的問(wèn)題。
這一系列的問(wèn)題就涉及到可持續(xù)性交付這塊了，從開(kāi)發(fā)提交代碼，到測(cè)試，到構(gòu)建，再到測(cè)試用例的覆蓋，最后到生產(chǎn)這一連貫的工作，怎么讓他們自動(dòng)化？如果做不到自動(dòng)化，那投入的成本將可能是傳統(tǒng)的架構(gòu)的N倍。
4、結(jié)束語(yǔ)
我不是一個(gè)架構(gòu)師，只是一個(gè)小小的開(kāi)發(fā)者，所有行文都是按照一個(gè)開(kāi)發(fā)者的角度結(jié)合今天老師講的所寫(xiě)，所以可能有諸多不恰當(dāng)?shù)拇朐~，歡迎指正。
福利
掃描添加小編微信，備注“姓名+公司職位”，加入【云計(jì)算學(xué)習(xí)交流群】，和志同道合的朋友們共同打卡學(xué)習(xí)！
推薦閱讀：
都道業(yè)務(wù)提升坑大事兒多，但英特爾云方案卻說(shuō)“簡(jiǎn)單”
云有約 | 螞蟻金服bPaaS究竟是什么？
再不編程就老了！05 后比特幣專家準(zhǔn)備賺個(gè) 134,000,000 元！
Pig變飛機(jī)？AI為什么這么蠢 | Adversarial Attack
互聯(lián)網(wǎng)沒(méi)有春天
麥克阿瑟獎(jiǎng)得主Dawn Song：區(qū)塊鏈能保密和保護(hù)隱私？圖樣圖森破！
2019年最值得關(guān)注的五大微服務(wù)發(fā)展趨勢(shì)
總結(jié)
以上是生活随笔為你收集整理的公司转型微服务，真的有必要吗？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： Hadoop常见问题 | Hadoop能
- 下一篇： 2019年6月 阿里技术面试题集锦（28