云環(huán)境中Web應(yīng)用的微服務(wù)架構(gòu)

文/蘇瑾 田建斌

1 引言

相比較傳統(tǒng)的架構(gòu)，微服務(wù)架構(gòu)能夠更好的幫助企業(yè)將新的功能點(diǎn)快速的迭代插入到現(xiàn)有的生產(chǎn)環(huán)境中去，它減少了開發(fā)的復(fù)雜性，部署的復(fù)雜性，同時(shí)架構(gòu)本身也降低了資源的消耗。使得架構(gòu)本身能夠有效的提高整個(gè)系統(tǒng)的開發(fā)效率及容錯(cuò)率，而這一點(diǎn)對于當(dāng)代大型企業(yè)所搭建的功能點(diǎn)眾多，業(yè)務(wù)邏輯十分復(fù)雜的大型應(yīng)用系統(tǒng)來說顯然相當(dāng)重要。此外微服務(wù)架構(gòu)還可以實(shí)現(xiàn)服務(wù)模塊的單獨(dú)發(fā)部署，因此在應(yīng)用系統(tǒng)的構(gòu)建過程中持續(xù)部署成為了可能。所以一系列的好處使得微服務(wù)架構(gòu)被越來越多的企業(yè)所重視。而微服務(wù)架構(gòu)也以快捷性，部署簡易性，自身強(qiáng)大的包容性為企業(yè)應(yīng)用實(shí)施提供者不可估量的幫助。

2 現(xiàn)代微服務(wù)架構(gòu)的定義

首先微服務(wù)在物理意義上是一種小顆粒的獨(dú)立模塊。而這種小顆粒的獨(dú)立模塊，在系統(tǒng)邏輯上存在著相互的依賴關(guān)系，且通常情況下微服務(wù)模塊具備多層次依賴特性。

同時(shí)隨著近些年各方面技術(shù)的快速發(fā)展，云計(jì)算的成熟以及Web應(yīng)用的需求高漲，使得越來越多的企業(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ā)展帶來了新的活力。這一方面是因?yàn)榇罅康腤eb應(yīng)用，因?yàn)槠淇煽啃约靶市詥栴}，有時(shí)候難以滿足企業(yè)的大型業(yè)務(wù)需求，因此導(dǎo)致了整體Web應(yīng)用的部署效率較低，資源利用率底的情況，反饋到現(xiàn)實(shí)即是企業(yè)需要在硬件的運(yùn)行維護(hù)軟件的更迭替換中投入大量的資源，而微服務(wù)架構(gòu)則在此背景被提出服務(wù)架構(gòu)模型，它通過細(xì)分服務(wù)類別，用獨(dú)立部署，獨(dú)立擴(kuò)展，獨(dú)立開發(fā)，三種模式提高了Web應(yīng)用的整體容錯(cuò)性，拓展性，使得企業(yè)不需要通過大量的人力物力來對整個(gè)系統(tǒng)進(jìn)行維護(hù)。簡而言之，微服務(wù)架構(gòu)是把原先一個(gè)混合了多種服務(wù)體系的應(yīng)用模板，通過相應(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ù)雜的情況。

3 如何搭建微服務(wù)架構(gòu)

對于現(xiàn)代企業(yè)來說，如何搭建區(qū)別于傳統(tǒng)的微服務(wù)架構(gòu)，企業(yè)需要根據(jù)自己的業(yè)務(wù)需求。靈活的將整個(gè)系統(tǒng)，通過相應(yīng)的技術(shù)，流程拆分為多個(gè)獨(dú)立的服務(wù)模塊同時(shí)合理的劃分，系統(tǒng)功能模塊。使得整個(gè)微服務(wù)架構(gòu)能夠高效持續(xù)穩(wěn)定的運(yùn)行。而簡單的微服務(wù)架構(gòu)，搭建流程如下

3.1 首先確定關(guān)鍵需求

在進(jìn)行微服結(jié)構(gòu)搭建的過程中，企業(yè)要明確微服務(wù)架構(gòu)主要是為了解決復(fù)雜度相對于傳統(tǒng)單體式系統(tǒng)較為單一的復(fù)雜系統(tǒng)自身消耗大，功能混亂的情況，同時(shí)也需要明確微服務(wù)架構(gòu)，本身由多個(gè)簡單的服務(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ù)和更迭，在明確需求過后，公司需要為整個(gè)運(yùn)營制作團(tuán)隊(duì)提供最大化的自主權(quán)。在團(tuán)隊(duì)創(chuàng)建微服務(wù)架構(gòu)的過程中，為團(tuán)隊(duì)提供一種無需與其他行業(yè)協(xié)調(diào)即可完成自己本身工作的氛圍。并且在搭建的過程中，企業(yè)應(yīng)當(dāng)優(yōu)化開發(fā)速度，要明確在現(xiàn)代的社會(huì)中硬件成本一直都屬于相對較低，較為昂貴的是人工成本，因此企業(yè)需要對員工賦能，能使得員工可以迅速的開發(fā)出強(qiáng)大的服務(wù)，在整個(gè)開發(fā)過程中要以自動(dòng)化為中心，要明確再好的員工都會(huì)犯錯(cuò)，再優(yōu)秀的員工也不可能一直處于完美狀態(tài)，因此，在需要維護(hù)的系統(tǒng)變多的情況下就意味著出現(xiàn)錯(cuò)誤的概率偏大，所以要將人力所不能及的地方逐漸以自動(dòng)化代替。其次，在不危及一致性的前提下，企業(yè)可以提供靈活性讓團(tuán)隊(duì)自由的去決定如何進(jìn)行搭建與形式，通過一系列的技術(shù)手段確保長遠(yuǎn)范圍內(nèi)模塊秩序的穩(wěn)定。最后在整個(gè)系統(tǒng)搭建過程及收尾階段運(yùn)營階段中發(fā)生故障的可能性有很多，而分布式的系統(tǒng)引入又有可能引發(fā)一些的故障，因此為了形成彈性管理制度，為了將影響降至最低，企業(yè)需要確保開發(fā)的系統(tǒng)本身具備相應(yīng)的衡量機(jī)制，并且債務(wù)五維護(hù)上要使用多套。基準(zhǔn)代碼，為確保一致性，企業(yè)可以提供必要的指導(dǎo)和工具。

3.2 搭建平臺(tái)靈活取舍

服務(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)的過程中，團(tuán)隊(duì)一般需要大量的Web接口進(jìn)行持續(xù)的基層監(jiān)控與日志管理，團(tuán)隊(duì)也需要一個(gè)控制中心去管理所有的模塊，并且列出相應(yīng)的服務(wù)鏈接到各個(gè)工具的簡單控制中心。在理想的情況下。平臺(tái)提供的工作中心還可以從內(nèi)部工具搜集企業(yè)發(fā)展及運(yùn)營所需要的相應(yīng)數(shù)據(jù)，并且在確保合法合理的情況下，使用數(shù)據(jù)為企業(yè)提供額外的商業(yè)價(jià)值。

最后，平臺(tái)在內(nèi)部運(yùn)行過程中，通常一般是同時(shí)運(yùn)行很多的程序，而具體的數(shù)量則對應(yīng)著公司規(guī)模以及功能需求，可能只有十幾個(gè)亦或者上百個(gè)，甚至一些特大型的企業(yè)有可能一個(gè)平臺(tái)同時(shí)運(yùn)行上千上萬的程序，而每個(gè)服務(wù)都需要經(jīng)過獨(dú)立的模塊與團(tuán)隊(duì)進(jìn)行業(yè)務(wù)能力封裝，因此，為了確保服務(wù)能夠被具體的用于某一種圖同時(shí)不對其他的模塊產(chǎn)生影響，所搭建的服務(wù)就必須要在平臺(tái)內(nèi)盡可能的想將服務(wù)之間的交互降到最低，效率提高到最大。

3.3 微服務(wù)搭建注意事項(xiàng)

這里微服務(wù)的開發(fā)團(tuán)隊(duì)與運(yùn)營團(tuán)隊(duì)就發(fā)現(xiàn)每個(gè)服務(wù)都需要獨(dú)立的開發(fā)與部署。只要服務(wù)沒有對模塊APΙ做出破壞性，不可修復(fù)性的改動(dòng)，就不需要與其他的服務(wù)團(tuán)隊(duì)進(jìn)行聯(lián)動(dòng)與溝通，從某種意義上來說，每個(gè)服務(wù)都是一個(gè)獨(dú)立的團(tuán)隊(duì)產(chǎn)品，有著自己的基準(zhǔn)代碼。和運(yùn)營生存周期。而模塊與模塊之間有可能存在聯(lián)系，但一定相互獨(dú)立。因此，在微服務(wù)的架構(gòu)中存在的三條規(guī)律，如果發(fā)現(xiàn)部署需要配合其他的服務(wù)，一定是在搭建過程中出現(xiàn)了錯(cuò)誤，如果所有的服務(wù)使用了相同的基準(zhǔn)代碼，搭建的過程中肯定存在錯(cuò)誤，如果在服務(wù)運(yùn)行前必須要與其他服務(wù)進(jìn)行溝通，要提醒其他服務(wù)團(tuán)隊(duì)注意，服務(wù)邏輯必然存在問題。而當(dāng)多個(gè)服務(wù)。同時(shí)直接讀寫數(shù)據(jù)庫的一份數(shù)據(jù)時(shí)，對這份數(shù)據(jù)做出的改動(dòng)，這種情況就需要多和服務(wù)的相互協(xié)調(diào)，因此，公用的數(shù)據(jù)庫一定程度上就違反了服務(wù)相互獨(dú)立原則，在非必要的前提下存在一定的不恰當(dāng)。所以私有數(shù)據(jù)庫就成了服務(wù)搭建過程中的剛需，同時(shí)私有數(shù)據(jù)庫，也提供了根據(jù)服務(wù)的用途，選擇合適的服務(wù)技術(shù)的優(yōu)勢。

最后服務(wù)中還存在外部服務(wù)，也就是說一個(gè)獨(dú)立運(yùn)營的服務(wù)團(tuán)隊(duì)可能需要因?yàn)樽陨順I(yè)務(wù)需求或系統(tǒng)需求要與非團(tuán)隊(duì)搭建的系統(tǒng)進(jìn)行通信，比如說公用數(shù)據(jù)庫，緩沖支付系統(tǒng)，而這些系統(tǒng)。一般是由第三方托管是交付使用或者在特大型企業(yè)內(nèi)部。自行托管相關(guān)服務(wù)。而服務(wù)團(tuán)隊(duì)需要注意的是，無論采用哪種服務(wù)方式，都必須要考慮到服務(wù)數(shù)量以及服務(wù)力用力和服務(wù)需求，要確保系統(tǒng)的供應(yīng)和管理自動(dòng)化與智能化。

4 總結(jié)

云環(huán)境中Web應(yīng)用的微服務(wù)架構(gòu)的相關(guān)研究，無疑是繁瑣且復(fù)雜的，而現(xiàn)代企業(yè)愈發(fā)龐大的商務(wù)體系，層出不窮的各項(xiàng)功能需求也導(dǎo)致了基于云環(huán)境中的Web應(yīng)用的微服務(wù)架構(gòu)，是企業(yè)進(jìn)行系統(tǒng)搭建時(shí)無法避免的點(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ā)完善。