基于SpringBoot微服務(wù)架構(gòu)的城市一卡通手機(jī)充值支撐系統(tǒng)研究

作者/ 溫曉麗 蘇浩偉 陳歡 鄒大畢 廣州羊城通有限公司(廣東 廣州 510080)

摘要：基于微服務(wù)架構(gòu)而構(gòu)建的應(yīng)用系統(tǒng)是將復(fù)雜的大系統(tǒng)分解成了一系列小的單獨(dú)的子服務(wù)系統(tǒng)，這些子服務(wù)系統(tǒng)可以單獨(dú)部署發(fā)布，也可以組合成一個(gè)應(yīng)用發(fā)布。伴隨著移動(dòng)互聯(lián)網(wǎng)應(yīng)用的快速發(fā)展，相應(yīng)的服務(wù)系統(tǒng)更新迭代頻繁，采用微服務(wù)架構(gòu)之后的系統(tǒng)可以很好地適應(yīng)移動(dòng)互聯(lián)網(wǎng)這種需求不斷迭代更新的應(yīng)用場(chǎng)景。城市一卡通手機(jī)充值系統(tǒng)是城市一卡通公司在移動(dòng)互聯(lián)網(wǎng)領(lǐng)域的應(yīng)用服務(wù)系統(tǒng)，同樣地面臨著業(yè)務(wù)不斷快速迭代更新的需求，基于此，進(jìn)行城市一卡通手機(jī)充值支撐系統(tǒng)的構(gòu)建過程中采用了基于SpringBoot微服務(wù)架構(gòu)的研究是必要和有參考意義的。

引言

　　隨著時(shí)代的發(fā)展，在信息系統(tǒng)建設(shè)方面，傳統(tǒng)IT架構(gòu)面臨著以下一些問題：

　　1)使用傳統(tǒng)的整體式架構(gòu)(Monolithic Architecture)應(yīng)用開發(fā)系統(tǒng)，如CRM、ERP等大型應(yīng)用，隨著新需求的不斷增加，企業(yè)更新和修復(fù)大型整體式應(yīng)用變得越來越困難。在系統(tǒng)更新時(shí)，往往牽一發(fā)而動(dòng)全身，稍有不慎就可能帶來大的損失。

　　2)隨著移動(dòng)互聯(lián)網(wǎng)的發(fā)展，企業(yè)被迫將其應(yīng)用遷移至現(xiàn)代化UI界面架構(gòu)以便能兼容移動(dòng)設(shè)備，這要求企業(yè)能實(shí)現(xiàn)應(yīng)用功能的快速上線，而傳統(tǒng)IT架構(gòu)在系統(tǒng)快速迭代更新方面難度較大。

　　3)隨著應(yīng)用云化的日益普及，生于云端的應(yīng)用具有與傳統(tǒng)IT不同的技術(shù)基因和開發(fā)運(yùn)維模式，此時(shí)再生搬硬套傳統(tǒng)IT架構(gòu)往往會(huì)產(chǎn)生適得其反的效果。

　　4)移動(dòng)互聯(lián)網(wǎng)相關(guān)技術(shù)快速發(fā)展，云計(jì)算及互聯(lián)網(wǎng)公司大量開源輕量級(jí)技術(shù)不停涌現(xiàn)并日漸成熟，主要為如下幾方面：互聯(lián)網(wǎng)/內(nèi)聯(lián)網(wǎng)/網(wǎng)絡(luò)更加成熟，輕量級(jí)運(yùn)行時(shí)技術(shù)的出現(xiàn)(node.js等)，新的方法與工具(Agile、DevOps、TDD、CI及XP)，新的輕量級(jí)協(xié)議(RESTful API接口和輕量級(jí)消息機(jī)制)，簡化的基礎(chǔ)設(shè)施，操作系統(tǒng)虛擬化(hypervisors)、容器化(Docker)、基礎(chǔ)設(shè)施即服務(wù)(IaaS)、工作負(fù)載虛擬化(Kubernetes、Spark)等;服務(wù)平臺(tái)化(PaaS)，云服務(wù)平臺(tái)上具有自動(dòng)縮放、工作負(fù)載管理、SLA 管理、消息機(jī)制、緩存、構(gòu)建管理等各種按需使用的服務(wù)，新的可替代數(shù)據(jù)持久化模型：如NoSQL、MapReduce、BASE、CQRS等，標(biāo)準(zhǔn)化代碼管理等。

　　這一切都催生了新的架構(gòu)設(shè)計(jì)風(fēng)格，即微服務(wù)架構(gòu)的出現(xiàn)。

1 微服務(wù)架構(gòu)概述

　　微服務(wù)是一種架構(gòu)風(fēng)格，一個(gè)大型復(fù)雜軟件應(yīng)用由一個(gè)或多個(gè)微服務(wù)組成。系統(tǒng)中的各個(gè)微服務(wù)可被獨(dú)立部署，各個(gè)微服務(wù)之間是松耦合的。每個(gè)微服務(wù)僅關(guān)注于完成一件任務(wù)并很好地完成該任務(wù)。在所有情況下，每個(gè)任務(wù)代表著一個(gè)小的業(yè)務(wù)能力。

　　微服務(wù)具備彈性和伸縮性。微服務(wù)不只依賴單個(gè)服務(wù)器和部署，它們可以被發(fā)布到多個(gè)機(jī)器上，或者多個(gè)數(shù)據(jù)中心及其它任何可用的區(qū)域。如果一個(gè)服務(wù)失效，可以啟動(dòng)另外一個(gè)。因?yàn)檎麄€(gè)應(yīng)用被分解成了微服務(wù)(小型服務(wù))，可以很容易地對(duì)其中某些熱門的服務(wù)進(jìn)行橫向擴(kuò)展。

　　微服務(wù)一般會(huì)提供基于HTTP/JSON的API端點(diǎn)。這樣可以很容易地與其它服務(wù)(開源或閉源的)集成，只要這些服務(wù)提供了HTTP/JSON接口。服務(wù)可以通過更有意義的方式被消費(fèi)、被組合。

1.1 與整體架構(gòu)的比較

　　整體架構(gòu)把所有功能都放到一個(gè)進(jìn)程中，如圖1所示，其中每個(gè)形狀塊代表一個(gè)功能;而微服務(wù)架構(gòu)會(huì)將不同的功能放置到分離的多個(gè)服務(wù)進(jìn)程中，如圖2所示。

　　在系統(tǒng)服務(wù)能力需要擴(kuò)展時(shí)，采用整體架構(gòu)的系統(tǒng)只能復(fù)制整個(gè)系統(tǒng)到多個(gè)服務(wù)器上，如圖3所示;而采用微服務(wù)架構(gòu)的系統(tǒng)則僅根據(jù)不同服務(wù)的服務(wù)負(fù)載能力需求來決定復(fù)制到多少個(gè)服務(wù)器上，如圖4所示。

1.2 微服務(wù)架構(gòu)的優(yōu)點(diǎn)

　　1)每個(gè)服務(wù)都比較簡單，只關(guān)注于一個(gè)業(yè)務(wù)功能;

　　2)微服務(wù)架構(gòu)方式是松耦合的，可以提供更高的靈活性;

　　3)微服務(wù)可通過最佳及最合適的不同的編程語言與工具進(jìn)行開發(fā)，能夠做到有的放矢地解決針對(duì)性問題;

　　4)每個(gè)微服務(wù)可由不同團(tuán)隊(duì)獨(dú)立開發(fā)，互不影響，加快推出市場(chǎng)的速度;

　　5)微服務(wù)架構(gòu)是持續(xù)交付(CD)的巨大推動(dòng)力，允許在頻繁發(fā)布不同服務(wù)的同時(shí)保持系統(tǒng)其他部分的可用性和穩(wěn)定性。

1.3 微服務(wù)架構(gòu)的缺點(diǎn)

　　微服務(wù)的一些想法在實(shí)踐上是好的，但當(dāng)整體實(shí)現(xiàn)時(shí)也會(huì)呈現(xiàn)出其復(fù)雜性，主要約束性體現(xiàn)在如下幾個(gè)方面：

　　1)運(yùn)維開銷及成本增加：整體應(yīng)用可能只需部署至一小片應(yīng)用服務(wù)區(qū)集群，而微服務(wù)架構(gòu)可能變成需要構(gòu)建/測(cè)試/部署/運(yùn)行數(shù)十個(gè)獨(dú)立的服務(wù)，并可能需要支持多種語言和環(huán)境。

　　2)代碼重復(fù)：某些底層功能需要被多個(gè)服務(wù)所用，為了避免將“同步耦合引入到系統(tǒng)中”，有時(shí)需要向不同服務(wù)添加一些代碼，這就會(huì)導(dǎo)致代碼重復(fù)。

　　3)分布式系統(tǒng)的復(fù)雜性：作為一種分布式系統(tǒng)，微服務(wù)引入了復(fù)雜性和其他若干問題，例如網(wǎng)絡(luò)延遲、容錯(cuò)性、消息序列化、不可靠的網(wǎng)絡(luò)、異步機(jī)制、版本化、差異化的工作負(fù)載等，開發(fā)人員需要考慮以上的分布式系統(tǒng)問題。

　　4)可測(cè)性的挑戰(zhàn)：在動(dòng)態(tài)環(huán)境下服務(wù)間的交互會(huì)產(chǎn)生非常微妙的行為，難以可視化及全面測(cè)試。經(jīng)典微服務(wù)往往不太重視測(cè)試，更多的是通過監(jiān)控發(fā)現(xiàn)生產(chǎn)環(huán)境的異常，進(jìn)而快速回滾或采取其他必要的行動(dòng)。但對(duì)于特別在意風(fēng)險(xiǎn)規(guī)避監(jiān)管或投產(chǎn)環(huán)境錯(cuò)誤會(huì)產(chǎn)生顯著影響的場(chǎng)景下需要特別注意。