建站
咨詢
售后
建站咨詢
新聞中心
微服務(wù)或許你沒(méi)有真正實(shí)踐過(guò)，但一定聽(tīng)說(shuō)過(guò)，雖然已經(jīng)到了 2022 年，這個(gè)詞依然很熱，可以通過(guò)搜索 google 指數(shù)看得到。
讓客戶滿意是我們工作的目標(biāo)，不斷超越客戶的期望值來(lái)自于我們對(duì)這個(gè)行業(yè)的熱愛(ài)。我們立志把好的技術(shù)通過(guò)有效、簡(jiǎn)單的方式提供給客戶，將通過(guò)不懈努力成為客戶在信息化領(lǐng)域值得信任、有價(jià)值的長(zhǎng)期合作伙伴，公司提供的服務(wù)項(xiàng)目有：域名注冊(cè)、網(wǎng)絡(luò)空間、營(yíng)銷(xiāo)軟件、網(wǎng)站建設(shè)、江津網(wǎng)站維護(hù)、網(wǎng)站推廣。
起源
“微服務(wù)”一詞源于 2011 年 5 月在威尼斯附近的一次軟件架構(gòu)師研討會(huì)上進(jìn)行的架構(gòu)風(fēng)格的討論。2012 年 5 月 討論小組決定將這種架構(gòu)風(fēng)格命名為“微服務(wù)”。Fred George 同年在一次技術(shù)大會(huì)上進(jìn)行自己的微服務(wù)實(shí)踐分享，并說(shuō)微服務(wù)是一種細(xì)粒度的 SOA ，但最終將其發(fā)揚(yáng)光大的是 Martin Fowler 2014 年寫(xiě)的博文《 Microservices 》，原文鏈接如下：
https://martinfowler.com/articles/microservices.html。
自此以后，微服務(wù)就家喻戶曉了，Microservices 的 Google 指數(shù)也是在 2014 年后就一路飆升。
和微服務(wù)相對(duì)應(yīng)的是單體架構(gòu)，先來(lái)看看單體架構(gòu)是怎樣的。
單體架構(gòu)
大多數(shù)人做軟件開(kāi)發(fā)應(yīng)該都是從單體架構(gòu)開(kāi)始的，以 .NET 程序員來(lái)說(shuō)，從最早的 WebForm、到后來(lái)的 MVC、再到現(xiàn)在的前后端分離，后端使用 .NET 的 WebAPI ，都是整個(gè)項(xiàng)目的代碼放到一個(gè)解決方案中，發(fā)布要么直接整個(gè)目錄進(jìn)行替換，或者更新有變更的 dll 文件。
包括到現(xiàn)在，這種單體架構(gòu)的模該還占著很大的比重，凡是存在，必有道理，單體架構(gòu)有著他的可取之處：
- 開(kāi)發(fā)方便，.NET 程序員只需只需使用宇宙最強(qiáng) IDE VS 就可以。
- 調(diào)試方便，在開(kāi)發(fā)階段，所有的項(xiàng)目都在一個(gè)解決方案下，項(xiàng)目之間是可以直接引用，斷點(diǎn)可以到達(dá)你想要的任何地方。
- 運(yùn)行方便，編碼完成，只需一個(gè) F5 搞定。
- 部署方便，無(wú)論是之前部署 IIS ，還是現(xiàn)在的容器部署，都只涉及到一個(gè)發(fā)布目錄。
不過(guò)，隨著產(chǎn)品的功能越來(lái)越復(fù)雜，代碼也會(huì)變得越來(lái)越復(fù)雜，團(tuán)隊(duì)的人數(shù)也會(huì)越來(lái)越多，這時(shí)單體架構(gòu)就會(huì)帶來(lái)一些問(wèn)題：
- 因?yàn)榇a庫(kù)非常的臃腫，從編譯、構(gòu)建、運(yùn)行到測(cè)試這個(gè)時(shí)間會(huì)越來(lái)越長(zhǎng)。
- 技術(shù)棧幾乎是受限的，比如一個(gè) .NET 的工程，基本就是 C# 來(lái)開(kāi)發(fā)了，不太可能混雜其他的語(yǔ)言。
- 不方便橫向擴(kuò)展，只能整套程序進(jìn)行擴(kuò)，滿足所有模塊的需求，對(duì)資源的利用率非常差。
- 不夠敏捷，團(tuán)隊(duì)成員越來(lái)越多多時(shí)，都在同一個(gè)代碼上進(jìn)行修改、提交、合并，容易引發(fā)沖突和其他問(wèn)題。
- 一個(gè)很小的改動(dòng)點(diǎn)，容易引發(fā)全身問(wèn)題，導(dǎo)致系統(tǒng)崩潰，因?yàn)橛绊扅c(diǎn)多，測(cè)試成本也會(huì)很高。
- 缺乏可靠性，我們就碰到過(guò)因?yàn)橐粋€(gè)序列化的問(wèn)題導(dǎo)致 CPU 占用很高，結(jié)果整個(gè)系統(tǒng)癱瘓了。
微服務(wù)架構(gòu)
上面提到的單體架構(gòu)存在的問(wèn)題，采用微服務(wù)架構(gòu)可以很好地解決。微服務(wù)的核心是為了解耦，構(gòu)建成一個(gè)松耦合的分布式系統(tǒng)。
一個(gè)龐大的單體系統(tǒng)拆分成若干個(gè)小的服務(wù)，每個(gè)服務(wù)可以由一個(gè)小的團(tuán)隊(duì)來(lái)維護(hù)，團(tuán)隊(duì)會(huì)更加敏捷，構(gòu)建發(fā)布的時(shí)間更短，代碼也容易維護(hù)。
不同的微服務(wù)團(tuán)隊(duì)可以采用不同的技術(shù)棧，比如工作流引擎使用 .NET ，規(guī)則引擎可以使用 Java ，一些全新的模塊更容易采用新的技術(shù)，人員流動(dòng)和補(bǔ)充上也更加靈活。
每個(gè)服務(wù)通常采用獨(dú)立的數(shù)據(jù)庫(kù)，代碼或者數(shù)據(jù)庫(kù)層面的問(wèn)題不會(huì)導(dǎo)致整個(gè)系統(tǒng)的崩潰。
擴(kuò)展方便，這個(gè)很重要，如果監(jiān)控發(fā)現(xiàn)流程引擎的壓力很大，可以只針對(duì)這個(gè)服務(wù)進(jìn)行橫向擴(kuò)展，服務(wù)器資源可以得到更好的利用。
上面說(shuō)的都是好處，但沒(méi)有任何一種技術(shù)是銀彈，微服務(wù)解決問(wèn)題的同時(shí)，也會(huì)帶來(lái)更多的問(wèn)題。
1、開(kāi)發(fā)調(diào)試變得困難了，需要通過(guò)日志的方式或者借助一些遠(yuǎn)程調(diào)試工具。
2、單體架構(gòu)中，模塊之間的調(diào)用都是進(jìn)程內(nèi)，添加類庫(kù)的引用后，就是本地方法的調(diào)用，微服務(wù)各自獨(dú)立部署，就會(huì)涉及到進(jìn)程間的通信。
3、線上問(wèn)題往往需要多個(gè)服務(wù)團(tuán)隊(duì)一起來(lái)協(xié)作解決，會(huì)存在互相甩鍋的問(wèn)題。
4、在分布式系統(tǒng)中，事務(wù)、數(shù)據(jù)一致性、聯(lián)合查詢等相比較單體更加復(fù)雜。
5、持續(xù)集成、部署、運(yùn)維的復(fù)雜度也顯著提升。
6、隨著服務(wù)越來(lái)越多，客戶端怎樣去找這些服務(wù)呢?
7、進(jìn)程內(nèi)的訪問(wèn)不存在網(wǎng)絡(luò)的問(wèn)題，拆分后的服務(wù)可能在同個(gè)機(jī)器的不同進(jìn)程，更多的時(shí)候是不同機(jī)器的不同進(jìn)程，網(wǎng)絡(luò)問(wèn)題導(dǎo)致服務(wù)不穩(wěn)定怎么辦?
為了解決這些問(wèn)題，各種中間件和框架就應(yīng)運(yùn)而生，又會(huì)帶來(lái)更多的學(xué)習(xí)成本。
在 .NET 技術(shù)棧中，會(huì)用到下面這些中間件：
- 服務(wù)注冊(cè)與發(fā)現(xiàn)：Consul。
- 網(wǎng)關(guān)：Ocelot。
- 熔斷降級(jí)：Polly。
- 服務(wù)鏈路追蹤：SkyWalking 或 Twitter 的 Zipkin。
- 配置中心：Apllo。
- 鑒權(quán)中心：IdentityServer4。
在 Java 中也有 Spring Cloud 和 Spring Cloud Alibaba 這種全家桶套件可以使用。
要不要轉(zhuǎn)微服務(wù)呢?
從單體到微服務(wù)是一個(gè)權(quán)衡和取舍的問(wèn)題，切記不要跟風(fēng)。以我的經(jīng)驗(yàn)來(lái)看，可以分為兩類：
- 做企業(yè)級(jí)系統(tǒng)。
- 做互聯(lián)網(wǎng)系統(tǒng)。
做企業(yè)級(jí)應(yīng)用大多都是項(xiàng)目交付型的，客戶關(guān)系維系的好，后面可以做二期、三期，當(dāng)然也有一錘子買(mǎi)賣(mài)的。這其中一個(gè)關(guān)鍵點(diǎn)是要快，單從快速來(lái)看，采用單體架構(gòu)，開(kāi)發(fā)、調(diào)試、部署都是最快的。
從客戶角度來(lái)說(shuō)，只要能滿足業(yè)務(wù)，是單體還是微服務(wù)其實(shí)不太關(guān)心。
做互聯(lián)網(wǎng)應(yīng)用，也就是我們常說(shuō)的 SaaS，也分為兩種情況：
1、將現(xiàn)有的私有化部署的系統(tǒng)(單體架構(gòu))改造成支持 SaaS 的模式。
這種我也不建議一上來(lái)就大刀闊斧地進(jìn)行微服務(wù)改造，可以在代碼的結(jié)構(gòu)上做一些調(diào)整，比如按照領(lǐng)域去拆分目錄，不同領(lǐng)域之間的調(diào)用可以再進(jìn)行一層抽象，目的是為了未來(lái)向微服務(wù)架構(gòu)轉(zhuǎn)化。
當(dāng)團(tuán)隊(duì)的技術(shù)棧變得豐富了，比如原先只有 .NET ,現(xiàn)在有些模塊采用的是 Java ,這時(shí)已然是朝著微服務(wù)架構(gòu)發(fā)展了，只是粒度比較大而已，相應(yīng)的一些中間件也需要引入，比如服務(wù)網(wǎng)關(guān)、服務(wù)發(fā)現(xiàn)、服務(wù)間通信等。
2、從零開(kāi)始做一個(gè) SaaS 系統(tǒng)。
互聯(lián)網(wǎng)系統(tǒng)和企業(yè)級(jí)系統(tǒng)有很大的差別，如果說(shuō)企業(yè)級(jí)系統(tǒng)更多關(guān)注功能性需求，那么互聯(lián)網(wǎng)系統(tǒng)除了功能性需求，還需要關(guān)注非功能性需求，比如：橫向擴(kuò)展、限流降級(jí)、日志追蹤、預(yù)警、灰度發(fā)布等。
即便因?yàn)闀r(shí)間關(guān)系，一開(kāi)始是單體架構(gòu)，我覺(jué)得也應(yīng)該是微服務(wù)架構(gòu)的單體，隨著持續(xù)迭代和發(fā)展，根據(jù)實(shí)際情況逐步進(jìn)行拆分。
如果時(shí)間上比較充裕，可以一開(kāi)始就按照微服務(wù)架構(gòu)進(jìn)行分離，但粒度不要太小。
總結(jié)
- 解決常說(shuō)的的三高問(wèn)題(高并發(fā)、高性能、高可用)，一個(gè)核心的思路就是拆，分而治之，所以說(shuō)微服務(wù)肯定是能解決掉我們的很多問(wèn)題，也是發(fā)展方向。
- 實(shí)踐微服務(wù)需要根據(jù)當(dāng)前的實(shí)際情況，如果單體運(yùn)行的很好，也沒(méi)什么問(wèn)題，也不要為了炫技進(jìn)行微服務(wù)改造。
- 如果決定要實(shí)踐微服務(wù)，先做好單體架構(gòu)的設(shè)計(jì)，讓代碼遵循面向?qū)ο蟮脑O(shè)計(jì)原則，否則即便形式上變成了微服務(wù)，也不能?chē)L到微服務(wù)的甜頭。
分享文章：微服務(wù)：我們需要從單體轉(zhuǎn)到微服務(wù)嗎？
當(dāng)前地址：http://www.dlmjj.cn/article/dhocccg.html
