文/朱士中 王加年 先曉兵 張爾喜

常熟理工學(xué)院微服務(wù)無(wú)縫嵌入實(shí)踐教學(xué)管理平臺(tái)

文/朱士中 王加年 先曉兵 張爾喜

實(shí)踐教學(xué)管理工作復(fù)雜性分析

實(shí)踐教學(xué)管理工作的復(fù)雜性，首先體現(xiàn)在內(nèi)容上。實(shí)踐教學(xué)管理工作不僅包括很多常規(guī)性事務(wù)，如實(shí)驗(yàn)設(shè)備管理、教學(xué)資源準(zhǔn)備、實(shí)踐教學(xué)過(guò)程管理、檔案日志管理及其他日常管理，還包括很多臨時(shí)性、突發(fā)性工作。這對(duì)管理人員是一種考驗(yàn)，對(duì)從業(yè)者的心理素質(zhì)、個(gè)人能力要求極高。

實(shí)踐教學(xué)管理工作的復(fù)雜性，還體現(xiàn)在實(shí)際運(yùn)作過(guò)程中。首先，實(shí)踐教學(xué)管理工作的復(fù)雜來(lái)自教學(xué)體系的復(fù)雜，實(shí)踐教學(xué)工作內(nèi)容繁多，如實(shí)驗(yàn)教學(xué)、課程設(shè)計(jì)、實(shí)訓(xùn)、畢業(yè)實(shí)習(xí)、畢業(yè)設(shè)計(jì)等方面都設(shè)置了多樣化的實(shí)踐教學(xué)過(guò)程，一般而言，這些教學(xué)過(guò)程又與實(shí)踐教學(xué)管理工作盤根錯(cuò)節(jié)共生在一個(gè)有機(jī)體中；其次，當(dāng)前各高校為了其自身生存、發(fā)展需要，為適應(yīng)地方發(fā)展應(yīng)用需要，一般都設(shè)置了文、理、工各類專業(yè)，其專業(yè)之間的差異必然加劇其實(shí)踐教學(xué)環(huán)節(jié)的復(fù)雜性。實(shí)踐教學(xué)管理工作的內(nèi)容是一項(xiàng)十分復(fù)雜的系統(tǒng)工程，必須保證每一個(gè)環(huán)節(jié)都做到十分精準(zhǔn)，才能保障整個(gè)教學(xué)體系運(yùn)作過(guò)程順暢有序。

基于微服務(wù)架構(gòu)的技術(shù)優(yōu)劣

微服務(wù)架構(gòu)的定義

微服務(wù)這一概念出現(xiàn)于2012年，但并沒(méi)有精確地定義出這一架構(gòu)形式，雖然圍繞業(yè)務(wù)能力、自動(dòng)化部署、終端智能以及語(yǔ)言和數(shù)據(jù)的分散控制有一些常見的特性。

微服務(wù)架構(gòu)是面向服務(wù)架構(gòu)思想的一種實(shí)現(xiàn)，微服務(wù)的基本思想在于考慮圍繞著業(yè)務(wù)領(lǐng)域組件來(lái)創(chuàng)建應(yīng)用，是一種特定的軟件應(yīng)用程序設(shè)計(jì)方式——將大型軟件拆分為多個(gè)獨(dú)立可部署服務(wù)組合而成的套件方案。微服務(wù)架構(gòu)中各個(gè)應(yīng)用可獨(dú)立地進(jìn)行開發(fā)、管理和加速，在分散的組件中使用微服務(wù)云架構(gòu)和平臺(tái)使部署、管理和服務(wù)功能變得更加簡(jiǎn)單。

微服務(wù)架構(gòu)的技術(shù)優(yōu)勢(shì)

微服務(wù)架構(gòu)將原本單一的應(yīng)用按照功能邊界分解成一系列獨(dú)立專注的微服務(wù)，每個(gè)微服務(wù)對(duì)應(yīng)傳統(tǒng)應(yīng)用中的一個(gè)組件，可以獨(dú)立編譯、部署和擴(kuò)展。相對(duì)整體架構(gòu)，微服務(wù)架構(gòu)具備以下優(yōu)勢(shì)。

1.組件復(fù)雜度可控

在將應(yīng)用分解的同時(shí)，規(guī)避了原本復(fù)雜度無(wú)止境的積累，每一個(gè)微服務(wù)專注單一功能，并通過(guò)接口清晰地表述服務(wù)邊界，由于組件體積小、復(fù)雜度低，每個(gè)微服務(wù)可有一個(gè)小規(guī)模的開發(fā)團(tuán)隊(duì)掌控，易于保持高可維護(hù)性和開發(fā)效率。

2.組件獨(dú)立部署

由于微服務(wù)具備獨(dú)立的運(yùn)行進(jìn)程，所以每個(gè)微服務(wù)也可以獨(dú)立部署，當(dāng)某個(gè)服務(wù)發(fā)生變化時(shí)，無(wú)需編譯、部署整個(gè)應(yīng)用。并且當(dāng)某一個(gè)服務(wù)發(fā)生故障時(shí)，在單一的進(jìn)程傳統(tǒng)架構(gòu)下，往往會(huì)導(dǎo)致整個(gè)應(yīng)用不能使用，而在微服務(wù)架構(gòu)下，故障會(huì)被隔離在單個(gè)組件服務(wù)中。

3.可擴(kuò)展性

單個(gè)應(yīng)用可以實(shí)現(xiàn)橫向擴(kuò)展，當(dāng)不通服務(wù)組件在擴(kuò)展需求上存在差異時(shí)，微服務(wù)架構(gòu)便體現(xiàn)出靈活性，因?yàn)槊總€(gè)服務(wù)組件可以根據(jù)實(shí)際需求進(jìn)行獨(dú)立的擴(kuò)展。

微服務(wù)架構(gòu)的技術(shù)劣勢(shì)

微服務(wù)的一些想法在實(shí)踐上是好的，但當(dāng)整體實(shí)現(xiàn)時(shí)也會(huì)呈現(xiàn)出其復(fù)雜性。

1.運(yùn)維開銷及成本增加

整體應(yīng)用可能只需部署至一小片應(yīng)用服務(wù)區(qū)集群，而微服務(wù)架構(gòu)可能變成需要構(gòu)建、測(cè)試、部署、運(yùn)行等數(shù)十個(gè)獨(dú)立的服務(wù)，并可能需要支持多種語(yǔ)言和環(huán)境。這導(dǎo)致一個(gè)整體式系統(tǒng)如果由20個(gè)微服務(wù)組成，可能需要40～60個(gè)進(jìn)程。

2.必須有堅(jiān)實(shí)的開發(fā)運(yùn)維一體化技能

開發(fā)人員需要熟知運(yùn)維與投產(chǎn)環(huán)境，開發(fā)人員也需要掌握各種必要的數(shù)據(jù)存儲(chǔ)技術(shù)，具有較強(qiáng)技能的人員比較稀缺，會(huì)帶來(lái)技術(shù)人員方面的挑戰(zhàn)。

圖1 實(shí)踐教學(xué)管理架構(gòu)模型

3.隱式接口及接口匹配問(wèn)題

把系統(tǒng)分為多個(gè)協(xié)作組件后會(huì)產(chǎn)生新的接口，這意味著簡(jiǎn)單的交叉變化可能需要改變?cè)S多組件，并需協(xié)調(diào)一起發(fā)布。在實(shí)際環(huán)境中，一個(gè)新品發(fā)布可能被迫同時(shí)發(fā)布大量服務(wù)，由于集成點(diǎn)的大量增加，微服務(wù)架構(gòu)會(huì)有更高的發(fā)布風(fēng)險(xiǎn)。

實(shí)踐教學(xué)管理平臺(tái)

微服務(wù)不需要像普通服務(wù)那樣成為一種獨(dú)立的功能或者獨(dú)立的資源。微服務(wù)是需要與業(yè)務(wù)能力相匹配，服務(wù)粒度越粗，就越難符合規(guī)定原則。服務(wù)粒度越細(xì)，就越能夠靈活地降低變化和負(fù)載所帶來(lái)的影響。其利弊之間的權(quán)衡過(guò)程是非常復(fù)雜的，在建設(shè)過(guò)程中，我們要綜合硬件配置和資金規(guī)模的基礎(chǔ)上考慮到基礎(chǔ)設(shè)施的成本問(wèn)題。

基于傳統(tǒng)的單體應(yīng)用開發(fā)模式面臨業(yè)務(wù)功能重復(fù)、共享融合不深，需求改變困難等問(wèn)題，結(jié)合微服務(wù)架構(gòu)的技術(shù)特點(diǎn)和優(yōu)劣勢(shì)，可以通過(guò)采用微處理結(jié)構(gòu)模式解決實(shí)踐教學(xué)管理的復(fù)雜的教學(xué)管理過(guò)程，不再是開發(fā)一個(gè)巨大的單體式的實(shí)踐教學(xué)管理系統(tǒng)，而是將整個(gè)系統(tǒng)分解為小的、互相連接的微服務(wù)應(yīng)用。參照微服務(wù)架構(gòu)模型結(jié)合實(shí)踐教學(xué)管理的需求，本文構(gòu)建的實(shí)踐教學(xué)管理架構(gòu)模型如圖1所示。

結(jié)構(gòu)模型

基于微服務(wù)架構(gòu)的實(shí)踐教學(xué)管理平臺(tái)整體分為左右兩部分，圖1虛線右側(cè)為實(shí)踐教學(xué)管理所涉及到的各個(gè)核心業(yè)務(wù)功能的技術(shù)實(shí)現(xiàn)，從技術(shù)上講，是以服務(wù)為抓手，在傳統(tǒng)的單體應(yīng)用基礎(chǔ)上將復(fù)雜的系統(tǒng)功能細(xì)化、拆分為一個(gè)個(gè)相互獨(dú)立、分散的功能點(diǎn)，且這些功能點(diǎn)是以微服務(wù)接口形式存在的。虛線右側(cè)是從用戶、角色的維度對(duì)右側(cè)的各個(gè)微服務(wù)接口進(jìn)行業(yè)務(wù)組合而形成的各級(jí)用戶、管理員的用戶UI端。UI端的形式可以是多樣的，既可以是PC形式也可以是移動(dòng)終端形式，還可以進(jìn)一步以WebAPI接口形式出現(xiàn)供其他第三方業(yè)務(wù)集成使用?？傮w而言，這些接口對(duì)于用戶來(lái)說(shuō)是透明的，用戶只需按照軟件功能設(shè)計(jì)在自己的UI下完成自己業(yè)務(wù)工作，而不用去管具體使用到哪些接口。

相關(guān)微服務(wù)接口

面向服務(wù)架構(gòu)思想、微服務(wù)架構(gòu)設(shè)計(jì)方法打破了傳統(tǒng)的大而全的整體設(shè)計(jì)思路，以解決業(yè)務(wù)需求為宗旨，圍繞業(yè)務(wù)領(lǐng)域組件來(lái)創(chuàng)建應(yīng)用，從而將傳統(tǒng)的單體應(yīng)用的實(shí)踐教學(xué)管理系統(tǒng)的核心業(yè)務(wù)功能按照微服務(wù)接口的方式，分解為實(shí)驗(yàn)項(xiàng)目管理接口、實(shí)驗(yàn)室管理接口、實(shí)驗(yàn)預(yù)約接口、實(shí)驗(yàn)考勤接口、實(shí)驗(yàn)登記接口、場(chǎng)館巡檢接口，每個(gè)接口之間相互獨(dú)立且只專注自己的業(yè)務(wù)功能。各接口通過(guò)相互調(diào)用、組合完成各類管理人員的工作業(yè)務(wù)系統(tǒng)模塊。如實(shí)驗(yàn)項(xiàng)目管理和實(shí)驗(yàn)室管理。首先，兩套微服務(wù)接口在開發(fā)實(shí)現(xiàn)階段各自只需要專注各自的業(yè)務(wù)功能需求，兩套接口相互獨(dú)立且隔離，同時(shí)實(shí)驗(yàn)項(xiàng)目管理中涉及到實(shí)驗(yàn)地點(diǎn)、實(shí)驗(yàn)設(shè)備、耗材等時(shí)都要使用到實(shí)驗(yàn)室管理的微服務(wù)接口。其次，無(wú)論是實(shí)驗(yàn)項(xiàng)目管理接口還是實(shí)驗(yàn)室管理接口，任何一個(gè)接口的功能變動(dòng)僅限于自己接口內(nèi)的程序變動(dòng)，不會(huì)牽涉到另一個(gè)接口去做相應(yīng)的調(diào)整。

技術(shù)優(yōu)勢(shì)

（1）區(qū)別于單體應(yīng)用，基于微服務(wù)架構(gòu)的實(shí)踐教學(xué)管理平臺(tái)各服務(wù)接口功能邊界清晰，且輕量級(jí)的確簡(jiǎn)化了程序設(shè)計(jì)人員的工作，能夠縮短項(xiàng)目實(shí)施周期，從而使得項(xiàng)目更具可行性。

（2）由于各個(gè)服務(wù)接口相互獨(dú)立，系統(tǒng)的故障僅限于服務(wù)接口內(nèi)部，僅是發(fā)生異常的服務(wù)接口不能運(yùn)行，不會(huì)影響到其他接口的正常運(yùn)行，同時(shí)，某服務(wù)接口的維護(hù)升級(jí)不會(huì)影響其他接口的運(yùn)行，相比于單體應(yīng)用程序更具備健壯性和可維護(hù)性。

（3）實(shí)踐教學(xué)管理相關(guān)微服務(wù)接口可以隨著學(xué)校的發(fā)展、教學(xué)管理的變革、管理的需要數(shù)量上不斷地?cái)U(kuò)展、功能上不斷地升級(jí)，有利于分段實(shí)施，逐步完善系統(tǒng)功能。

為常熟理工學(xué)院）