基于Thrift-Eureka改進(jìn)的微服務(wù)技術(shù)研究

趙媛心,王 毅,紀(jì)祖赑,趙俊翔,劉 萍

(北京臨近空間飛行器系統(tǒng)工程研究所，北京 100076)

0 引言

航天領(lǐng)域是國家安全基石的重要組成部分，是多學(xué)科綜合、多專業(yè)耦合、多領(lǐng)域覆蓋的系統(tǒng)工程，其中的型號軟件具有技術(shù)水平高、復(fù)雜度高、覆蓋范圍廣的特點。同時，組織也在發(fā)揮型號軟件中積攢的技術(shù)和管理優(yōu)勢，逐步擴(kuò)大產(chǎn)品化、市場化軟件的研制和推廣。隨著航天控制軟件規(guī)模越來越大，涉及的單位越來越多，分工也越來越細(xì)化。在這種場景下所有功能在一個軟件中編寫實現(xiàn)已經(jīng)不現(xiàn)實，多個系統(tǒng)、多個軟件配合使用已經(jīng)成為航天控制領(lǐng)域軟件的主要模式。隨之產(chǎn)生多系統(tǒng)、多軟件協(xié)同調(diào)用問題越來越突出，歸納起來有以下兩點：

1)調(diào)用方如何發(fā)現(xiàn)被調(diào)用方[7-8]；

2)被調(diào)用方啟用或者關(guān)閉如何通知調(diào)用方[9-10]。

目前常用的解決方法有以下兩種：

1)靜態(tài)配置。在數(shù)據(jù)庫或者文件中手動維護(hù)被調(diào)用方軟件地址列表。如果被調(diào)用方啟用或者關(guān)閉，則手動更新數(shù)據(jù)庫或者文件列表。調(diào)用方每次調(diào)用服務(wù)之前，首先讀取數(shù)據(jù)庫或者文件，然后再調(diào)用服務(wù)。

2)引入互聯(lián)網(wǎng)領(lǐng)域的微服務(wù)框架。分布式微服務(wù)框架[1-2]優(yōu)點在于：

(1)一個服務(wù)對應(yīng)一項業(yè)務(wù)能力，做到單一職責(zé)[11-12]；

(2)服務(wù)實現(xiàn)自動注冊和發(fā)現(xiàn)；

(3)服務(wù)之間相互獨立，可以實施不同的優(yōu)化方案[13]。

當(dāng)前互聯(lián)網(wǎng)領(lǐng)域比較流行的微服務(wù)框架[3]有Thrift-Eureka[1-2]和Dubbo[20]，這些微服務(wù)框架的核心原理和組件基本一致，組件包括客戶端[4](調(diào)用方軟件)、服務(wù)端(被調(diào)用方軟件)和注冊中心[5-6]，注冊中心的主要作用就是維護(hù)服務(wù)端列表，通過健康檢查[14-15]和消息通知[16]及時維護(hù)服務(wù)列表，目前比較常用的注冊中心是Zookeeper[17]。

但是這兩種方式在適配航天控制領(lǐng)域軟件都遇到了困難。靜態(tài)配置方式遇到的主要困難是每次軟件啟用、關(guān)閉都需要手動更新數(shù)據(jù)庫或者文件，這就給運維人員提出了很高的要求，尤其是調(diào)用關(guān)系復(fù)雜的情況下，如何及時正確地配置調(diào)用關(guān)系就成為了系統(tǒng)瓶頸。

互聯(lián)網(wǎng)領(lǐng)域軟件與航天控制領(lǐng)域軟件的一個重要區(qū)別是物理網(wǎng)絡(luò)隔離。Thrift-Eureka框架、Dubbo比較適用于互聯(lián)網(wǎng)領(lǐng)域，而不太適合航天控制領(lǐng)域，原因就在于這些框架依賴服務(wù)很多，部署復(fù)雜。通常航天控制軟件需要在多個區(qū)域部署試用，而且各個區(qū)域的網(wǎng)絡(luò)是物理隔離無法遠(yuǎn)程部署服務(wù)。如果需要匯報演示軟件，航天控制軟件自身部署需要1 h，但是微服務(wù)框架部署可能需要1 d。所以就需要結(jié)合互聯(lián)網(wǎng)領(lǐng)域微服務(wù)框架思想開發(fā)一套適用于航天控制軟件領(lǐng)域的微服務(wù)框架，其需要具備以下特點：1)易用性高；2)功能豐富；3)依賴項少，部署簡單。

1 Thrift-Eureka微服務(wù)架構(gòu)及原理

1.1 Thrift-Eureka框架介紹

Facebook作為全球10大巨頭互聯(lián)網(wǎng)公司之一，其內(nèi)部包含多套軟件系統(tǒng)。并且各個軟件系統(tǒng)使用的開發(fā)語言互不相同，部署環(huán)境互不相同。為了打通不同系統(tǒng)之間的信息壁壘，串聯(lián)各個信息孤島，構(gòu)建互聯(lián)互通的軟件系統(tǒng)，其開發(fā)了Thrift框架。在內(nèi)部穩(wěn)定運行一段時間后，F(xiàn)acebook于2007年將Thrift框架作為一個開源項目提交給了Apache基金會。由于創(chuàng)建Thrift框架的原由就是解決跨平臺通信問題，所以Thrift天生支持多種語言通信。既支持流行了很多年的開發(fā)語言C++、JAVA、C#等，也支持當(dāng)前正在流行的Erlang、Python、Ruby等。Thrift框架雖然在程序語言支持方面表現(xiàn)優(yōu)異，但是它的靜態(tài)編譯技術(shù)也常常被人詬病。Thrift框架需要先定義數(shù)據(jù)結(jié)構(gòu)，然后使用Thrift工具將數(shù)據(jù)結(jié)構(gòu)轉(zhuǎn)換成IDL文件。這就意味著，如果某個數(shù)據(jù)結(jié)構(gòu)發(fā)生了變化，必須重新編譯生成IDL文件，但是這個弱項并沒有阻礙Thrift成為流行的微服務(wù)通信框架。

完整的Thrift框架包括一個客戶端和一個服務(wù)端，首先用戶需要自定義數(shù)據(jù)結(jié)構(gòu)，然后使用Thrift工具自動生成客戶端和服務(wù)端代碼，并且自動生成的代碼中包含接口協(xié)議字段，以便客戶端與服務(wù)端進(jìn)行通信。在通信過程中Thrift會將數(shù)據(jù)信息轉(zhuǎn)換成高效的二進(jìn)制字節(jié)來提高傳輸效率。服務(wù)器端會利用底層多線程、阻塞或者非阻塞協(xié)議來接收數(shù)據(jù)。具體采用哪種協(xié)議基于操作系統(tǒng)不同而不同。

通過上面介紹可以發(fā)現(xiàn)Thrift框架是客戶端與服務(wù)端直接通信的，這就會導(dǎo)致以下問題。

1)服務(wù)的端口或者IP發(fā)生變化，調(diào)用方需要手動修改IP或端口；

2)新啟服務(wù)無法實現(xiàn)動態(tài)發(fā)現(xiàn)；

3)服務(wù)之間調(diào)用關(guān)系錯綜復(fù)雜，難以維護(hù)。

針對以上缺點互聯(lián)網(wǎng)領(lǐng)域通常將Thrift與Eureka配合使用。Eureka是Netflix開發(fā)的服務(wù)發(fā)現(xiàn)框架，本身是一個基于REST的服務(wù)，以達(dá)到負(fù)載均衡和中間層服務(wù)故障轉(zhuǎn)移的目的。

Eureka是Netflix開發(fā)的服務(wù)發(fā)現(xiàn)框架，其有兩部分構(gòu)成，即服務(wù)端和客戶端。服務(wù)端主要提供用戶服務(wù)注冊功能與更新功能，即用戶服務(wù)啟動之后，會將自身服務(wù)信息注冊到Eureka的服務(wù)端中。每隔30 s用戶服務(wù)節(jié)點會發(fā)一次心跳到Eureka的服務(wù)端中，如果Eureka服務(wù)端連續(xù)多個心跳周期(一般為3個周期)都沒有收到某個服務(wù)節(jié)點的心跳，那么Eureka服務(wù)端就認(rèn)為該服務(wù)節(jié)點不可用，然后將其剔除。通過這樣的機(jī)制Eureka的服務(wù)端就可以總覽所有服務(wù)節(jié)點信息，并且快速識別可用的服務(wù)列表。Eureka客戶端主要提供服務(wù)訂閱功能和與服務(wù)端的連接封裝管理功能。即利用Eureka客戶端上層應(yīng)用可以使用服務(wù)名稱與其他應(yīng)用進(jìn)行通信，而不用通過配置IP與其他應(yīng)用進(jìn)行通信。Eureka客戶端還內(nèi)置了輪詢算法來實現(xiàn)負(fù)載均衡功能。Thrift-Eureka微服務(wù)框架如圖1所示。

圖1 Thrift-Eureka微服務(wù)框架圖

由圖2所示，Thrift-Eureka框架的調(diào)用邏輯分為以下幾步：

圖2 Thrift-Eureka框架調(diào)用圖

1)在注冊中心中配置服務(wù)端名稱，在客戶端中配置其需要訂閱的服務(wù)名稱；

2)服務(wù)啟動之后，服務(wù)端將本地IP和服務(wù)信息發(fā)送給注冊中心；

3)注冊中心將服務(wù)端IP和服務(wù)發(fā)送給客戶端；

4)客戶端基于注冊中心發(fā)來的消息，調(diào)用服務(wù)端的接口。

1.2 Dubbo框架介紹

Dubbo 最早誕生于阿里巴巴，隨后加入 Apache 軟件基金會，項目從設(shè)計之初就是為了解決企業(yè)的服務(wù)化問題，因此充分考慮了大規(guī)模集群場景下的服務(wù)開發(fā)與治理問題，如易用性、性能、流量管理、集群可伸縮性等。在Dubbo開源的將近10年時間內(nèi)，Dubbo幾乎成為了國內(nèi)微服務(wù)框架的首選框架，尤其受到大規(guī)?；ヂ?lián)網(wǎng)、IT企業(yè)的認(rèn)可，可以說作為開源服務(wù)框架，Dubbo在支持微服務(wù)集群方面有著非常大的規(guī)模與非常久的實踐經(jīng)驗積累，是最具有企業(yè)規(guī)模化微服務(wù)實踐話語權(quán)的框架之一。采用Dubbo的企業(yè)涵蓋互聯(lián)網(wǎng)、傳統(tǒng)IT、金融、生產(chǎn)制造業(yè)多個領(lǐng)域，一些典型用戶包括阿里巴巴、攜程、工商銀行、中國人壽、海爾、金蝶等。

Dubbo作為一款微服務(wù)開發(fā)框架，它提供了遠(yuǎn)程服務(wù)調(diào)用與微服務(wù)治理兩大關(guān)鍵能力。利用Dubbo提供的豐富服務(wù)治理能力，可以實現(xiàn)諸如服務(wù)發(fā)現(xiàn)、負(fù)載均衡、流量調(diào)度等服務(wù)治理訴求。同時Dubbo是高度可擴(kuò)展的，用戶幾乎可以在任意功能點去定制自己的實現(xiàn)，以改變框架的默認(rèn)行為來滿足自己的業(yè)務(wù)需求，Dubbo框架如圖3所示。

自開源以來，Dubbo 就被一眾大規(guī)模互聯(lián)網(wǎng)、IT公司選型，經(jīng)過多年企業(yè)實踐積累了大量經(jīng)驗。因此，Dubbo 在解決業(yè)務(wù)落地與規(guī)模化實踐方面有著無可比擬的優(yōu)勢：

1)易用性高，如 Java 版本的面向接口代理特性能實現(xiàn)本地透明調(diào)用；

2)功能豐富，基于原生庫或輕量擴(kuò)展即可實現(xiàn)絕大多數(shù)的微服務(wù)治理能力；

3)高性能的跨進(jìn)程通信協(xié)議；

4)地址發(fā)現(xiàn)、流量治理層面，輕松支持百萬規(guī)模集群實例。

Dubbo 提供了從服務(wù)定義、服務(wù)發(fā)現(xiàn)、服務(wù)通信到流量管控等幾乎所有的服務(wù)治理能力，并且嘗試從使用上對用戶屏蔽底層細(xì)節(jié)，以提供更好的易用性。定義服務(wù)在 Dubbo 中非常簡單與直觀，可以選擇使用與某種語言綁定的方式(如Java中可直接定義Interface)，也可以使用Protobuf IDL語言中立的方式。無論選擇哪種方式，站在服務(wù)消費方的視角，都可以通過 Dubbo 提供的透明代理直接編碼。

點對點的服務(wù)通信是Dubbo提供的一項基本能力，Dubbo以遠(yuǎn)程服務(wù)調(diào)用的方式將請求數(shù)據(jù)(Request)發(fā)送給后端服務(wù)，并接收服務(wù)端返回的計算結(jié)果(Response)。遠(yuǎn)程服務(wù)調(diào)用對用戶來說是完全透明的，使用者無需關(guān)心請求是如何發(fā)出去的、發(fā)到了哪里，每次調(diào)用只需要拿到正確的調(diào)用結(jié)果就行。同步的Request-Response是默認(rèn)的通信模型，它最簡單但卻不能覆蓋所有的場景，因此，Dubbo 提供更豐富的通信模型：

1)客戶端異步請求(Client Side Asynchronous Request-Response);

2)服務(wù)端異步執(zhí)行(Server Side Asynchronous Request-Response);

3)客戶端請求流(Request Streaming);

4)服務(wù)端響應(yīng)流(Response Streaming);

5)雙向流式通信(Bidirectional Streaming)。

Dubbo的服務(wù)發(fā)現(xiàn)機(jī)制，讓微服務(wù)組件之間可以獨立演進(jìn)并任意部署，客戶端可以在無需感知對端部署位置與 IP 地址的情況下完成通信。Dubbo 提供的是 Client-Based 的服務(wù)發(fā)現(xiàn)機(jī)制，使用者可以使用Zookeeper作為服務(wù)發(fā)現(xiàn)組件。

Dubbo 提供了包括負(fù)載均衡、流量路由、請求超時、流量降級、重試等策略，基于這些基礎(chǔ)能力可以輕松的實現(xiàn)更多場景化的路由方案，包括金絲雀發(fā)布、A/B測試、權(quán)重路由、同區(qū)域優(yōu)先等。Dubbo 強(qiáng)大的服務(wù)治理能力不僅體現(xiàn)在核心框架上，還包括其優(yōu)秀的擴(kuò)展能力以及周邊配套設(shè)施的支持。

1.3 Thrift-Eureka框架與Dubbo框架對比

Thrift-Eureka需要使用API(接口定義語言)定義一個文件，然后通過Thrift來生成對應(yīng)的各種語言的代碼，服務(wù)的提供者和消費者都需要把這個代碼引入進(jìn)去，服務(wù)端負(fù)責(zé)接口的實現(xiàn)，消費者使用API的存根去直接調(diào)用提供者。目前Thrift-Eureka支持的語言比較多，比如常見的C++、Java、Python、Ruby、C#、PHP等。Thrift屬于C/S模式，它通過代碼生成工具將接口定義的文件生成服務(wù)器端和客戶端的代碼，當(dāng)然，服務(wù)端和客戶端可以是不同語言的，從而實現(xiàn)了客戶端和服務(wù)端之間跨語言的支持。傳輸?shù)男蛄谢仓С趾芏喾N，比如：二進(jìn)制模式、壓縮模式、JSON模式以及Debug模式，可以在開發(fā)的過程中使用Debug模式和JSON模式來方便的看到傳輸?shù)臄?shù)據(jù)，在正式環(huán)境使用二進(jìn)制模式或壓縮模式來提升性能。在通訊模式上也支持很多種，它支持阻塞的I/O和NIO，還有專門用來傳輸文件的傳輸方式。在線程模型上，它也支持很多種，比如簡單的單線程模式、線程池模式、多線程使用非阻塞I/O模式。這樣可以在不同的業(yè)務(wù)場景中使用更適合的技術(shù)來實現(xiàn)微服務(wù)調(diào)用。Thrift并沒有服務(wù)治理相關(guān)的功能，消費者只能使用服務(wù)提供者IP和端口號來進(jìn)行訪問，而Eureka具有服務(wù)注冊與發(fā)現(xiàn)功能，需要將Thrift和Eureka配合使用，來作為一個完整的微服務(wù)框架。

Dubbo的消費者和提供者以及注冊中心之間使用的是長連接，服務(wù)的消費者和提供者會在內(nèi)存中累計服務(wù)調(diào)用的次數(shù)，并且定時將調(diào)用的信息發(fā)送到監(jiān)控中心；消費者和提供者之間通信采用的是非阻塞I/O(即NIO)；Dubbo的序列化使用的是阿里修改過的hession序列化方式，Dubbo是基于Java來進(jìn)行開發(fā)的，所以也支持java的客戶端和服務(wù)端。Dubbo具備完善的服務(wù)注冊、服務(wù)訂閱、通知以及監(jiān)控功能。

總體而言，Dubbo作為一個完善的微服務(wù)框架，具備豐富的工具。但是它的缺點在于只支持Java語言。Thrift-Eureka搭配使用也能作為一個完善的微服務(wù)框架，其具備的工具集合滿足航天型號軟件使用需求，而且其支持的語言非常豐富。綜合比較下來，系統(tǒng)選擇改造Thrift-Eureka微服務(wù)框架來適配航天型號軟件。

2 Thrift-Eureka改進(jìn)的微服務(wù)架構(gòu)

結(jié)合引言中介紹的航天型號軟件使用場景，即經(jīng)常需要在不同場地進(jìn)行試用，并且各個場地之間網(wǎng)絡(luò)不通。如果型號軟件部署需要1小時，但是微服務(wù)框架部署需要1天，那就是本末倒置了。針對這種情況，微服務(wù)框架改造的重點在于不增加使用難度的情況下，縮短部署時間。

2.1 含有數(shù)據(jù)庫的航天型號系統(tǒng)

結(jié)合上文中提到的改造目標(biāo)，如果能夠?qū)⒆灾行暮捅O(jiān)控中心的功能進(jìn)行轉(zhuǎn)移，并且將客戶端軟件和服務(wù)端軟件做成依賴包的形式嵌入型號軟件中，那么就達(dá)到了在不增加使用難度的情況下，減少部署時間的目標(biāo)。目前Thrift-Eureka的客戶端軟件和服務(wù)端軟件可以作為依賴包嵌入型號軟件。再分析一下注冊中心和監(jiān)控中心的功能，注冊中心的功能主要是服務(wù)注冊、服務(wù)更新通知和服務(wù)發(fā)現(xiàn)，監(jiān)控中心的主要功能是客戶端指標(biāo)收集和服務(wù)端指標(biāo)收集。

1)服務(wù)注冊：服務(wù)提供方將自身服務(wù)地址寫入注冊中心；

2)服務(wù)更新通知：當(dāng)服務(wù)提供方IP或者端口發(fā)生變化后，及時通知客戶端更新服務(wù)列表；

3)服務(wù)發(fā)現(xiàn)：客戶端讀取注冊中心中的服務(wù)列表；

4)客戶端指標(biāo)收集：客戶端將調(diào)用成功次數(shù)、失敗次數(shù)及耗時情況寫入監(jiān)控中心；

5)服務(wù)端指標(biāo)收集：服務(wù)端將調(diào)用成功次數(shù)、失敗次數(shù)及耗時情況寫入監(jiān)控中心。

在原有數(shù)據(jù)庫的基礎(chǔ)上增加兩張數(shù)據(jù)庫表，就可以來承載注冊中心和監(jiān)控中心的職責(zé)，如圖4所示。

圖4 包含數(shù)據(jù)庫型號軟件微服務(wù)框架

根據(jù)圖4可知，包含數(shù)據(jù)庫的型號軟件微服務(wù)架構(gòu)原理概述如下：

首先在原有數(shù)據(jù)庫的基礎(chǔ)上增加兩張表，分別為服務(wù)注冊表和服務(wù)健康統(tǒng)計表。服務(wù)注冊表主要包括服務(wù)提供方IP、端口、最近更新時間。服務(wù)健康統(tǒng)計表主要包括機(jī)器IP、端口、服務(wù)名稱、調(diào)用次數(shù)、失敗次數(shù)、類型(服務(wù)端、客戶端)等。

然后修改服務(wù)端的服務(wù)注冊邏輯，每隔30 s更新一次服務(wù)注冊表中的服務(wù)信息。

再次在原有客戶端的基礎(chǔ)上，基于guava的Localcache構(gòu)建一套本地緩存，每隔30 s從數(shù)據(jù)庫中獲取一次服務(wù)提供方列表，并且將更新時間超過90 s的服務(wù)剔除。并且基于客戶端緩存的服務(wù)列表來實現(xiàn)負(fù)載均衡、流量路由、重試等策略等功能。

最后客戶端和服務(wù)端都將服務(wù)統(tǒng)計數(shù)據(jù)上傳到服務(wù)健康統(tǒng)計表中。

對照Thrift-Eureka的注冊中心和監(jiān)控中心，重新梳理了以下功能：

1)服務(wù)注冊：服務(wù)提供方每隔30 s將自身服務(wù)地址和服務(wù)器時間更新到服務(wù)注冊表；

2)服務(wù)更新通知：客戶端通過本地緩存每隔30 s拉取一次服務(wù)注冊表信息，來達(dá)到服務(wù)更新通知的目標(biāo)；

3)服務(wù)發(fā)現(xiàn)：客戶端讀取本地緩存的服務(wù)列表；

4)客戶端指標(biāo)收集：客戶端將調(diào)用成功次數(shù)、失敗次數(shù)及耗時情況寫入服務(wù)健康統(tǒng)計表；

5)服務(wù)端指標(biāo)收集：服務(wù)端將調(diào)用成功次數(shù)、失敗次數(shù)及耗時情況寫入服務(wù)健康統(tǒng)計表。

2.2 不包含數(shù)據(jù)庫的航天型號系統(tǒng)

上一章節(jié)介紹了如何基于數(shù)據(jù)庫改造Thrift-Eureka，下面介紹不利用數(shù)據(jù)庫改造微服務(wù)框架的方法。即可以通過服務(wù)端發(fā)送廣播本地服務(wù)消息的方式來實現(xiàn)注冊中心的功能，客戶端發(fā)送廣播獲取服務(wù)消息的方式來實現(xiàn)服務(wù)發(fā)現(xiàn)的功能，如圖5所示。

圖5 不包含數(shù)據(jù)庫型號軟件微服務(wù)框架

根據(jù)圖5所示，不包含數(shù)據(jù)庫的微服務(wù)架構(gòu)原理概述如下：首先服務(wù)端啟動之后，在局域網(wǎng)內(nèi)廣播本地服務(wù)地址和服務(wù)信息，其他服務(wù)器收到消息之后，判斷該消息包含的服務(wù)信息是否是自己訂閱的。如果是自己訂閱的，則更新本地服務(wù)列表。如果不是自己訂閱的，則忽略這條廣播消息。然后服務(wù)端每隔3 min廣播一次本地服務(wù)地址和服務(wù)消息，其他服務(wù)器收到消息后處理邏輯與第一次收到消息處理邏輯一致。

然后客戶端啟動，在局域網(wǎng)內(nèi)廣播自己需要的服務(wù)地址，其他服務(wù)器收到消息之后，判斷該消息包含的服務(wù)信息是否是自己提供的。如果是自己提供的，則將本地服務(wù)地址和服務(wù)信息發(fā)送給客戶端。如果不是自己提供的，則忽略這條廣播消息。

再次在原有客戶端的基礎(chǔ)上，基于guava的Localcache構(gòu)建一套本地緩存，主要存儲服務(wù)地址和服務(wù)更新時間，并且將更新時間超過3 min的服務(wù)剔除。并且基于客戶端緩存的服務(wù)列表來實現(xiàn)負(fù)載均衡、流量路由、重試等策略等功能。

最后客戶端和服務(wù)端都將服務(wù)統(tǒng)計數(shù)據(jù)存儲到本地日志中，方便后續(xù)定位分析問題。

對照Thrift-Eureka的注冊中心，重新梳理了以下功能：

1)服務(wù)注冊：服務(wù)提供方啟動之后將自身服務(wù)地址和服務(wù)器時間廣播給局域網(wǎng)內(nèi)其他機(jī)器；

2)服務(wù)更新通知：服務(wù)提供方每隔3 min將自身服務(wù)地址和服務(wù)器時間廣播給局域網(wǎng)內(nèi)其他機(jī)器；

3)服務(wù)發(fā)現(xiàn)：客戶端讀取本地緩存的服務(wù)列表。如果本地緩存列表為空，則廣播發(fā)送獲取服務(wù)消息。

2.3 航天型號系統(tǒng)微服務(wù)框架使用模式

基于上述章節(jié)，航天型號系統(tǒng)微服務(wù)框架內(nèi)置了兩套使用模式。模式一針對包含數(shù)據(jù)庫的型號系統(tǒng)，它具有可靠性高、問題排查方便的特點。模式二針對不包含數(shù)據(jù)庫的型號系統(tǒng)，它具有依賴少，使用范圍廣泛的特點。系統(tǒng)會判斷用戶是否設(shè)置了使用模式，如果用戶有自定義設(shè)置，則按照用戶要求來使用系統(tǒng)。否則按照如下步驟自動啟動框架。

2.3.1 連接數(shù)據(jù)庫

判斷數(shù)據(jù)庫能否連接成功，如果能連接成功，則跳轉(zhuǎn)步驟2)。否則使用廣播模式，如下所示：

1)服務(wù)端廣播服務(wù)信息:服務(wù)端每隔3 min將本地服務(wù)信息廣播給局域網(wǎng)內(nèi)其他機(jī)器。

2)客戶端獲取服務(wù)信息:客戶端判斷本地緩存的服務(wù)列表是否為空，為空則廣播發(fā)送獲取服務(wù)消息。

2.3.2 創(chuàng)建服務(wù)注冊表

判斷數(shù)據(jù)庫中是否已經(jīng)存在服務(wù)注冊表。如果存在，則跳過。否則創(chuàng)建服務(wù)注冊表。

2.3.3 服務(wù)端每隔30 s更新服務(wù)注冊信息

服務(wù)端每隔30 s將本地服務(wù)地址和服務(wù)器時間更新到服務(wù)注冊表中。

2.3.4 客戶端每隔30 s拉取服務(wù)注冊信息

客戶端每隔30 s從服務(wù)注冊表中拉取服務(wù)信息，并更新本地緩存。

通過上述步驟可以得出，系統(tǒng)默認(rèn)優(yōu)先使用數(shù)據(jù)庫模式，在數(shù)據(jù)庫無法連接的情況則使用廣播模式。

3 試驗結(jié)果與分析

Thrift-Eureka改進(jìn)的微服務(wù)架構(gòu)主要解決的是航天型號軟件部署維護(hù)復(fù)雜的問題，為此設(shè)計了對照實驗來比較原型Thrift-Eureka框架和改進(jìn)的Thrift-Eureka框架的部署耗時。首先針對某航天型號軟件A，分別使用Thrift-Eureka框架構(gòu)建系統(tǒng)B，使用改進(jìn)的Thrift-Eureka框架構(gòu)建系統(tǒng)C。

從開發(fā)組、測試組和運維組總共抽取了45名同事，將這45名同事隨機(jī)分成5個隊，每隊9人，包括3名開發(fā)、3名測試和3名運維同事。

每隊需要同時部署系統(tǒng)A、系統(tǒng)B和系統(tǒng)C。耗時情況如表1所示。

表1 系統(tǒng)部署耗時比較 s

從表1中可以看出部署系統(tǒng)A和系統(tǒng)C的耗時基本相同，這符合實驗預(yù)期。因為改進(jìn)的Thrift-Eureka框架構(gòu)不需要額外部署軟件，實驗隊員部署系統(tǒng)A和系統(tǒng)C的步驟基本相同。但是部署系統(tǒng)B的耗時明顯增加，這是因為除了部署基礎(chǔ)的型號系統(tǒng)A之外，還需要部署配置Thrift-Eureka框架。

4 結(jié)束語

首先介紹了航天型號軟件開發(fā)框架遇到的問題，分析了航天型號垂直應(yīng)用框架和微服務(wù)框架的優(yōu)缺點，著重介紹了目前互聯(lián)網(wǎng)領(lǐng)域流行的微服務(wù)框架Thrift-Eureka和Dubbo。接著描述了互聯(lián)網(wǎng)領(lǐng)域的微服務(wù)框架適配航天型號軟件領(lǐng)域遇到的問題。然后基于微服務(wù)框架思想和Dubbo微服務(wù)框架，提出了一種適用于航天型號軟件領(lǐng)域的微服務(wù)框架。該服務(wù)框架有兩種使用模式：一種適用于包含數(shù)據(jù)庫的型號軟件系統(tǒng)；另一種適用于不包含數(shù)據(jù)庫的型號軟件系統(tǒng)。針對有數(shù)據(jù)庫的型號軟件系統(tǒng)，利用數(shù)據(jù)庫系統(tǒng)來實現(xiàn)微服務(wù)框架的注冊中心功能。針對沒有數(shù)據(jù)庫的型號軟件系統(tǒng)，利用廣播協(xié)議、本地日志來實現(xiàn)微服務(wù)框架注冊中心功能。經(jīng)在某項目中實踐后可見，該方案能夠?qū)嶋H解決航天型號軟件微服務(wù)框架使用的問題。