簡(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í)通知本站，予以刪除。
搶沙發(fā)
