簡(jiǎn)介
隨著互聯(lián)網(wǎng)公司在高度競(jìng)爭(zhēng)性的市場(chǎng)中需要快速靈活的復(fù)制其開(kāi)發(fā)環(huán)境,應(yīng)用程序的開(kāi)發(fā)正變得越來(lái)越復(fù)雜。龐大并且整體的應(yīng)用程序在過(guò)去是企業(yè)的競(jìng)爭(zhēng)力,但是在新的情境中卻使得快速部署新的服務(wù)成為了問(wèn)題。而分散的和分布式開(kāi)發(fā)會(huì)帶來(lái)組織架構(gòu)上的問(wèn)題。基于此,用戶的要求比過(guò)去任何時(shí)候更高 – 企業(yè)需要有效的擴(kuò)展并且監(jiān)控已部署的系統(tǒng)以確保高性能和一致的用戶體驗(yàn)。當(dāng)然,這一切都需要在服務(wù)不中斷的情況下完成。
上述的這些趨勢(shì)對(duì)軟件架構(gòu)模式提出了新的要求以使其能處理在當(dāng)前時(shí)代下的需求。整體化的架構(gòu)是一種傳統(tǒng)的方式,但是存在諸多問(wèn)題:不易于擴(kuò)展,大的代碼庫(kù)難于維護(hù),升級(jí)過(guò)程有很大的風(fēng)險(xiǎn),前置的準(zhǔn)備成本等,所有這些迫使企業(yè)尋求新的方法。
在過(guò)去幾年,微服務(wù)的概念進(jìn)入了人們的視野。由于其在提供模塊化、可擴(kuò)展、高可用的應(yīng)用方面的能力以及促進(jìn)組織架構(gòu)融合方面的優(yōu)勢(shì)使得它迅速的被業(yè)界所接受。
整體化架構(gòu)
在微服務(wù)之前,一個(gè)通用的軟件設(shè)計(jì)模式是使用整體化架構(gòu)。在這種模式下,應(yīng)用程序在開(kāi)發(fā)、測(cè)試、打包和部署階段都是作為一個(gè)整體存在。代碼庫(kù)被整體編譯,應(yīng)用程序被作為一個(gè)實(shí)體部署。擴(kuò)展需要將應(yīng)用程序的二進(jìn)制文件和依賴的庫(kù)文件拷貝到不同的服務(wù)器上,這些應(yīng)用程序一般都是單進(jìn)程運(yùn)行。這種整體化架構(gòu)使得持續(xù)交付(一種包含了快速、迭代、升級(jí)安全的軟件開(kāi)發(fā)過(guò)程)變得充滿挑戰(zhàn),因?yàn)槟呐率菓?yīng)用程序棧的最小增量版本也需要重新編譯、重新鏈接和測(cè)試。
什么是微服務(wù)?
微服務(wù)是一種將應(yīng)用分解成小的自治服務(wù)的軟件架構(gòu)。服務(wù)通常僅關(guān)注某個(gè)特定的目標(biāo)并保證服務(wù)之間的自治。每個(gè)服務(wù)被獨(dú)立的開(kāi)發(fā)、測(cè)試和部署,每個(gè)服務(wù)往往使用約定的API并通過(guò)網(wǎng)絡(luò)進(jìn)行通信,雖然在某些情況下網(wǎng)絡(luò)可能是本地的。
微服務(wù)從SOA發(fā)展而來(lái),SOA在本世紀(jì)初曾獲得廣泛的認(rèn)可和流行,SOA是一種反對(duì)大型的整體化架構(gòu)應(yīng)用的方式。SOA和微服務(wù)的主要區(qū)別有:
SOAs是有狀態(tài)的,而微服務(wù)是無(wú)狀態(tài)的。
SOAs傾向于使用企業(yè)級(jí)的服務(wù)總線進(jìn)行通信,而微服務(wù)則使用更簡(jiǎn)單的通信系統(tǒng)。
SOAs或許會(huì)有上百萬(wàn)行代碼,而微服務(wù)往往僅有少于100行代碼。
SOAs強(qiáng)調(diào)重用(例如運(yùn)行時(shí)代碼、數(shù)據(jù)庫(kù)等),而微服務(wù)則關(guān)注在盡量解耦。
SOAs里的一個(gè)系統(tǒng)性變化需要修改軟件的整體結(jié)構(gòu),而在微服務(wù)中的一個(gè)系統(tǒng)性變化將產(chǎn)生一個(gè)新的服務(wù)。
SOAs更經(jīng)常使用傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù),而微服務(wù)則更傾向于現(xiàn)代的、非關(guān)系型數(shù)據(jù)庫(kù)。下面幾節(jié)將介紹在微服務(wù)架構(gòu)中使用非關(guān)系型數(shù)據(jù)庫(kù)的好處。
許多架構(gòu)師發(fā)現(xiàn)SOA存在通信協(xié)議的問(wèn)題和缺乏有效的如何分割服務(wù)的指導(dǎo),這些問(wèn)題構(gòu)成了微服務(wù)的基礎(chǔ),使得微服務(wù)成為了實(shí)現(xiàn)一個(gè)真正的SOA的最佳實(shí)踐方法。
使微服務(wù)成為可能的新技術(shù)
需要部署成百甚至上千的服務(wù)的缺點(diǎn)跟微服務(wù)帶來(lái)的好處(快速開(kāi)發(fā)、可擴(kuò)展)相比還是值得的。
新的技術(shù)的出現(xiàn)例如容器(Docker、LXC)和編排框架(Kubernetes、Mesos)消除了過(guò)去阻礙微服務(wù)架構(gòu)使用的很多問(wèn)題。
容器是輕量級(jí)的運(yùn)行時(shí)環(huán)境,使用最少的性能和容量影響提供了隔離性和可擴(kuò)展性。程序打包也被簡(jiǎn)化成了相同的環(huán)境可以同時(shí)支持開(kāi)發(fā)、支持、測(cè)試和生產(chǎn)環(huán)境的版本,因此使得從開(kāi)發(fā)到測(cè)試到QA到生產(chǎn)的過(guò)程變得更容易。容器在微服務(wù)環(huán)境中可以工作的很好因?yàn)樗梢詫⒎?wù)隔離在單個(gè)的容器中。升級(jí)一個(gè)服務(wù)變成了一個(gè)可以自動(dòng)化和可控的過(guò)程,在APIs保持不變的情況下修改一個(gè)服務(wù)不會(huì)影響到其它的服務(wù)。
當(dāng)組織開(kāi)始在大規(guī)模環(huán)境中運(yùn)行容器時(shí),或許需要考慮使用編排框架來(lái)管理持續(xù)增加的復(fù)雜性。編排框架幫助部署和管理容器:部署主機(jī)、示例容器、錯(cuò)誤處理、彈性伸縮。Kubernetes和Mesos是兩個(gè)常見(jiàn)的編排框架可以使得在微服務(wù)環(huán)境中部署大量容器變得容易。
獲取更多關(guān)于如何利用容器和MongoDB構(gòu)建微服務(wù)架構(gòu)的信息,下載我們的指南:構(gòu)建微服務(wù):解析容器和編排。
微服務(wù)的好處
很多組織可以通過(guò)實(shí)施微服務(wù)來(lái)滿足現(xiàn)代應(yīng)用的需求,這些好處包括:
縮短產(chǎn)品上市時(shí)間:在整體化架構(gòu)的應(yīng)用中,任何微小的修改都需要重新部署整個(gè)應(yīng)用棧,因此帶來(lái)了更高的風(fēng)險(xiǎn)和復(fù)雜度。這造成了更長(zhǎng)的版本周期,因?yàn)樾薷目赡軙?huì)被累積,直到達(dá)到某個(gè)閾值時(shí)才發(fā)布新的版本。使用微服務(wù),對(duì)于某個(gè)服務(wù)的修改可以被迅速的提交、測(cè)試和部署,因?yàn)閷?duì)此服務(wù)的修改跟系統(tǒng)的其它部分是不相關(guān)的。
持續(xù)集成——一種每天數(shù)次集成和測(cè)試開(kāi)發(fā)人員的代碼改動(dòng)的軟件開(kāi)發(fā)實(shí)踐 – 因?yàn)橛懈俚墓δ苄枰y(cè)試而變得更簡(jiǎn)單和快速。結(jié)果是版本的發(fā)布節(jié)奏更快,因?yàn)楦俚拇a需要被編譯和重新測(cè)試。編排框架例如Kubernetes通過(guò)自動(dòng)化上線、容器滾動(dòng)更新和必要時(shí)的回滾進(jìn)一步加快了產(chǎn)品上市的節(jié)奏。
靈活性和可擴(kuò)展性:整體架構(gòu)的應(yīng)用需要系統(tǒng)中的全部組件同時(shí)擴(kuò)展。如果某個(gè)服務(wù)需要更高的性能,唯一的選項(xiàng)就是擴(kuò)展系統(tǒng)中的所有服務(wù)而不是僅僅擴(kuò)展需要擴(kuò)容的單個(gè)服務(wù)。使用微服務(wù),僅需要額外能力的單個(gè)服務(wù)需要擴(kuò)容。擴(kuò)容通過(guò)部署更多的容器來(lái)實(shí)現(xiàn)、可以實(shí)現(xiàn)更有效的容量計(jì)劃,更少的軟件授權(quán)和更低的總體擁有成本;因?yàn)榉?wù)和軟件可以更好的匹配。
彈性: 整體架構(gòu)應(yīng)用的一個(gè)主要問(wèn)題是當(dāng)某個(gè)服務(wù)失效時(shí)可能整個(gè)系統(tǒng)可能都會(huì)受到連累。在微服務(wù)中,各個(gè)服務(wù)之間的隔離性使得單個(gè)服務(wù)的失效不會(huì)擴(kuò)展到系統(tǒng)的其它部分進(jìn)而造成全局性的影響。如果使用容器,編排框架可以提供額外的彈性:當(dāng)某個(gè)容器失效時(shí),一個(gè)新的容器會(huì)被啟動(dòng),進(jìn)而實(shí)現(xiàn)完全的冗余和容量。
組織架構(gòu)匹配:微服務(wù)可以更好的匹配組織架構(gòu),因?yàn)閳F(tuán)隊(duì)的規(guī)??梢愿鶕?jù)需要完成的任務(wù)進(jìn)行更好的定義。團(tuán)隊(duì)可以被分成更小的小組并專注在應(yīng)用的某個(gè)組件上。這對(duì)分布在不同地理位置的團(tuán)隊(duì)來(lái)講是非常有用的。例如,在新加坡的團(tuán)隊(duì)處理三個(gè)服務(wù),在舊金山的團(tuán)隊(duì)處理五個(gè)服務(wù),這兩個(gè)團(tuán)隊(duì)可以獨(dú)立的發(fā)布和部署功能組件。 這可以幫助處理相同組件的不同職能的團(tuán)隊(duì)(Ops、Dev、QA)打破疆界和更好的合作。這也可以保證不同團(tuán)隊(duì)之間的溝通跟不同的服務(wù)之間的API相匹配。本質(zhì)上來(lái)講,服務(wù)之間的API定義了不同開(kāi)發(fā)團(tuán)隊(duì)之間應(yīng)該相互提供的服務(wù)的契約。
降低成本:通過(guò)使用容器,應(yīng)用和環(huán)境(設(shè)計(jì)、測(cè)試、生產(chǎn)、支持)可以共享相同的基礎(chǔ)設(shè)施,結(jié)果是更高的硬件利用率和由于管理簡(jiǎn)化帶來(lái)的成本降低。另外,微服務(wù)也會(huì)降低技術(shù)方面的開(kāi)銷。在整體化架構(gòu)的應(yīng)用中,重構(gòu)一個(gè)大型應(yīng)用的代碼會(huì)帶來(lái)開(kāi)銷(時(shí)間、資源)。通過(guò)將應(yīng)用分解成可以通過(guò)API訪問(wèn)的微服務(wù),代碼重構(gòu)可以逐個(gè)服務(wù)進(jìn)行,結(jié)果是更少的時(shí)間去維護(hù)和更新代碼。
第三十四屆CIO班招生
北達(dá)軟EXIN網(wǎng)絡(luò)空間與IT安全基礎(chǔ)認(rèn)證培訓(xùn)
北達(dá)軟EXIN DevOps Professional認(rèn)證培訓(xùn)
責(zé)編:yangjun
免責(zé)聲明:本網(wǎng)站(http://www.www.gypb.net/)內(nèi)容主要來(lái)自原創(chuàng)、合作媒體供稿和第三方投稿,凡在本網(wǎng)站出現(xiàn)的信息,均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性,但不保證有關(guān)資料的準(zhǔn)確性及可靠性,讀者在使用前請(qǐng)進(jìn)一步核實(shí),并對(duì)任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對(duì)有關(guān)資料所引致的錯(cuò)誤、不確或遺漏,概不負(fù)任何法律責(zé)任。
本網(wǎng)站刊載的所有內(nèi)容(包括但不僅限文字、圖片、LOGO、音頻、視頻、軟件、程序等)版權(quán)歸原作者所有。任何單位或個(gè)人認(rèn)為本網(wǎng)站中的內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí),請(qǐng)及時(shí)通知本站,予以刪除。