新聞中心

EEPW首頁 > 手機與無線通信 > 設計應用 > 基于SpringBoot微服務架構的城市一卡通手機充值支撐系統(tǒng)研究

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

作者:溫曉麗 蘇浩偉 陳歡 鄒大畢 時間:2017-09-27 來源:電子產(chǎn)品世界 收藏
編者按:基于微服務架構而構建的應用系統(tǒng)是將復雜的大系統(tǒng)分解成了一系列小的單獨的子服務系統(tǒng),這些子服務系統(tǒng)可以單獨部署發(fā)布,也可以組合成一個應用發(fā)布。伴隨著移動互聯(lián)網(wǎng)應用的快速發(fā)展,相應的服務系統(tǒng)更新迭代頻繁,采用微服務架構之后的系統(tǒng)可以很好地適應移動互聯(lián)網(wǎng)這種需求不斷迭代更新的應用場景。城市一卡通手機充值系統(tǒng)是城市一卡通公司在移動互聯(lián)網(wǎng)領域的應用服務系統(tǒng),同樣地面臨著業(yè)務不斷快速迭代更新的需求,基于此,進行城市一卡通手機充值支撐系統(tǒng)的構建過程中采用了基于SpringBoot微服務架構的研究是必要和有參考意義的。

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

本文引用地址:http://m.butianyuan.cn/article/201709/364878.htm

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

引言

  隨著時代的發(fā)展,在信息系統(tǒng)建設方面,傳統(tǒng)IT架構面臨著以下一些問題:

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

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

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

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

  這一切都催生了新的架構設計風格,即微服務架構的出現(xiàn)。

1 微服務架構概述

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

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

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

1.1 與整體架構的比較

  整體架構把所有功能都放到一個進程中,如圖1所示,其中每個形狀塊代表一個功能;而微服務架構會將不同的功能放置到分離的多個服務進程中,如圖2所示。

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

1.2 微服務架構的優(yōu)點

  1)每個服務都比較簡單,只關注于一個業(yè)務功能;

  2)微服務架構方式是松耦合的,可以提供更高的靈活性;

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

  4)每個微服務可由不同團隊獨立開發(fā),互不影響,加快推出市場的速度;

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

1.3 微服務架構的缺點

  微服務的一些想法在實踐上是好的,但當整體實現(xiàn)時也會呈現(xiàn)出其復雜性,主要約束性體現(xiàn)在如下幾個方面:

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

  2)代碼重復:某些底層功能需要被多個服務所用,為了避免將“同步耦合引入到系統(tǒng)中”,有時需要向不同服務添加一些代碼,這就會導致代碼重復。

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

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



上一頁 1 2 下一頁

評論


相關推薦

技術專區(qū)

關閉