文/蘇瑾 田建斌
相比較傳統(tǒng)的架構(gòu),微服務(wù)架構(gòu)能夠更好的幫助企業(yè)將新的功能點(diǎn)快速的迭代插入到現(xiàn)有的生產(chǎn)環(huán)境中去,它減少了開(kāi)發(fā)的復(fù)雜性,部署的復(fù)雜性,同時(shí)架構(gòu)本身也降低了資源的消耗。使得架構(gòu)本身能夠有效的提高整個(gè)系統(tǒng)的開(kāi)發(fā)效率及容錯(cuò)率,而這一點(diǎn)對(duì)于當(dāng)代大型企業(yè)所搭建的功能點(diǎn)眾多,業(yè)務(wù)邏輯十分復(fù)雜的大型應(yīng)用系統(tǒng)來(lái)說(shuō)顯然相當(dāng)重要。此外微服務(wù)架構(gòu)還可以實(shí)現(xiàn)服務(wù)模塊的單獨(dú)發(fā)部署,因此在應(yīng)用系統(tǒng)的構(gòu)建過(guò)程中持續(xù)部署成為了可能。所以一系列的好處使得微服務(wù)架構(gòu)被越來(lái)越多的企業(yè)所重視。而微服務(wù)架構(gòu)也以快捷性,部署簡(jiǎn)易性,自身強(qiáng)大的包容性為企業(yè)應(yīng)用實(shí)施提供者不可估量的幫助。
首先微服務(wù)在物理意義上是一種小顆粒的獨(dú)立模塊。而這種小顆粒的獨(dú)立模塊,在系統(tǒng)邏輯上存在著相互的依賴(lài)關(guān)系,且通常情況下微服務(wù)模塊具備多層次依賴(lài)特性。
同時(shí)隨著近些年各方面技術(shù)的快速發(fā)展,云計(jì)算的成熟以及Web應(yīng)用的需求高漲,使得越來(lái)越多的企業(yè)逐步的將企業(yè)本身應(yīng)用程序從本地遷徙到云計(jì)算平臺(tái),這導(dǎo)致云計(jì)算平臺(tái)漸漸成為了現(xiàn)代互聯(lián)網(wǎng)中的新興技術(shù),而現(xiàn)代云計(jì)算平臺(tái)則集成了包括分布式計(jì)算、網(wǎng)格計(jì)算等多種新式計(jì)算的優(yōu)點(diǎn),使得云服務(wù)平臺(tái)可以整合各種可用的資源,同時(shí)能夠?qū)崟r(shí)的為用戶提供,可靠穩(wěn)定的服務(wù),而云計(jì)算平臺(tái)的興起則為Web應(yīng)用的發(fā)展帶來(lái)了新的活力。這一方面是因?yàn)榇罅康腤eb應(yīng)用,因?yàn)槠淇煽啃约靶市詥?wèn)題,有時(shí)候難以滿足企業(yè)的大型業(yè)務(wù)需求,因此導(dǎo)致了整體Web應(yīng)用的部署效率較低,資源利用率底的情況,反饋到現(xiàn)實(shí)即是企業(yè)需要在硬件的運(yùn)行維護(hù)軟件的更迭替換中投入大量的資源,而微服務(wù)架構(gòu)則在此背景被提出服務(wù)架構(gòu)模型,它通過(guò)細(xì)分服務(wù)類(lèi)別,用獨(dú)立部署,獨(dú)立擴(kuò)展,獨(dú)立開(kāi)發(fā),三種模式提高了Web應(yīng)用的整體容錯(cuò)性,拓展性,使得企業(yè)不需要通過(guò)大量的人力物力來(lái)對(duì)整個(gè)系統(tǒng)進(jìn)行維護(hù)。簡(jiǎn)而言之,微服務(wù)架構(gòu)是把原先一個(gè)混合了多種服務(wù)體系的應(yīng)用模板,通過(guò)相應(yīng)的規(guī)則和結(jié)構(gòu)劃分為獨(dú)立的服務(wù)模塊,將原先混亂的服務(wù)功能全部一一分離同時(shí)進(jìn)行模板化使得每一個(gè)微服務(wù)都成為一個(gè)獨(dú)立運(yùn)行的個(gè)體,從而在最大程度上解決了現(xiàn)代Web應(yīng)用存在的部署混亂,業(yè)務(wù)邏輯復(fù)雜的情況。
對(duì)于現(xiàn)代企業(yè)來(lái)說(shuō),如何搭建區(qū)別于傳統(tǒng)的微服務(wù)架構(gòu),企業(yè)需要根據(jù)自己的業(yè)務(wù)需求。靈活的將整個(gè)系統(tǒng),通過(guò)相應(yīng)的技術(shù),流程拆分為多個(gè)獨(dú)立的服務(wù)模塊同時(shí)合理的劃分,系統(tǒng)功能模塊。使得整個(gè)微服務(wù)架構(gòu)能夠高效持續(xù)穩(wěn)定的運(yùn)行。而簡(jiǎn)單的微服務(wù)架構(gòu),搭建流程如下
在進(jìn)行微服結(jié)構(gòu)搭建的過(guò)程中,企業(yè)要明確微服務(wù)架構(gòu)主要是為了解決復(fù)雜度相對(duì)于傳統(tǒng)單體式系統(tǒng)較為單一的復(fù)雜系統(tǒng)自身消耗大,功能混亂的情況,同時(shí)也需要明確微服務(wù)架構(gòu),本身由多個(gè)簡(jiǎn)單的服務(wù)構(gòu)成,而這些服務(wù)之間存在著相互的邏輯交互,使得整個(gè)系統(tǒng)能夠得到控制,但各個(gè)模塊之間又相互獨(dú)立。因此,微服務(wù)架構(gòu)的自身其實(shí)也會(huì)導(dǎo)致復(fù)雜度的增加。使用微服務(wù)架構(gòu)需要運(yùn)維的系統(tǒng)數(shù)量,不會(huì)得到減少。在一定程度上,反而變得更多,有時(shí)日志文件也較容易出現(xiàn)了散步性,難以維持一致性的情況,因此。搭建微服務(wù)架構(gòu),第一步就是確定需求,企業(yè)需要明確自己搭建微服務(wù)架構(gòu)中所需要的功能有哪些,要將功能劃分為幾個(gè)模塊,同時(shí)是否組建相應(yīng)的管理團(tuán)隊(duì)及模塊進(jìn)行定時(shí)的維護(hù)和更迭,在明確需求過(guò)后,公司需要為整個(gè)運(yùn)營(yíng)制作團(tuán)隊(duì)提供最大化的自主權(quán)。在團(tuán)隊(duì)創(chuàng)建微服務(wù)架構(gòu)的過(guò)程中,為團(tuán)隊(duì)提供一種無(wú)需與其他行業(yè)協(xié)調(diào)即可完成自己本身工作的氛圍。并且在搭建的過(guò)程中,企業(yè)應(yīng)當(dāng)優(yōu)化開(kāi)發(fā)速度,要明確在現(xiàn)代的社會(huì)中硬件成本一直都屬于相對(duì)較低,較為昂貴的是人工成本,因此企業(yè)需要對(duì)員工賦能,能使得員工可以迅速的開(kāi)發(fā)出強(qiáng)大的服務(wù),在整個(gè)開(kāi)發(fā)過(guò)程中要以自動(dòng)化為中心,要明確再好的員工都會(huì)犯錯(cuò),再優(yōu)秀的員工也不可能一直處于完美狀態(tài),因此,在需要維護(hù)的系統(tǒng)變多的情況下就意味著出現(xiàn)錯(cuò)誤的概率偏大,所以要將人力所不能及的地方逐漸以自動(dòng)化代替。其次,在不危及一致性的前提下,企業(yè)可以提供靈活性讓團(tuán)隊(duì)自由的去決定如何進(jìn)行搭建與形式,通過(guò)一系列的技術(shù)手段確保長(zhǎng)遠(yuǎn)范圍內(nèi)模塊秩序的穩(wěn)定。最后在整個(gè)系統(tǒng)搭建過(guò)程及收尾階段運(yùn)營(yíng)階段中發(fā)生故障的可能性有很多,而分布式的系統(tǒng)引入又有可能引發(fā)一些的故障,因此為了形成彈性管理制度,為了將影響降至最低,企業(yè)需要確保開(kāi)發(fā)的系統(tǒng)本身具備相應(yīng)的衡量機(jī)制,并且債務(wù)五維護(hù)上要使用多套?;鶞?zhǔn)代碼,為確保一致性,企業(yè)可以提供必要的指導(dǎo)和工具。
服務(wù)團(tuán)隊(duì)在現(xiàn)代云環(huán)境Web系統(tǒng)的微服務(wù)架構(gòu)搭建中需要能自由構(gòu)建必要的東西,而為了確保一致性,并且管理因?yàn)楣δ茉黾佣桨l(fā)復(fù)雜的運(yùn)維工作,就需要讓通信日志監(jiān)控部署等等工作,實(shí)現(xiàn)標(biāo)準(zhǔn)化流程化,穩(wěn)定化的情況,而平臺(tái)就是一系列需求的最后產(chǎn)物,借助平臺(tái)可以更好的創(chuàng)建為服務(wù)架構(gòu),并且滿足基礎(chǔ)運(yùn)維需求。而在使用平臺(tái)的過(guò)程中,團(tuán)隊(duì)一般需要大量的Web接口進(jìn)行持續(xù)的基層監(jiān)控與日志管理,團(tuán)隊(duì)也需要一個(gè)控制中心去管理所有的模塊,并且列出相應(yīng)的服務(wù)鏈接到各個(gè)工具的簡(jiǎn)單控制中心。在理想的情況下。平臺(tái)提供的工作中心還可以從內(nèi)部工具搜集企業(yè)發(fā)展及運(yùn)營(yíng)所需要的相應(yīng)數(shù)據(jù),并且在確保合法合理的情況下,使用數(shù)據(jù)為企業(yè)提供額外的商業(yè)價(jià)值。
最后,平臺(tái)在內(nèi)部運(yùn)行過(guò)程中,通常一般是同時(shí)運(yùn)行很多的程序,而具體的數(shù)量則對(duì)應(yīng)著公司規(guī)模以及功能需求,可能只有十幾個(gè)亦或者上百個(gè),甚至一些特大型的企業(yè)有可能一個(gè)平臺(tái)同時(shí)運(yùn)行上千上萬(wàn)的程序,而每個(gè)服務(wù)都需要經(jīng)過(guò)獨(dú)立的模塊與團(tuán)隊(duì)進(jìn)行業(yè)務(wù)能力封裝,因此,為了確保服務(wù)能夠被具體的用于某一種圖同時(shí)不對(duì)其他的模塊產(chǎn)生影響,所搭建的服務(wù)就必須要在平臺(tái)內(nèi)盡可能的想將服務(wù)之間的交互降到最低,效率提高到最大。
這里微服務(wù)的開(kāi)發(fā)團(tuán)隊(duì)與運(yùn)營(yíng)團(tuán)隊(duì)就發(fā)現(xiàn)每個(gè)服務(wù)都需要獨(dú)立的開(kāi)發(fā)與部署。只要服務(wù)沒(méi)有對(duì)模塊APΙ做出破壞性,不可修復(fù)性的改動(dòng),就不需要與其他的服務(wù)團(tuán)隊(duì)進(jìn)行聯(lián)動(dòng)與溝通,從某種意義上來(lái)說(shuō),每個(gè)服務(wù)都是一個(gè)獨(dú)立的團(tuán)隊(duì)產(chǎn)品,有著自己的基準(zhǔn)代碼。和運(yùn)營(yíng)生存周期。而模塊與模塊之間有可能存在聯(lián)系,但一定相互獨(dú)立。因此,在微服務(wù)的架構(gòu)中存在的三條規(guī)律,如果發(fā)現(xiàn)部署需要配合其他的服務(wù),一定是在搭建過(guò)程中出現(xiàn)了錯(cuò)誤,如果所有的服務(wù)使用了相同的基準(zhǔn)代碼,搭建的過(guò)程中肯定存在錯(cuò)誤,如果在服務(wù)運(yùn)行前必須要與其他服務(wù)進(jìn)行溝通,要提醒其他服務(wù)團(tuán)隊(duì)注意,服務(wù)邏輯必然存在問(wèn)題。而當(dāng)多個(gè)服務(wù)。同時(shí)直接讀寫(xiě)數(shù)據(jù)庫(kù)的一份數(shù)據(jù)時(shí),對(duì)這份數(shù)據(jù)做出的改動(dòng),這種情況就需要多和服務(wù)的相互協(xié)調(diào),因此,公用的數(shù)據(jù)庫(kù)一定程度上就違反了服務(wù)相互獨(dú)立原則,在非必要的前提下存在一定的不恰當(dāng)。所以私有數(shù)據(jù)庫(kù)就成了服務(wù)搭建過(guò)程中的剛需,同時(shí)私有數(shù)據(jù)庫(kù),也提供了根據(jù)服務(wù)的用途,選擇合適的服務(wù)技術(shù)的優(yōu)勢(shì)。
最后服務(wù)中還存在外部服務(wù),也就是說(shuō)一個(gè)獨(dú)立運(yùn)營(yíng)的服務(wù)團(tuán)隊(duì)可能需要因?yàn)樽陨順I(yè)務(wù)需求或系統(tǒng)需求要與非團(tuán)隊(duì)搭建的系統(tǒng)進(jìn)行通信,比如說(shuō)公用數(shù)據(jù)庫(kù),緩沖支付系統(tǒng),而這些系統(tǒng)。一般是由第三方托管是交付使用或者在特大型企業(yè)內(nèi)部。自行托管相關(guān)服務(wù)。而服務(wù)團(tuán)隊(duì)需要注意的是,無(wú)論采用哪種服務(wù)方式,都必須要考慮到服務(wù)數(shù)量以及服務(wù)力用力和服務(wù)需求,要確保系統(tǒng)的供應(yīng)和管理自動(dòng)化與智能化。
云環(huán)境中Web應(yīng)用的微服務(wù)架構(gòu)的相關(guān)研究,無(wú)疑是繁瑣且復(fù)雜的,而現(xiàn)代企業(yè)愈發(fā)龐大的商務(wù)體系,層出不窮的各項(xiàng)功能需求也導(dǎo)致了基于云環(huán)境中的Web應(yīng)用的微服務(wù)架構(gòu),是企業(yè)進(jìn)行系統(tǒng)搭建時(shí)無(wú)法避免的點(diǎn),而這種情況也在一定程度上推動(dòng)了現(xiàn)代云環(huán)境中Web應(yīng)用的服務(wù)架構(gòu)的研究推進(jìn),使得各種各樣的技術(shù)噴涌式出現(xiàn)。因此有理由相信在需求決定方向的時(shí)代,基于云環(huán)境中Web應(yīng)用微服務(wù)架構(gòu)的搭建會(huì)越發(fā)完善。