初窺微服務(wù)

在當(dāng)前的這個年月,微服務(wù)已經(jīng)不是一個新的事物.不過我覺得還是應(yīng)該寫幾篇文章,整理一下個人對于微服務(wù)的一些認(rèn)識.

什么微服務(wù)

以下內(nèi)容來自維基百科

Microservices are a software development technique—a variant of the service-oriented architecture (SOA) architectural style that structures an application as a collection of loosely coupled services. In a microservices architecture, services are fine-grained and the protocols are lightweight. The benefit of decomposing an application into different smaller services is that it improves modularity. This makes the application easier to understand, develop, test, and become more resilient to architecture erosion.^[1] It parallelizes development by enabling small autonomous teams to develop, deploy and scale their respective services independently.^[2] It also allows the architecture of an individual service to emerge through continuous refactoring.^[3] Microservices-based architectures enable continuous delivery and deployment.^[4]

以下內(nèi)容來自百度

所謂的微服務(wù)是SOA架構(gòu)下的最終產(chǎn)物，該架構(gòu)的設(shè)計目標(biāo)是為了肢解業(yè)務(wù)，使得服務(wù)能夠獨立運行。微服務(wù)設(shè)計原則：1、各司其職 2、服務(wù)高可用和可擴(kuò)展性

綜合以上,微服務(wù)(MicroServices)就是微小緊湊的服務(wù), 提供統(tǒng)一簡捷的 API 供外部訪問, 實現(xiàn)一組獨立的功能.可能還是覺得有些模糊.不過沒關(guān)系,后續(xù)應(yīng)該會逐步的清晰.

微服務(wù)的歷史

2011年5月在威尼斯附近舉行的一個軟件架構(gòu)師研討會使用了“微服務(wù)”這個術(shù)語來描述參與者所看到的一種共同的架構(gòu)風(fēng)格，他們中的許多人最近都在探索這種風(fēng)格。2012年5月，該組織決定將“微服務(wù)”作為最合適的名稱。2012年3月，James Lewis在Kraków的第33屆Microservices (Java, Unix方式)課程上展示了其中的一些想法作為一個案例研究。Netflix的Adrian Cockcroft將這種方法描述為“細(xì)粒度SOA”，他在web規(guī)模上開創(chuàng)了這種風(fēng)格.至此開啟了微服務(wù)統(tǒng)領(lǐng)的架構(gòu)時代.

微服務(wù)發(fā)展背景

看了上面的那些內(nèi)容,那么勢必有個疑問,為什么是微服務(wù),而不是其他來承接了后續(xù)的架構(gòu)設(shè)計?
為了明白這個問題,我們簡單的了解一下微服務(wù)架構(gòu)出現(xiàn)之前的架構(gòu)設(shè)計形式.

在 2000 年初，面向服務(wù)架構(gòu)（Service Oriented Architecture，SOA）是一種非常流行的軟件架構(gòu)設(shè)計范式。簡而言之，SOA 是一種軟件架構(gòu)模式，用于構(gòu)建大型的企業(yè)應(yīng)用程序，這些應(yīng)用程序通常要求集成多種服務(wù)，而每種服務(wù)使用不同的平臺和編程語言來構(gòu)建，并通過通用的通信機(jī)制進(jìn)行交互。

以下是面向服務(wù)架構(gòu)（SOA）的簡單圖示：

SOA架構(gòu)圖

關(guān)鍵點

1. SOA 是大型軟件產(chǎn)品（如企業(yè)應(yīng)用程序）的首選。
   
2. SOA 側(cè)重于將多個服務(wù)集成到單個應(yīng)用程序中，而不是強(qiáng)調(diào)模塊化應(yīng)用程序。
   
3. 在 SOA 中，用于服務(wù)間交互的通用通信機(jī)制被稱為企業(yè)服務(wù)總線（Enterprise Service Bus，ESB）。
   
4. 基于 SOA 的應(yīng)用程序本質(zhì)是單體。也就是說，單個應(yīng)用程序?qū)影擞脩艚缑婊虮硎緦?、業(yè)務(wù)邏輯或應(yīng)用程序?qū)樱约皵?shù)據(jù)庫層，這些全部都集成到一個平臺中。
   

隨著業(yè)務(wù)的發(fā)展,我們發(fā)現(xiàn)有一些比較嚴(yán)重的問題

1、代碼重復(fù)率高

1）從技術(shù)架構(gòu)角度看，傳統(tǒng)垂直架構(gòu)的特點是本地API接口調(diào)用，不存在業(yè)務(wù)的拆分和互相調(diào)用，使用到上面功能就本地開發(fā)，不需要過度依賴于其他的功能模塊。

2）從考核角度看，共享很難推行。開發(fā)只需要對自己開發(fā)的模塊交付質(zhì)量負(fù)責(zé)，沒有義務(wù)為他人提供并維護(hù)公共類庫，這個非常耗費成本。

3）時間依賴很難把控。對于公共類庫的使用者而言，依賴別人提供此功能，但是功能提供者可能有更重要的事情在做，交付時間無法滿足使用者。與其坐等別人提供，還不如自己開發(fā)效率更高。

4）跨地域、跨開發(fā)小組協(xié)調(diào)很困難，業(yè)務(wù)團(tuán)隊可能跨地域研發(fā)，內(nèi)部通常也會分成多個開發(fā)小組，各個開發(fā)小組之間的協(xié)調(diào)和溝通成本非常高。

功能的重復(fù)開發(fā)會導(dǎo)致研發(fā)成本的上升，代碼質(zhì)量的下降，架構(gòu)腐蝕，為后續(xù)系統(tǒng)的運維和新功能的開發(fā)帶來了巨大的挑戰(zhàn)。

2、需求變更困難

代碼重復(fù)率變高之后，已有功能變更或者新需求加入都會非常困難，以充值繳費功能為例，不同的充值渠道開發(fā)了相同的限額保護(hù)功能，當(dāng)限額保護(hù)功能發(fā)生變更之后，所有重復(fù)開發(fā)的限額保護(hù)功能都需要重新修改和測試，很容易出現(xiàn)修改不一致或者被遺漏，導(dǎo)致部分渠道充值功能正常，部分存在Bug的問題，如下圖所示：

原始版本

修改不一致導(dǎo)致的移動APP充值失敗示例，如下圖所示

修改不一致版本

圖--充值限額保護(hù)功能需求變更后

3、代碼維護(hù)困難

在傳統(tǒng)的MVC架構(gòu)中，業(yè)務(wù)流程是由一長串本地接口或者方法調(diào)用串聯(lián)起來的。臃腫而冗長，而且往往由一個人負(fù)責(zé)開發(fā)和維護(hù)，隨著業(yè)務(wù)的發(fā)展和需求變化，本地代碼再不斷的迭代和變更，最后形成了一個個垂直的功能孤島，只有原理的開發(fā)者才能理解接口調(diào)用的關(guān)系和功能需求，一旦原有的開發(fā)者離職或者調(diào)到其他項目組，這些功能模塊的運維就變得非常困難，如下圖所示：

image

圖--垂直架構(gòu)導(dǎo)致的功能孤島

4、部署效率低

部署效率低主要體現(xiàn)在以下三個方面：
1） 業(yè)務(wù)沒有拆分，很多功能模塊都能打到同一個war包中，一旦有一個功能發(fā)生變更，就需要重新打包和部署。

2）巨無霸應(yīng)用由于包含功能模塊過多，編譯、打包時間比較長，一旦編譯過程出錯，需要根據(jù)錯誤重新修改代碼再編譯，耗時較長。

3）測試工作量較大，因為存在大量重復(fù)的功能類庫，需要針對所有調(diào)用方法進(jìn)行測試，測試工作量大，另外，由于業(yè)務(wù)混在一起打包，需要針對集成打包進(jìn)行專項測試，客觀上也增加了測試工作量。

基于以上問題,微服務(wù)的出現(xiàn)不可避免,那么微服務(wù)有那些優(yōu)勢呢?

微服務(wù)的優(yōu)勢

微服務(wù)的核心競爭力:更小,更快,更強(qiáng)

更小

更小意味著單個應(yīng)用的體積小,覆蓋的功能也相對比較小。也就是通常說的服務(wù)解耦。有一個一般的原則是，單一服務(wù)提供的功能是可以獨立被替換和升級的。 也就是說如果有 A 和 B 兩個功能，如果 A 功能發(fā)生變化時同時 B 功能也需要變化，那么 A 和 B 這兩個功能應(yīng)該被劃在一個服務(wù)中。 但這些服務(wù)可獨立于其他服務(wù)或整個應(yīng)用程序本身而構(gòu)建、部署、伸縮和維護(hù)。

image

基于服務(wù)注冊中心的訂閱發(fā)布機(jī)制，可以實現(xiàn)服務(wù)消費者和提供者之間的解耦，消費者不需要配置服務(wù)提供者的地址信息，即可以實現(xiàn)位置無關(guān)的透明化路由，它的開發(fā)體驗與本地API接口調(diào)用相似，但是卻實現(xiàn)了遠(yuǎn)程服務(wù)調(diào)用。通過服務(wù)注冊中心，可以管理服務(wù)的訂閱和發(fā)布關(guān)系，查看服務(wù)提供者和服務(wù)消費者的詳細(xì)信息。有了服務(wù)訂閱關(guān)系，業(yè)務(wù)和服務(wù)之間的調(diào)用管理系統(tǒng)變得透明化，不合理的接口依賴、調(diào)用關(guān)系一目了然。

更快

更快主要體現(xiàn)在以下三個方面：
1） 開發(fā)速度快,基于微服務(wù)的架構(gòu),使得單個服務(wù)更集中于單一的功能實現(xiàn),便于開發(fā)人員進(jìn)行功能迭代及新的開發(fā)人員快速熟悉微服務(wù)對應(yīng)的代碼。

2）部署時間快,小微型的應(yīng)用,對其他應(yīng)用沒有直接的依賴關(guān)系,自然啟動速度會比較快。

3）迭代速度快,微服務(wù)的架構(gòu),使得單點可容錯的機(jī)會變大,單點的改動也相對來講比單體的應(yīng)用更快。

更強(qiáng)

不是所有系統(tǒng)都打算持續(xù)存在。它們在需要時創(chuàng)建，在不適合某個用途時就會被刪除。正如在上面提到的。微服務(wù)的架構(gòu)使得服務(wù)與服務(wù)間保持這松耦合,減少了關(guān)聯(lián)故障的影響。

正是基于微服務(wù)的這些特點作為基礎(chǔ),才有了現(xiàn)在比較流行的DevOps。對于DevOps,有機(jī)會的話在后續(xù)會整理一片文章來進(jìn)行說明。

微服務(wù)特點總結(jié)

微服務(wù)有如下的特點：

1）單一職責(zé)原則：每個服務(wù)應(yīng)該負(fù)責(zé)單獨的功能，正是SOLID原則之一。

2）獨立部署、升級、擴(kuò)展和替換：每個服務(wù)都可以單獨部署及重新部署而不影響整個系統(tǒng)。這使得服務(wù)很容易升級，每個服務(wù)都可以沿用著 “Art of Scalability” 一書定義的X軸和Z軸進(jìn)行擴(kuò)展。

3）支持異構(gòu)/多種語言：每個服務(wù)的實現(xiàn)細(xì)節(jié)都與其他服務(wù)無關(guān)，這使得服務(wù)之間能夠解耦，團(tuán)隊可以針對每個服務(wù)選擇最合適的開發(fā)語言、工具和方法。

4）輕量級：微服務(wù)通常有輕量級的分布式服務(wù)框架承載，采用了P2P通信，無中心節(jié)點，性能可以線性增長；第三方軟件依賴減少，減少類沖突和冗余依賴，集成和升級更方便。

微服務(wù)與容器化

微服務(wù)將單體應(yīng)用拆分成很多小的應(yīng)用，因而運維和持續(xù)集成會工作量變大，而容器技術(shù)能很好的解決這個問題。關(guān)于該部分的詳細(xì)內(nèi)容,后續(xù)會增加相關(guān)文檔進(jìn)行說明。

微服務(wù)的劃分

1）一個單獨的微型服務(wù)，盡量保證純粹，良好的封裝性。良好的封裝表示不會對外暴露自身的細(xì)節(jié)。

2）微型服務(wù)的組織盡量保證有一定的層次性，不要胡亂的或者網(wǎng)狀的組織微型服務(wù)，不要出現(xiàn)胡亂依賴，循環(huán)依賴。

3）微型服務(wù)切記不要劃分的太細(xì)，也不要劃分的太粗。具體那個度適中，這個需要根據(jù)具體的case進(jìn)行思考。

4）每個微型服務(wù)都應(yīng)該時刻警醒===>自己依賴的服務(wù)。每個這些外部服務(wù)的健康狀況都會對你的服務(wù)產(chǎn)生直接影響。同時你要經(jīng)常梳理自己的服務(wù)的依賴，如果不是真正的必要，不要引入別的服務(wù)的依賴。

微服務(wù)的選擇

綜合以上的了解,我們發(fā)現(xiàn)微服務(wù)簡直是一個必須的選擇啊。但是是否我們需要立馬擁抱微服務(wù),還是需要慎重。
我們先來看一下傳統(tǒng)的單體應(yīng)用與微服務(wù)的優(yōu)缺點對比圖。

image