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