基于SpringBoot微服務(wù)架構的城市一卡通手機充值支撐系統研究
作者/ 溫曉麗 蘇浩偉 陳歡 鄒大畢 廣州羊城通有限公司(廣東 廣州 510080)
本文引用地址:http://dyxdggzs.com/article/201709/364878.htm摘要:基于微服務(wù)架構而構建的應用系統是將復雜的大系統分解成了一系列小的單獨的子服務(wù)系統,這些子服務(wù)系統可以單獨部署發(fā)布,也可以組合成一個(gè)應用發(fā)布。伴隨著(zhù)移動(dòng)互聯(lián)網(wǎng)應用的快速發(fā)展,相應的服務(wù)系統更新迭代頻繁,采用微服務(wù)架構之后的系統可以很好地適應移動(dòng)互聯(lián)網(wǎng)這種需求不斷迭代更新的應用場(chǎng)景。城市一卡通手機充值系統是城市一卡通公司在移動(dòng)互聯(lián)網(wǎng)領(lǐng)域的應用服務(wù)系統,同樣地面臨著(zhù)業(yè)務(wù)不斷快速迭代更新的需求,基于此,進(jìn)行城市一卡通手機充值支撐系統的構建過(guò)程中采用了基于SpringBoot微服務(wù)架構的研究是必要和有參考意義的。
引言
隨著(zhù)時(shí)代的發(fā)展,在信息系統建設方面,傳統IT架構面臨著(zhù)以下一些問(wèn)題:
1)使用傳統的整體式架構(Monolithic Architecture)應用開(kāi)發(fā)系統,如CRM、ERP等大型應用,隨著(zhù)新需求的不斷增加,企業(yè)更新和修復大型整體式應用變得越來(lái)越困難。在系統更新時(shí),往往牽一發(fā)而動(dòng)全身,稍有不慎就可能帶來(lái)大的損失。
2)隨著(zhù)移動(dòng)互聯(lián)網(wǎng)的發(fā)展,企業(yè)被迫將其應用遷移至現代化UI界面架構以便能兼容移動(dòng)設備,這要求企業(yè)能實(shí)現應用功能的快速上線(xiàn),而傳統IT架構在系統快速迭代更新方面難度較大。
3)隨著(zhù)應用云化的日益普及,生于云端的應用具有與傳統IT不同的技術(shù)基因和開(kāi)發(fā)運維模式,此時(shí)再生搬硬套傳統IT架構往往會(huì )產(chǎn)生適得其反的效果。
4)移動(dòng)互聯(lián)網(wǎng)相關(guān)技術(shù)快速發(fā)展,云計算及互聯(lián)網(wǎng)公司大量開(kāi)源輕量級技術(shù)不停涌現并日漸成熟,主要為如下幾方面:互聯(lián)網(wǎng)/內聯(lián)網(wǎng)/網(wǎng)絡(luò )更加成熟,輕量級運行時(shí)技術(shù)的出現(node.js等),新的方法與工具(Agile、DevOps、TDD、CI及XP),新的輕量級協(xié)議(RESTful API接口和輕量級消息機制),簡(jiǎn)化的基礎設施,操作系統虛擬化(hypervisors)、容器化(Docker)、基礎設施即服務(wù)(IaaS)、工作負載虛擬化(Kubernetes、Spark)等;服務(wù)平臺化(PaaS),云服務(wù)平臺上具有自動(dòng)縮放、工作負載管理、SLA 管理、消息機制、緩存、構建管理等各種按需使用的服務(wù),新的可替代數據持久化模型:如NoSQL、MapReduce、BASE、CQRS等,標準化代碼管理等。
這一切都催生了新的架構設計風(fēng)格,即微服務(wù)架構的出現。
1 微服務(wù)架構概述
微服務(wù)是一種架構風(fēng)格,一個(gè)大型復雜軟件應用由一個(gè)或多個(gè)微服務(wù)組成。系統中的各個(gè)微服務(wù)可被獨立部署,各個(gè)微服務(wù)之間是松耦合的。每個(gè)微服務(wù)僅關(guān)注于完成一件任務(wù)并很好地完成該任務(wù)。在所有情況下,每個(gè)任務(wù)代表著(zhù)一個(gè)小的業(yè)務(wù)能力。
微服務(wù)具備彈性和伸縮性。微服務(wù)不只依賴(lài)單個(gè)服務(wù)器和部署,它們可以被發(fā)布到多個(gè)機器上,或者多個(gè)數據中心及其它任何可用的區域。如果一個(gè)服務(wù)失效,可以啟動(dòng)另外一個(gè)。因為整個(gè)應用被分解成了微服務(wù)(小型服務(wù)),可以很容易地對其中某些熱門(mén)的服務(wù)進(jìn)行橫向擴展。
微服務(wù)一般會(huì )提供基于HTTP/JSON的API端點(diǎn)。這樣可以很容易地與其它服務(wù)(開(kāi)源或閉源的)集成,只要這些服務(wù)提供了HTTP/JSON接口。服務(wù)可以通過(guò)更有意義的方式被消費、被組合。
1.1 與整體架構的比較
整體架構把所有功能都放到一個(gè)進(jìn)程中,如圖1所示,其中每個(gè)形狀塊代表一個(gè)功能;而微服務(wù)架構會(huì )將不同的功能放置到分離的多個(gè)服務(wù)進(jìn)程中,如圖2所示。
在系統服務(wù)能力需要擴展時(shí),采用整體架構的系統只能復制整個(gè)系統到多個(gè)服務(wù)器上,如圖3所示;而采用微服務(wù)架構的系統則僅根據不同服務(wù)的服務(wù)負載能力需求來(lái)決定復制到多少個(gè)服務(wù)器上,如圖4所示。
1.2 微服務(wù)架構的優(yōu)點(diǎn)
1)每個(gè)服務(wù)都比較簡(jiǎn)單,只關(guān)注于一個(gè)業(yè)務(wù)功能;
2)微服務(wù)架構方式是松耦合的,可以提供更高的靈活性;
3)微服務(wù)可通過(guò)最佳及最合適的不同的編程語(yǔ)言與工具進(jìn)行開(kāi)發(fā),能夠做到有的放矢地解決針對性問(wèn)題;
4)每個(gè)微服務(wù)可由不同團隊獨立開(kāi)發(fā),互不影響,加快推出市場(chǎng)的速度;
5)微服務(wù)架構是持續交付(CD)的巨大推動(dòng)力,允許在頻繁發(fā)布不同服務(wù)的同時(shí)保持系統其他部分的可用性和穩定性。
1.3 微服務(wù)架構的缺點(diǎn)
微服務(wù)的一些想法在實(shí)踐上是好的,但當整體實(shí)現時(shí)也會(huì )呈現出其復雜性,主要約束性體現在如下幾個(gè)方面:
1)運維開(kāi)銷(xiāo)及成本增加:整體應用可能只需部署至一小片應用服務(wù)區集群,而微服務(wù)架構可能變成需要構建/測試/部署/運行數十個(gè)獨立的服務(wù),并可能需要支持多種語(yǔ)言和環(huán)境。
2)代碼重復:某些底層功能需要被多個(gè)服務(wù)所用,為了避免將“同步耦合引入到系統中”,有時(shí)需要向不同服務(wù)添加一些代碼,這就會(huì )導致代碼重復。
3)分布式系統的復雜性:作為一種分布式系統,微服務(wù)引入了復雜性和其他若干問(wèn)題,例如網(wǎng)絡(luò )延遲、容錯性、消息序列化、不可靠的網(wǎng)絡(luò )、異步機制、版本化、差異化的工作負載等,開(kāi)發(fā)人員需要考慮以上的分布式系統問(wèn)題。
4)可測性的挑戰:在動(dòng)態(tài)環(huán)境下服務(wù)間的交互會(huì )產(chǎn)生非常微妙的行為,難以可視化及全面測試。經(jīng)典微服務(wù)往往不太重視測試,更多的是通過(guò)監控發(fā)現生產(chǎn)環(huán)境的異常,進(jìn)而快速回滾或采取其他必要的行動(dòng)。但對于特別在意風(fēng)險規避監管或投產(chǎn)環(huán)境錯誤會(huì )產(chǎn)生顯著(zhù)影響的場(chǎng)景下需要特別注意。
評論