探討微服務(wù)在燃?xì)馄髽I(yè)數(shù)字化轉(zhuǎn)型中的實(shí)踐應(yīng)用

陳徐棟

（江陰天力燃?xì)庥邢薰?，江蘇 無錫214400）

隨著大數(shù)據(jù)、人工智能、云計(jì)算等新技術(shù)的高速發(fā)展并且逐步向產(chǎn)業(yè)和行業(yè)下沉，數(shù)字化的浪潮已經(jīng)不可避免地到來，城燃企業(yè)也同樣面臨著向新興數(shù)字化轉(zhuǎn)型的迫切需求。而在數(shù)字化轉(zhuǎn)型中，IT的轉(zhuǎn)型或升級(jí)是數(shù)字化轉(zhuǎn)型之路上最重要的革新力量。

數(shù)字化的本質(zhì)，是通過上述新技術(shù)與企業(yè)的業(yè)務(wù)進(jìn)行深度融合來實(shí)現(xiàn)商業(yè)模式的創(chuàng)新以及企業(yè)效率的提升，核心就是快速響應(yīng)和準(zhǔn)確洞察。但城燃企業(yè)傳統(tǒng)的煙囪式信息化架構(gòu)，往往無法滿足這樣快速接入、融合支撐[1]、彈性擴(kuò)展等的需求。

那么如何打破煙囪式架構(gòu)、釋放數(shù)字資產(chǎn)的價(jià)值呢？運(yùn)用“去中心化”的微服務(wù)架構(gòu)，為應(yīng)對(duì)這樣的挑戰(zhàn)提供了一個(gè)很好的解決方案。

1 微服務(wù)

1.1 微服務(wù)定義及概述

2014年，MartinFowler與JamesLewis共同提出了微服務(wù)（Microservices）的概念，定義了微服務(wù)是由以單一應(yīng)用程序構(gòu)成的小服務(wù)，自己擁有自己的進(jìn)程與輕量化處理，服務(wù)依業(yè)務(wù)功能設(shè)計(jì)，以全自動(dòng)的方式部署，與其他服務(wù)使用HTTPAPI通信。同時(shí)服務(wù)會(huì)使用最小規(guī)模的集中管理（例如Docker容器）能力，服務(wù)可以用不同的編程語言與數(shù)據(jù)庫等組件實(shí)現(xiàn)[2]。

通俗點(diǎn)講，微服務(wù)就是把傳統(tǒng)的單體應(yīng)用根據(jù)實(shí)際的情況進(jìn)行解耦，拆分成一個(gè)個(gè)單獨(dú)的服務(wù)，每個(gè)服務(wù)專注于做特定的事，提供特定的服務(wù)。這樣的服務(wù)都可以單獨(dú)進(jìn)行部署及迭代，并且能夠更加根據(jù)實(shí)際情況擁有自身對(duì)應(yīng)的數(shù)據(jù)庫。比如可以將原來應(yīng)用中的銷售功能解耦拆分出來形成一個(gè)單獨(dú)的微服務(wù)，這樣做的好處在于，如果遇到類似于調(diào)價(jià)前用戶集中搶購的情況，只要對(duì)銷售服務(wù)資源進(jìn)行調(diào)整即可。

1.2 微服務(wù)特點(diǎn)

微服務(wù)架構(gòu)具有低耦合、組件化、獨(dú)立部署、獨(dú)立擴(kuò)展、去中心化等特點(diǎn)，主要體現(xiàn)在以下方面：①服務(wù)粒度小。一個(gè)系統(tǒng)被解構(gòu)為多個(gè)顆粒度較小的服務(wù)，每個(gè)微服務(wù)的可維護(hù)性和開發(fā)效率較高。②獨(dú)立進(jìn)程和部署。每一個(gè)服務(wù)都可以獨(dú)立部署及獨(dú)立運(yùn)行，這種方式能夠?qū)崿F(xiàn)靈活的代碼組織和敏捷開發(fā)，降低了業(yè)務(wù)迭代時(shí)服務(wù)發(fā)布的風(fēng)險(xiǎn)，擴(kuò)展性也很強(qiáng)。③去中心化。每個(gè)微服務(wù)可以根據(jù)自身的特性和整體發(fā)展的需要，自由選擇最適合的技術(shù)棧。

1.3 微服務(wù)優(yōu)缺點(diǎn)

相比傳統(tǒng)架構(gòu)，微服務(wù)具備以下優(yōu)勢(shì)：①由于服務(wù)足夠小，因此易于被理解，也易于開發(fā)、維護(hù)以及迭代更新；②各服務(wù)間獨(dú)立性強(qiáng)，易于部署；③由于每個(gè)服務(wù)較小且獨(dú)立，易于在橫向縱向上擴(kuò)展，也易于按需求對(duì)硬件資源進(jìn)行擴(kuò)容，因此可擴(kuò)展性較強(qiáng)；④各服務(wù)可以用不同的語言開發(fā)，數(shù)據(jù)庫也可不同，兼容性強(qiáng)；⑤可使開發(fā)團(tuán)隊(duì)職責(zé)清晰，與IT組織的匹配性更強(qiáng)。當(dāng)然，微服務(wù)架構(gòu)也存在一些缺點(diǎn)，諸如它有分布式系統(tǒng)固有的復(fù)雜性，對(duì)運(yùn)維的要求也較高。

2 實(shí)踐應(yīng)用-技術(shù)框架

2.1 架構(gòu)設(shè)計(jì)及搭建

首先對(duì)燃?xì)馄髽I(yè)最復(fù)雜最重要的主營(yíng)業(yè)務(wù)系統(tǒng)（物聯(lián)網(wǎng)表營(yíng)銷系統(tǒng)）進(jìn)行了改造，將原先復(fù)雜龐大的單體業(yè)務(wù)系統(tǒng)進(jìn)行解耦并微服務(wù)化，并選擇了spring boot來進(jìn)行開發(fā)，最終完成的智慧燃?xì)庠葡到y(tǒng)架構(gòu)，如圖1所示。

從圖1中可以看出，整個(gè)微服務(wù)架構(gòu)的訪問鏈路為：外部請(qǐng)求（web/app）—負(fù)載均衡—服務(wù)網(wǎng)關(guān)（API GateWay）—內(nèi)部微服務(wù)—數(shù)據(jù)及消息，其中各微服務(wù)與APIGatway之間的調(diào)用，則會(huì)通過統(tǒng)一的服務(wù)注冊(cè)配置中心來完成。

圖1 智慧燃?xì)庠葡到y(tǒng)架構(gòu)

2.2 微服務(wù)的服務(wù)網(wǎng)關(guān)（APIGatway）

燃?xì)夤镜臉I(yè)務(wù)功能繁多，可提供的服務(wù)也非常多，但顯然客戶端是不需要和每一個(gè)服務(wù)逐一打交道的，這就需要一個(gè)統(tǒng)一的對(duì)外入口，在這里搭建了微服務(wù)的服務(wù)網(wǎng)關(guān)（APIGatway）。APIGatway主要包含了對(duì)請(qǐng)求的路由和過濾兩個(gè)功能，它能動(dòng)態(tài)地將外部請(qǐng)求路由到所需要的的內(nèi)部微服務(wù)集群中，是實(shí)現(xiàn)外部訪問統(tǒng)一入口的基礎(chǔ)過濾器。這樣，雖然內(nèi)部微服務(wù)是一個(gè)復(fù)雜的分布式網(wǎng)狀結(jié)構(gòu)，但外部通過網(wǎng)關(guān)來看是一個(gè)整體，屏蔽了內(nèi)部服務(wù)的復(fù)雜性。APIGatway還具有鑒權(quán)、限流、安全等功能。同時(shí)，由于它對(duì)外暴露的唯一接口，所有的外部請(qǐng)求都將通過它來訪問，為了應(yīng)對(duì)高并發(fā)、高可用，需要對(duì)APIGatway進(jìn)行集群形式的部署，并在前端搭建Nginx（應(yīng)用層）/SLB（網(wǎng)絡(luò)層）來進(jìn)行負(fù)載均衡。以上的APIGatway采用了SpringcloudNetflix框架的組件Zuul來實(shí)現(xiàn)網(wǎng)關(guān)服務(wù)。

2.3 微服務(wù)的服務(wù)注冊(cè)與發(fā)現(xiàn)

對(duì)原先的業(yè)務(wù)進(jìn)行了解耦微服務(wù)化，這樣就形成了二十幾個(gè)微服務(wù)組成的微服務(wù)集群，那么這些服務(wù)之間的通信，就需要服務(wù)提供方注冊(cè)報(bào)告服務(wù)地址以及服務(wù)調(diào)用方能發(fā)現(xiàn)服務(wù)目標(biāo)，因此引入了Eureka來進(jìn)行所有微服務(wù)的注冊(cè)發(fā)現(xiàn)管理。首先搭建EurekaServer以提供服務(wù)注冊(cè)服務(wù)，所有微服務(wù)啟動(dòng)后都會(huì)在EurekaServer進(jìn)行注冊(cè)，并通過Eureka Client連接到EurekaServer后定時(shí)發(fā)送心跳。Eureka默認(rèn)心跳周期是30s，表明服務(wù)仍處于存活狀態(tài)，如果連續(xù)3次未收到心跳，才會(huì)判斷服務(wù)死亡然后將之從注冊(cè)中刪除。

2.4 熔斷降級(jí)監(jiān)控

新的微服務(wù)架構(gòu)其實(shí)是一個(gè)分布式系統(tǒng)，同時(shí)微服務(wù)之間存在著復(fù)雜的依賴關(guān)系，依賴的調(diào)用不可避免地會(huì)存在超時(shí)、異常、失敗等問題，很可能某個(gè)服務(wù)的一次延時(shí)就會(huì)在短時(shí)間內(nèi)耗盡系統(tǒng)資源并導(dǎo)致整體服務(wù)崩潰。為解決這樣的雪崩效應(yīng)，搭建了Hystrix來進(jìn)行容錯(cuò)處理，它可以通過熔斷、隔離、回退、降級(jí)、限流等機(jī)制，對(duì)整個(gè)微服務(wù)集群進(jìn)行彈性容錯(cuò)保護(hù)，以保證系統(tǒng)的穩(wěn)定性。

3 實(shí)踐應(yīng)用及效果

在沒有采用微服務(wù)架構(gòu)前，公司的營(yíng)銷系統(tǒng)平臺(tái)采用的是傳統(tǒng)的架構(gòu)，如圖2所示。

圖2 公司的營(yíng)銷系統(tǒng)平臺(tái)架構(gòu)

從圖2中可以看到，原來的所有技術(shù)架構(gòu)以及業(yè)務(wù)應(yīng)用還是沿襲著傳統(tǒng)的煙囪式的、單一的部署方式，存在著諸多弊端：①集中式架構(gòu)無法適應(yīng)技術(shù)的發(fā)展。無論是大數(shù)據(jù)分析的需求，還是物聯(lián)網(wǎng)帶來的海量數(shù)據(jù)，這些新的情況都需要向分布式架構(gòu)部署轉(zhuǎn)變。②單體架構(gòu)的業(yè)務(wù)應(yīng)用無法面對(duì)公司的發(fā)展及市場(chǎng)的競(jìng)爭(zhēng)。原先單體架構(gòu)對(duì)于適應(yīng)業(yè)務(wù)的高并發(fā)需求、橫向擴(kuò)展性等非常有限，業(yè)務(wù)的處理規(guī)模及發(fā)展也存在著瓶頸，受到了極大的限制。③后期迭代及擴(kuò)展效率低下。隨著業(yè)務(wù)的不斷發(fā)展，業(yè)務(wù)平臺(tái)也不斷地進(jìn)行迭代更新，功能越來越多，軟件代碼也越來越復(fù)雜。原先的架構(gòu)導(dǎo)致這些代碼都融合在一個(gè)應(yīng)用程序中，該應(yīng)用中的各項(xiàng)功能服務(wù)之間的邏輯關(guān)系也都是在一起的，這就導(dǎo)致如果面臨功能擴(kuò)展或者邏輯調(diào)整，整個(gè)迭代的復(fù)雜程度會(huì)越來越大，時(shí)間周期也會(huì)越來越長(zhǎng)，效率會(huì)急劇降低，代碼的可維護(hù)性下降，并且建設(shè)和維護(hù)成本會(huì)顯著上升。同時(shí)在原先的架構(gòu)中，一個(gè)應(yīng)用程序中的各項(xiàng)功能服務(wù)一般都是訪問同一個(gè)數(shù)據(jù)庫，那么如果遇上服務(wù)或者數(shù)據(jù)庫發(fā)生問題，則極易造成全局性的問題?，F(xiàn)在按照上文所述的微服務(wù)架構(gòu)，對(duì)整個(gè)“物聯(lián)網(wǎng)表營(yíng)銷系統(tǒng)”平臺(tái)進(jìn)行了解耦及重構(gòu)，重構(gòu)后的業(yè)務(wù)結(jié)構(gòu)如圖3所示。

圖3 重構(gòu)后的業(yè)務(wù)結(jié)構(gòu)圖

從圖3可以看出，前端請(qǐng)求和后端的業(yè)務(wù)服務(wù)中間通過網(wǎng)關(guān)來轉(zhuǎn)接，后面的業(yè)務(wù)服務(wù)由原來的一個(gè)笨重的整體轉(zhuǎn)變?yōu)楦魉酒渎毜臓顟B(tài)，每個(gè)業(yè)務(wù)服務(wù)只專注于自身服務(wù)范圍內(nèi)的職責(zé)。實(shí)踐中根據(jù)公司具體的業(yè)務(wù)現(xiàn)狀以及整體的信息化建設(shè)現(xiàn)狀，將原先的業(yè)務(wù)平臺(tái)進(jìn)行了合理的解耦，比如通訊采集微服務(wù)僅負(fù)責(zé)與各種物聯(lián)網(wǎng)設(shè)備進(jìn)行通訊并采集其數(shù)據(jù)；營(yíng)收結(jié)算微服務(wù)負(fù)責(zé)按照公司的結(jié)算規(guī)則定期對(duì)用戶的繳費(fèi)用氣情況進(jìn)行結(jié)算；設(shè)備微服務(wù)負(fù)責(zé)所有的設(shè)備全生命周期管理，包括出入庫、維修等；派單微服務(wù)則專門負(fù)責(zé)整個(gè)工單系統(tǒng)的派單、接單、回單等。各微服務(wù)系統(tǒng)之間的邏輯關(guān)系非常清晰，管理方便。并且能夠根據(jù)各種服務(wù)的特性，部署不同的數(shù)據(jù)庫。比如對(duì)于這里面海量數(shù)據(jù)處理以及后續(xù)預(yù)期擴(kuò)展性要求較高的物聯(lián)網(wǎng)表通訊采集服務(wù)選用了MongoDB，對(duì)于適用關(guān)系型數(shù)據(jù)庫及穩(wěn)定性要求較高的其他業(yè)務(wù)服務(wù)選用了Mysql。同時(shí)這樣的架構(gòu)也使故障可隔離，比如假設(shè)通訊采集服務(wù)發(fā)生故障，并不影響其他業(yè)務(wù)的使用，類似開戶報(bào)裝、充值繳費(fèi)等業(yè)務(wù)仍舊可以正常運(yùn)行，而不像以前，一旦發(fā)生故障，則所有的業(yè)務(wù)都將停止，造成巨大的惡劣影響。

改造上線后，最直接的效果就是原先的開發(fā)上線周期明顯變得更加敏捷。通過統(tǒng)計(jì)了3個(gè)月的開發(fā)需求迭代記錄發(fā)現(xiàn)，顯示由原來的平均32人天/項(xiàng)大幅提升至平均15人天/項(xiàng)，同時(shí)，由于微服務(wù)架構(gòu)將相關(guān)聯(lián)的業(yè)務(wù)邏輯及數(shù)據(jù)放在一起形成了獨(dú)立的邊界，某些服務(wù)的更新不影響其他服務(wù)，大大提高了快速交付能力。本案例中，改造后的迭代上線時(shí)間也大幅縮短，由原先4～6h大幅縮短至1h以內(nèi)，這些都意味著今后這個(gè)架構(gòu)平臺(tái)對(duì)于企業(yè)數(shù)字化轉(zhuǎn)型需求的支持能力是顯著提升的。

微服務(wù)架構(gòu)的價(jià)值還不僅僅體現(xiàn)在當(dāng)下，其通過對(duì)業(yè)務(wù)服務(wù)的解耦拆分，將不同的業(yè)務(wù)應(yīng)用及數(shù)據(jù)分布式部署在云平臺(tái)上，能夠真正發(fā)揮云計(jì)算的算力，使城燃企業(yè)的信息化系統(tǒng)更適合云上生態(tài)。同時(shí)微服務(wù)架構(gòu)的搭建，還可以使燃?xì)馄髽I(yè)未來能夠更加方便、高效、精準(zhǔn)地搭建自己的數(shù)據(jù)中臺(tái)及業(yè)務(wù)中臺(tái)，從而為大數(shù)據(jù)、AI等數(shù)字化轉(zhuǎn)型新技術(shù)提供強(qiáng)有力的支撐，比如通過用戶畫像分析、消費(fèi)行為分析等實(shí)現(xiàn)精準(zhǔn)營(yíng)銷，來賦能城燃企業(yè)數(shù)字化轉(zhuǎn)型。

4 結(jié)束語

本文通過實(shí)踐案例闡述了微服務(wù)架構(gòu)的搭建以及在城燃企業(yè)中的具體應(yīng)用?？梢钥吹?，微服務(wù)這種去中心化的架構(gòu)理念不僅能有效解決原先煙囪式架構(gòu)的各種痛點(diǎn)，也比較契合云計(jì)算、大數(shù)據(jù)分析以及人工智能等新技術(shù)的發(fā)展，更能夠給未來燃?xì)馄髽I(yè)的業(yè)務(wù)融合、大數(shù)據(jù)分析、數(shù)據(jù)資產(chǎn)化等提供很好的基礎(chǔ)支撐，并為正探索數(shù)字化轉(zhuǎn)型的燃?xì)馄髽I(yè)提供了一種比較適宜的方法。