微服務(wù)架構(gòu)在校園智能安全接送系統(tǒng)中的應(yīng)用

萬 燕, 朱 翔

(東華大學(xué) 計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院, 上海201600)

0 引 言

學(xué)生上學(xué)接送問題作為校園安全中的重要一環(huán),涉及到學(xué)校和家長兩方面的配合,現(xiàn)代社會(huì)快速發(fā)展,大多數(shù)父母工作繁忙無法親自接送孩子,很多時(shí)候需要家中老人接送孩子或者孩子獨(dú)自一人上下學(xué),但是老人畢竟行動(dòng)不便,而孩子自身缺乏安全意識(shí)。 父母會(huì)擔(dān)心孩子是否安全上下學(xué),但又無法實(shí)時(shí)聯(lián)系確認(rèn)。

校園智能安全接送系統(tǒng)是針對這一現(xiàn)實(shí)情況所設(shè)計(jì)的系統(tǒng),它能夠快速甄別幼兒園、小學(xué)接送人員的身份,保護(hù)學(xué)生安全,且不影響通行速度。 而在此系統(tǒng)實(shí)際使用過程中發(fā)現(xiàn),在工作日的早上送孩子入校和晚上接孩子放學(xué)兩個(gè)時(shí)間段會(huì)產(chǎn)生大量的、單一功能性的請求,在普通的時(shí)間段請求量相對較少。 基于這種情況,采用傳統(tǒng)的單體架構(gòu)式應(yīng)用無法對于某些功能單獨(dú)進(jìn)行高并發(fā)配置,只能對整個(gè)系統(tǒng)進(jìn)行配置,無法根據(jù)時(shí)間段靈活切換,例如無法單獨(dú)增加或減少某一服務(wù)以達(dá)到負(fù)載均衡,只能增加或減少整個(gè)系統(tǒng)的部署數(shù)量,造成部分資源的浪費(fèi)。 此外,單體架構(gòu)本身也存在開發(fā)、維護(hù)、擴(kuò)展困難的問題。 而新興的微服務(wù)架構(gòu)則可以很好的滿足這種任務(wù)的需要。

1 微服務(wù)架構(gòu)簡介

微服務(wù)最早由Martin Fowler 與James Lewis 于2014 年共同提出,其目的是有效的拆分應(yīng)用,實(shí)現(xiàn)敏捷開發(fā)和部署。 微服務(wù)架構(gòu)的設(shè)計(jì)理念是使用多個(gè)小型服務(wù)組合來開發(fā)單個(gè)應(yīng)用的方式,每個(gè)服務(wù)運(yùn)行在自己的進(jìn)程中,服務(wù)之間使用輕量級(jí)機(jī)制進(jìn)行通信,通常使用HTTP 協(xié)議下的應(yīng)用程序接口,即HTTP Application Programming Interface ( HTTP API)。 服務(wù)基于業(yè)務(wù)能力構(gòu)建,能夠獨(dú)立部署,滿足分布式部署的需求。 此外,各個(gè)服務(wù)可以使用不同的編程語言、不同數(shù)據(jù)存儲(chǔ)技術(shù),并保持最低限度的集中式管理,實(shí)現(xiàn)單個(gè)服務(wù)的高內(nèi)聚、服務(wù)之間低耦合的效果。

微服務(wù)的關(guān)鍵不僅僅是微服務(wù)本身,系統(tǒng)本身也要提供一套基礎(chǔ)的架構(gòu),使得微服務(wù)可以獨(dú)立的部署、運(yùn)行、升級(jí)。 不僅如此,整個(gè)系統(tǒng)架構(gòu)需要使微服務(wù)與微服務(wù)之間在結(jié)構(gòu)上"松耦合",在功能上則為一個(gè)統(tǒng)一的整體。 這種所謂的"統(tǒng)一的整體"的表現(xiàn)方式是統(tǒng)一風(fēng)格的界面,統(tǒng)一的權(quán)限管理,統(tǒng)一的安全策略,統(tǒng)一的上線過程,統(tǒng)一的日志和審計(jì)方法,統(tǒng)一的調(diào)度方式,統(tǒng)一的訪問入口等等［1］。

對比傳統(tǒng)的單體架構(gòu)模式,微服務(wù)架構(gòu)的優(yōu)勢是顯而易見的［2-3］：

(1)按業(yè)務(wù)功能劃分使得每一個(gè)微服務(wù)功能較整個(gè)單體架構(gòu)而言簡單很多,且功能之間都具有一定的邏輯性,服務(wù)邊界明確,更加具有目標(biāo)性,易于開發(fā)和維護(hù)。

(2)每一個(gè)微服務(wù)都可以使用不同的開發(fā)語言,基于不同的平臺(tái)實(shí)現(xiàn),可以根據(jù)技術(shù)棧自由選擇任何合適的技術(shù)進(jìn)行開發(fā),僅僅需要提供統(tǒng)一的對外接口即可,使得每一個(gè)微服務(wù)的靈活性大大提高。

(3)每一個(gè)微服務(wù)都可以獨(dú)立部署,擁有獨(dú)立的進(jìn)程。 當(dāng)某一個(gè)微服務(wù)進(jìn)行了修改,僅需對其服務(wù)進(jìn)行重新編譯、部署。 而當(dāng)某一個(gè)微服務(wù)出現(xiàn)了問題,也僅影響到某些與其有關(guān)聯(lián)的微服務(wù),對整個(gè)應(yīng)用的影響較小。

(4)微服務(wù)架構(gòu)屬于分布式架構(gòu)系統(tǒng),各個(gè)微服務(wù)之間的耦合度較低。 隨著業(yè)務(wù)的改變,可以隨時(shí)增加新的業(yè)務(wù)微服務(wù)或者刪除舊的業(yè)務(wù)微服務(wù),具有強(qiáng)大的橫向擴(kuò)展性。 并且可以根據(jù)實(shí)際需要,對某些微服務(wù)進(jìn)行集群部署,以解決隨著用戶數(shù)量增加而帶來的并發(fā)問題。

2 微服務(wù)架構(gòu)在校園智能安全接送系統(tǒng)中的應(yīng)用

當(dāng)前開發(fā)和應(yīng)用的校園智能安全接送系統(tǒng),在實(shí)際使用過程中暴露出諸多問題,例如高峰時(shí)間段并發(fā)請求響應(yīng)時(shí)間過長、新增部署服務(wù)器操作步驟繁瑣、在開發(fā)過程中未對代碼進(jìn)行有效管理、單體架構(gòu)本身的復(fù)雜度高、服務(wù)間耦合度高導(dǎo)致新增功能或修改舊功能十分困難等嚴(yán)重問題。 現(xiàn)引入微服務(wù)架構(gòu)對該系統(tǒng)進(jìn)行重構(gòu),提升系統(tǒng)的穩(wěn)定性、可用性、高并發(fā)性、以及橫向擴(kuò)展性［4］。

2.1 系統(tǒng)主要功能模塊

在微服務(wù)架構(gòu)中,每一個(gè)業(yè)務(wù)邏輯服務(wù)僅包含功能單一、獨(dú)立、簡單的業(yè)務(wù),以便于不同開發(fā)者基于自己的技術(shù)棧進(jìn)行開發(fā),從而保證系統(tǒng)的快速迭代和升級(jí)［5］。 校園智能安全接送系統(tǒng)的主要功能模塊如圖1。

圖1 校園智能安全接送系統(tǒng)主要功能模塊Fig. 1 The main functional modules of the Campus Intelligent Security Pick-up System

(1)用戶模塊。 主要包括登陸和注冊功能,用于為家長和教師提供進(jìn)入系統(tǒng)的接口。

(2)家庭模塊。 由家庭、家長以及學(xué)生3 個(gè)功能模塊組成,用于家長用戶對于自己家庭的管理。

(3)教師模塊。 包含教師和班級(jí)兩個(gè)功能模塊,用于維護(hù)和查看教師個(gè)人信息以及其管理的班級(jí)的信息。

(4)接送記錄模塊。 根據(jù)人臉識(shí)別返回的結(jié)果生成接送記錄,為家長和教師用戶提供學(xué)生的接送記錄查詢功能。

(5)通知服務(wù)。 用于接收校內(nèi)的通知類消息,教師也可以通過該模塊發(fā)布通知,通知家長和其他教師相關(guān)的校內(nèi)事務(wù)。

(6)文件模塊。 主要功能是接收上傳的圖片,并將圖片存入文件存儲(chǔ)服務(wù)器,提供前端的人臉識(shí)別進(jìn)行人臉對比識(shí)別,確定學(xué)生以及其接送人的身份,保證學(xué)生的安全。

2.2 服務(wù)劃分

根據(jù)微服務(wù)架構(gòu)原理,結(jié)合當(dāng)前系統(tǒng)的實(shí)際情況,對校園智能安全接送系統(tǒng)進(jìn)行拆分,劃分出系統(tǒng)運(yùn)行服務(wù)和業(yè)務(wù)邏輯服務(wù)。 系統(tǒng)運(yùn)行服務(wù)提供整個(gè)系統(tǒng)運(yùn)行所需要的功能；業(yè)務(wù)邏輯服務(wù)提供系統(tǒng)用戶所需要的功能。 系統(tǒng)劃分出的微服務(wù)如表1 所示。

表1 系統(tǒng)微服務(wù)列表Tab. 1 System micro-services list

各個(gè)微服務(wù)對其它微服務(wù)暴露獨(dú)立的服務(wù)接口,用于對外或?qū)?nèi)調(diào)用,每一個(gè)微服務(wù)只關(guān)注單一獨(dú)立的業(yè)務(wù)功能,方便后期擴(kuò)展或修改。

2.3 架構(gòu)技術(shù)選型

整體微服務(wù)平臺(tái)基于Spring Cloud 進(jìn)行搭建,Spring Cloud 是一系列框架的有序結(jié)合,利用Spring Boot 的開發(fā)便利性簡化了分布式系統(tǒng)的開發(fā),包含了微服務(wù)的方方面面,具有無配置文件、組件輕量且優(yōu)秀,開發(fā)簡便、靈活等特點(diǎn)［6］。

Spring-boot 作為微服務(wù)的基礎(chǔ)開發(fā)框架,提供包括依賴注入、嵌入式容器、持久化開發(fā)等功能。 各個(gè)微服務(wù)的自動(dòng)化注冊和發(fā)現(xiàn)由Eureka 提供。Spring Cloud Config 提供集中管理式的微服務(wù)配置。Nginx 以及Zuul 相互配合提供網(wǎng)關(guān)、路由選擇、監(jiān)控以及負(fù)載均衡。 各個(gè)微服務(wù)之間的調(diào)用通過引入Fegin 實(shí)現(xiàn)。 系統(tǒng)整體的鏈路狀態(tài)通過ZipKin 監(jiān)控。

2.4 系統(tǒng)整體框架

基于微服務(wù)的校園智能安全接送系統(tǒng)的架構(gòu)如圖2 所示。

圖2 校園智能安全接送系統(tǒng)整體架構(gòu)Fig. 2 The overall architecture of the Campus Intelligent Security Pick-up System

基于微服務(wù)的“高內(nèi)聚、松耦合”的設(shè)計(jì)思想,為了實(shí)現(xiàn)系統(tǒng)高可用、高并發(fā)、高性能的三個(gè)目標(biāo),保持系統(tǒng)的開放性、可擴(kuò)展性,對現(xiàn)有系統(tǒng)提供的業(yè)務(wù)進(jìn)行重構(gòu),使之解耦成相互獨(dú)立且功能專一的服務(wù),服務(wù)之間通過Spring Cloud 的Feign 組件進(jìn)行通信以及負(fù)載均衡,通過各個(gè)服務(wù)互相協(xié)作構(gòu)建供外部訪問的應(yīng)用系統(tǒng)［7］。

校園智能安全接送系統(tǒng)框架主要分為4 個(gè)模塊：

(1)外部訪問模塊。 Nginx 作為反向代理服務(wù)器對外提供接口地址,Zuul 作為微服務(wù)網(wǎng)關(guān)向Nginx 提供微服務(wù)內(nèi)部訪問的接口,通過Nginx 和多個(gè)Zuul 組合成為系統(tǒng)的統(tǒng)一對外接口,用戶僅需訪問Nginx 提供的對外接口,即可使用系統(tǒng)相對應(yīng)的功能［8］。

(2)服務(wù)配置及治理模塊。 該模塊由Spring Cloud Config 以及Spring Cloud Eureka 組成,所有微服務(wù)的配置文件由Config 微服務(wù)統(tǒng)一管理,方便修改和部署。 Eureka 負(fù)責(zé)服務(wù)發(fā)現(xiàn)和注冊,將微服務(wù)信息提供給Zuul 和Feign 用于查詢各個(gè)微服務(wù)的地址以及進(jìn)行負(fù)載均衡。

(3)業(yè)務(wù)邏輯與服務(wù)模塊。 由重構(gòu)、拆分出來的多個(gè)相互獨(dú)立、可拓展的微服務(wù)構(gòu)成,包括業(yè)務(wù)邏輯相關(guān)的微服務(wù)與基礎(chǔ)服務(wù)。 業(yè)務(wù)邏輯微服務(wù)包括用戶微服務(wù)、家庭微服務(wù)、班級(jí)微服務(wù)等。 基礎(chǔ)服務(wù)則是一些通用微服務(wù),包括redis 微服務(wù)、文件微服務(wù)以及工具類微服務(wù)。

(4)數(shù)據(jù)庫模塊。 由redis 和Mysql 構(gòu)成的數(shù)據(jù)庫模塊,基于微服務(wù)的理念,對于每一個(gè)需要數(shù)據(jù)庫的微服務(wù)均構(gòu)建了一個(gè)單獨(dú)的數(shù)據(jù)庫,這樣雖然會(huì)造成部分?jǐn)?shù)據(jù)冗余,但是對于單個(gè)服務(wù)的開發(fā)、管理、擴(kuò)展而言有很大的益處。 同時(shí),采用了redis 作為數(shù)據(jù)庫的二級(jí)緩存,提高在高請求量、高并發(fā)環(huán)境下的數(shù)據(jù)讀取速度。

2.5 高并發(fā)、高可用處理

在單體架構(gòu)系統(tǒng)的使用過程中,學(xué)生早上上學(xué)和下午放學(xué)兩個(gè)時(shí)間段是學(xué)生出入校的高峰,此時(shí)有識(shí)別接送人和學(xué)生以及生成接送記錄這兩種功能的大量重復(fù)的請求。 原有系統(tǒng)對這類情況并沒有特殊處理,導(dǎo)致在此種情況下請求會(huì)丟失、報(bào)錯(cuò),或是服務(wù)響應(yīng)超時(shí)、出錯(cuò)、返回速度慢等問題,嚴(yán)重影響用戶的實(shí)際體驗(yàn)。 引入微服務(wù)架構(gòu),通過以下5 點(diǎn),優(yōu)化了系統(tǒng)在高并發(fā)情況下的可用性。

(1)Nginx 和高可用Zuul 組合的雙層網(wǎng)關(guān)。 引入Nginx 后,Zuul 不會(huì)直接接收外部的請求,而是通過Nginx 轉(zhuǎn)發(fā)請求,Zuul 會(huì)根據(jù)高可用策略,啟動(dòng)多個(gè)實(shí)例。 當(dāng)Nginx 收到請求后,會(huì)根據(jù)下轄的Zuul實(shí)例個(gè)數(shù)以及承載量,進(jìn)行負(fù)載均衡。 不同的Zuul網(wǎng)關(guān)可以同時(shí)承擔(dān)部分請求轉(zhuǎn)發(fā)和微服務(wù)查詢的負(fù)擔(dān),進(jìn)行異步處理,提高并發(fā)量和可用性。

(2)針對Zuul 的配置優(yōu)化問題。 由于Zuul 整合了Hystrix,而Hystrix 的核心功能中包含資源隔離機(jī)制,目的是將多個(gè)依賴服務(wù)的調(diào)用分別隔離到各自的資源池內(nèi)。 這是一個(gè)很重要的防止服務(wù)雪崩的安全措施,但Zuul 默認(rèn)使用的信號(hào)量隔離機(jī)制以及其默認(rèn)的配置,導(dǎo)致Zuul 在面對高于100 的并發(fā)量時(shí)會(huì)直接報(bào)錯(cuò),需要調(diào)整信號(hào)量大小,或者使用線程隔離機(jī)制同時(shí)調(diào)整線程池的大小,以適應(yīng)高并發(fā)時(shí)的請求數(shù)量。 本文采用調(diào)整信號(hào)量大小的方式解決高并發(fā)請求。

(3)負(fù)載均衡。 負(fù)載均衡是高可用和高并發(fā)處理的基礎(chǔ),將同種請求給予相同微服務(wù)的不同實(shí)例進(jìn)行處理,減少單個(gè)服務(wù)器的壓力的同時(shí),也進(jìn)行了異步處理,提高并發(fā)處理數(shù)量和響應(yīng)速度。 負(fù)載均衡不僅在雙層網(wǎng)關(guān)中應(yīng)用,在內(nèi)部的Feign 中也會(huì)被應(yīng)用,提高微服務(wù)內(nèi)部的并發(fā)量和可用性。 且由于微服務(wù)架構(gòu)“高內(nèi)聚,低耦合”的特點(diǎn),可根據(jù)需要,對特定的微服務(wù)啟動(dòng)多個(gè)實(shí)例進(jìn)行負(fù)載均衡,而不需要像單體架構(gòu)一樣需要額外啟動(dòng)所有的服務(wù)實(shí)例進(jìn)行負(fù)載均衡,從而減少了資源的使用。

Zuul 和Feign 通過整合的Ribbon 組件對請求進(jìn)行負(fù)載均衡,默認(rèn)的負(fù)載均衡算法是簡單的輪詢機(jī)制,這種方法適用于部署在配置區(qū)別不大的服務(wù)器上的實(shí)例,而對于部署在配置區(qū)別較大的服務(wù)器上的實(shí)例,適合使用指定權(quán)重的方式,增加配置較好的服務(wù)器的輪詢幾率。 本文由于所有實(shí)例均運(yùn)行于同一服務(wù)器,所以使用Ribbon 默認(rèn)的輪詢機(jī)制進(jìn)行負(fù)載均衡。

(4) Feign 配置。 Feign 默認(rèn)使用基于Java Development Kit(JDK)提供的URLConnection 調(diào)用HTTP 接口,其不具備連接池,不能很好的適應(yīng)高并發(fā)的情況,而Apache HttpClient 和okhttp 都支持配置連接池功能,可以通過修改配置使用這兩者,但需要注意的是URLConnection 要比Apache HttpClient和okhttp 在調(diào)用速度上更優(yōu),因此需要根據(jù)實(shí)際情況來采用不同的HTTP 請求方式。 本文采用Apache HttpClient 并通過設(shè)置連接池以應(yīng)對高并發(fā)請求。

(5)服務(wù)重試機(jī)制和熔斷機(jī)制。 在原系統(tǒng)的使用過程中,發(fā)現(xiàn)請求過多時(shí),會(huì)發(fā)生請求報(bào)錯(cuò),但不修改任何錯(cuò)誤再次重試卻成功,或是請求長時(shí)間無反應(yīng)的情況,針對此種情況,引入了服務(wù)重試機(jī)制和熔斷機(jī)制。

①由于服務(wù)器卡頓、數(shù)據(jù)庫連接超時(shí)或是網(wǎng)絡(luò)震蕩等原因造成的請求報(bào)錯(cuò),通過Ribbon 的重試機(jī)制,對目標(biāo)微服務(wù)再次發(fā)送請求,值得注意的是：由于重試機(jī)制會(huì)再次發(fā)送請求,所以當(dāng)微服務(wù)確實(shí)出現(xiàn)邏輯問題時(shí),會(huì)導(dǎo)致一個(gè)請求被循環(huán)發(fā)送多次,當(dāng)存在大量類似請求時(shí),容易造成系統(tǒng)內(nèi)部大量資源被占用,引發(fā)整個(gè)系統(tǒng)卡頓甚至崩潰,因此重試的次數(shù)和時(shí)機(jī)需要根據(jù)實(shí)際需要調(diào)控,本系統(tǒng)中設(shè)定重試5 次,均失敗則返回錯(cuò)誤信息。

②因?yàn)榉?wù)器積壓的請求過多,引起處理速度慢、響應(yīng)請求時(shí)間過長,則通過Hystrix 的熔斷機(jī)制：當(dāng)超過規(guī)定時(shí)間而服務(wù)沒有返回任何消息時(shí),斷定此服務(wù)目前不可用,此時(shí)可以通過觸發(fā)服務(wù)重試機(jī)制,使得Ribbon 重試發(fā)送請求給其他的實(shí)例處理,提高系統(tǒng)的可用性。 如果沒有其他實(shí)例,則返回用戶報(bào)錯(cuò)信息。 需要注意的是：Hystrix 默認(rèn)的熔斷時(shí)間僅1 s,需要根據(jù)實(shí)際進(jìn)行調(diào)整。 本系統(tǒng)根據(jù)實(shí)際請求響應(yīng)的時(shí)間,設(shè)定為5 s。 此外,還需要修改Hystrix 資源隔離機(jī)制,默認(rèn)是線程隔離機(jī)制,需要調(diào)整其的線程池大小,本系統(tǒng)中調(diào)整為500 大小。

3 實(shí)驗(yàn)與分析

3.1 實(shí)驗(yàn)環(huán)境

該實(shí)驗(yàn)的測試環(huán)境為：操作系統(tǒng)Ubuntu 14.6 版本,32 G 內(nèi)存,處理器為Intel 2.6 GHz,JDK 版本為1.8 的Java 平臺(tái),數(shù)據(jù)庫為MySql 5.5.27 版本,使用Tomact 4.0 版本進(jìn)行部署。 單體架構(gòu)應(yīng)用和微服務(wù)架構(gòu)中的各個(gè)微服務(wù)都均只部署一個(gè)實(shí)例。 采用Jmeter 工具,模擬用戶向單體架構(gòu)系統(tǒng)與重構(gòu)的微服務(wù)架構(gòu)系統(tǒng)發(fā)送請求,主要記錄兩種架構(gòu)在調(diào)用服務(wù)時(shí)產(chǎn)生的數(shù)據(jù),以及服務(wù)器響應(yīng)時(shí)間［9］。

以下對比分析單體架構(gòu)系統(tǒng)與微服務(wù)架構(gòu)系統(tǒng)在高并發(fā)環(huán)境下的性能差異,以獲取家庭成員信息以及生成接送記錄為例。

3.2 實(shí)驗(yàn)結(jié)果

對比分析單體架構(gòu)系統(tǒng)與微服務(wù)架構(gòu)系統(tǒng)在高并發(fā)環(huán)境下的性能差異,以獲取家庭成員信息以及生成接送記錄。

3.2.1 獲取家庭成員信息耗時(shí)對比

對兩種架構(gòu)的系統(tǒng)分別模擬每秒100 個(gè)用戶同時(shí)請求,持續(xù)5 s,請求獲取家庭成員信息的接口,結(jié)果如圖3 所示。

圖3 獲取家庭成員信息響應(yīng)時(shí)間對比Fig. 3 Comparison of response time for obtaining family member information

由圖3 可知,在面對5 s 的100 級(jí)并發(fā),共500 次請求的情況下,單體架構(gòu)的響應(yīng)時(shí)間分別為2 483 ms、4 187 ms、4 394 ms、4 319 ms、4 661 ms,而微服務(wù)架構(gòu)響應(yīng)時(shí)間大幅度減少,分別為84 ms、109 ms、93 ms、98 ms、82 ms。 此外,單體架構(gòu)隨著請求數(shù)量的增加,之前的請求還未響應(yīng),導(dǎo)致請求數(shù)量堆積愈來愈多,響應(yīng)速度越來愈慢,而微服務(wù)則沒有此類的問題。

3.2.2 生成接送記錄耗時(shí)對比

對兩種架構(gòu)的系統(tǒng)分別模擬每秒100 個(gè)用戶同時(shí)請求,持續(xù)5 s,請求生成接送記錄的接口,結(jié)果如圖4 所示。

圖4 生成接送記錄響應(yīng)時(shí)間對比Fig. 4 Comparison of response time when generating pick-up records

單體架構(gòu)由于沒有對高并發(fā)進(jìn)行優(yōu)化,導(dǎo)致在高并發(fā)的情況下,響應(yīng)速度達(dá)到平均84 110 ms,而微服務(wù)僅需144 ms,是一個(gè)極大的進(jìn)步。

經(jīng)過實(shí)驗(yàn)結(jié)果分析,重構(gòu)后使用微服務(wù)架構(gòu)與單體架構(gòu)相比,極大的減少了在高并發(fā)情況下的請求響應(yīng)時(shí)間,此外,該系統(tǒng)還可以通過部署多個(gè)服務(wù)實(shí)例,進(jìn)一步提高系統(tǒng)性能［10］。

4 結(jié)束語

本文介紹了微服務(wù)的由來,設(shè)計(jì)理念。結(jié)合傳統(tǒng)單體架構(gòu)與微服務(wù)架構(gòu)的對比,闡明微服務(wù)架構(gòu)的現(xiàn)有優(yōu)勢。 分析原校園智能安全接送系統(tǒng)中存在的問題及實(shí)際需求,提出基于微服務(wù)架構(gòu)設(shè)計(jì),實(shí)現(xiàn)了承載高并發(fā)、高可用的校園智能安全接送系統(tǒng)。

目前,微服務(wù)架構(gòu)已廣泛應(yīng)用于各中小型企業(yè),但其也還存在一些問題,例如當(dāng)微服務(wù)數(shù)量過多,會(huì)對整個(gè)系統(tǒng)的服務(wù)配置、部署以及健康監(jiān)控會(huì)提出很高的要求,微服務(wù)架構(gòu)還存在很大的發(fā)展空間,在后續(xù)的校園智能安全接送系統(tǒng)的開發(fā)和建設(shè)中,將不斷探索和完善。