曹宏宇 胡恒

摘 要：將低壓配電側(cè)集中器和智能配變終端兩個(gè)設(shè)備進(jìn)行融合，既是實(shí)現(xiàn)營(yíng)配貫通業(yè)務(wù)需求、降低投資成本、提升臺(tái)區(qū)運(yùn)維效率的需要，也是支撐泛在電力物聯(lián)網(wǎng)建設(shè)的一個(gè)重要手段。“軟件定義終端”是實(shí)現(xiàn)終端融合的一種可行的方法。容器技術(shù)的出現(xiàn)，使一切皆軟件的想法成為現(xiàn)實(shí)，也使得終端應(yīng)用軟件App化成為可能。但不可否認(rèn)任何事物都具有兩面性，應(yīng)用軟件容器化必然會(huì)導(dǎo)致終端軟件變得越來(lái)越龐大和復(fù)雜，給整個(gè)軟件系統(tǒng)的設(shè)計(jì)帶來(lái)一些全新的挑戰(zhàn)。傳統(tǒng)的單點(diǎn)應(yīng)用軟件模式將難以適應(yīng)未來(lái)智能終端的發(fā)展要求，因此應(yīng)該重視新架構(gòu)和新技術(shù)的引入。微服務(wù)（Microservices）是目前業(yè)界非常受歡迎的架構(gòu)模式，企業(yè)和服務(wù)提供商正在尋找更好的方法將應(yīng)用程序部署在基于容器的虛擬化云環(huán)境中，微服務(wù)被認(rèn)為是未來(lái)的方向。

關(guān)鍵詞：微服務(wù)；智能終端；集中器

中圖分類號(hào)：TP311.13 文獻(xiàn)標(biāo)志碼：A 文章編號(hào)：2095-2945（2019）20-0017-03

Abstract： The integration of the low voltage distribution side concentrator and the intelligent distribution transformer terminal is not only the need to realize the business demand， reduce the investment cost and improve the operation and maintenance efficiency of the Taiwan area. It is also an important means to support the construction of ubiquitous power Internet of things. "Software defined terminal" is a feasible method to realize terminal fusion. The emergence of container technology not only makes the idea of everything software come true， but also makes it possible for terminal application software to be appraised. However， it is undeniable that everything has two sides， and the application software container will inevitably lead to the terminal software becoming more and more huge and complex， which brings some new challenges to the design of the whole software system. The traditional single-point application software model will be difficult to meet the requirements of the development of intelligent terminals in the future， so we should pay attention to the introduction of new architecture and new technology. Microservice is a very popular architecture pattern in the industry. Enterprises and service providers are looking for better ways to deploy applications in container-based virtual cloud environments. Microservice is considered to be the future trend.

Keywords： Microservices； intelligent terminal； concentrator

引言

本文試圖探討將微服務(wù)架構(gòu)和遠(yuǎn)程過(guò)程調(diào)用（RPC）用于終端軟件設(shè)計(jì)，并如何利用該模式解決容器和App之間信息交互的難題。

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

1.1 微服務(wù)簡(jiǎn)介

作為一種全新的程序設(shè)計(jì)架構(gòu)模式，微服務(wù)把一個(gè)整體應(yīng)用程序拆分成多個(gè)小的服務(wù)，它們組成的一組服務(wù)可以相互協(xié)調(diào)，共同完成原有單一服務(wù)提供的功能。微服務(wù)架構(gòu)中的每個(gè)組成服務(wù)都以獨(dú)立進(jìn)程的方式運(yùn)行，而且構(gòu)建時(shí)每個(gè)服務(wù)都對(duì)應(yīng)具體的業(yè)務(wù)，不同服務(wù)間的通信開(kāi)銷是輕量級(jí)的。每個(gè)服務(wù)都可以單獨(dú)部署，而且不推薦統(tǒng)一且集中的服務(wù)管理。在構(gòu)建微服務(wù)架構(gòu)的每個(gè)組成服務(wù)時(shí)，都需要根據(jù)其相關(guān)業(yè)務(wù)的上下文選擇合適的語(yǔ)言和工具。

圖1描述了典型的微服務(wù)架構(gòu)。

采用微服務(wù)架構(gòu)的主要優(yōu)勢(shì)有：

易于開(kāi)發(fā)和維護(hù)。一個(gè)微服務(wù)只關(guān)注一個(gè)特定的業(yè)務(wù)功能，所以它的業(yè)務(wù)清晰、代碼量較少。開(kāi)發(fā)和維護(hù)單個(gè)微服務(wù)相對(duì)比較簡(jiǎn)單，整個(gè)應(yīng)用是由若干個(gè)微服務(wù)構(gòu)建而成，所以整個(gè)應(yīng)用也會(huì)維持在可控狀態(tài)；

單個(gè)微服務(wù)啟動(dòng)較快。單個(gè)微服務(wù)代碼量較少，所以啟動(dòng)會(huì)比較快。

高可移植。微服務(wù)體量較小，功能較單一，這使得移植工作更容易。

易于測(cè)試。微服務(wù)依賴比較少，主要聚焦在功能測(cè)試，由于功能單一，代碼對(duì)測(cè)試友好，無(wú)需過(guò)度測(cè)試。

局部修改容易部署。單體應(yīng)用只要有修改，就要重新部署整個(gè)應(yīng)用，微服務(wù)解決了這樣的問(wèn)題。一般來(lái)說(shuō)，對(duì)某個(gè)微服務(wù)進(jìn)行修改，只需要重新部署這個(gè)服務(wù)即可。

技術(shù)棧不受限。在微服務(wù)中，我們可以結(jié)合項(xiàng)目業(yè)務(wù)及團(tuán)隊(duì)的特點(diǎn)，合理地選擇技術(shù)棧。

傳統(tǒng)微服務(wù)架構(gòu)的缺點(diǎn)主要包括：

需要較高的運(yùn)維開(kāi)銷，提高了開(kāi)發(fā)成本。和單體服務(wù)不同的是，傳統(tǒng)的微服務(wù)架構(gòu)在構(gòu)建每個(gè)組成服務(wù)時(shí)，都需要完成構(gòu)建、測(cè)試以及部署等工作，還需要單獨(dú)的容器運(yùn)行；如果要支持多語(yǔ)言環(huán)境的話會(huì)更加復(fù)雜。

存在隱式接口及接口匹配問(wèn)題。雖然傳統(tǒng)的微服務(wù)架構(gòu)把單一服務(wù)進(jìn)行拆分，實(shí)現(xiàn)了業(yè)務(wù)間的解耦合，但是多個(gè)服務(wù)間的協(xié)作需要新的接口，從而把原來(lái)的簡(jiǎn)單交互復(fù)雜化，在業(yè)務(wù)出現(xiàn)變更時(shí)可能需要統(tǒng)一協(xié)調(diào)發(fā)布。

增加了系統(tǒng)復(fù)雜性。微服務(wù)架構(gòu)本質(zhì)上是一種分布式系統(tǒng)，在提高了業(yè)務(wù)并發(fā)性的同時(shí)也帶來(lái)了一定的復(fù)雜性和其他問(wèn)題。例如，如果存在網(wǎng)絡(luò)延遲，可能會(huì)導(dǎo)致數(shù)據(jù)不一致性，因此需要考慮容錯(cuò)機(jī)制。另外，還需要權(quán)衡異步機(jī)制、差異化版本帶來(lái)的問(wèn)題，開(kāi)發(fā)人員還需要分析消息序列化、工作負(fù)載等在分布式系統(tǒng)上經(jīng)常出現(xiàn)的問(wèn)題。

1.2 微服務(wù)與容器

在容器技術(shù)出現(xiàn)之前，微服務(wù)通常需要獨(dú)自或者共同部署在多臺(tái)應(yīng)用服務(wù)器或多個(gè)虛擬機(jī)上，微服務(wù)之間通過(guò)標(biāo)準(zhǔn)的通信接口實(shí)現(xiàn)訪問(wèn)。這樣做的好處是當(dāng)一個(gè)微服務(wù)出現(xiàn)問(wèn)題時(shí)，并不會(huì)影響到其他的服務(wù)。而且，微服務(wù)可以基于資源的需求進(jìn)行獨(dú)立擴(kuò)展，可以被部署在更小的主機(jī)上。各個(gè)微服務(wù)使用的開(kāi)發(fā)語(yǔ)言也可以不同，只要保持接口協(xié)議統(tǒng)一。

然而，不容忽視的是，當(dāng)微服務(wù)部署在多個(gè)主機(jī)上，大量微服務(wù)的管理也成為一個(gè)難題。另外，假如微服務(wù)是由不同程序語(yǔ)言開(kāi)發(fā)的，那么實(shí)際部署時(shí)需要加載各自的庫(kù)，從而增加了部署的復(fù)雜性，為了解決這一問(wèn)題，容器技術(shù)應(yīng)運(yùn)而生。類似Docker容器技術(shù)等借助Namespaces及Cgroup等內(nèi)核接口，實(shí)現(xiàn)了不同容器間的隔離；不同容器還可以共享同一內(nèi)核。

目前流行的Linux容器主流方案是Docker和Rocket。Docker在實(shí)現(xiàn)時(shí)有一個(gè)libcontainer模塊，此模塊把相關(guān)的庫(kù)程序、用戶交互接口標(biāo)準(zhǔn)化；同時(shí)還為所有的容器鏡像一個(gè)官方的資源庫(kù)DockerHub。DockerHub類似于GitHub，簡(jiǎn)化了Docker容器共享和發(fā)布的流程?；贒ocker的所有容器是部署在同一主機(jī)上的，因此避免了不同語(yǔ)言開(kāi)發(fā)環(huán)境使用不同庫(kù)文件的部署問(wèn)題。另外，借助Docker的DockerFile還能夠解決不同開(kāi)發(fā)語(yǔ)言、不同框架以及不同庫(kù)文件間的依賴性。

將微服務(wù)應(yīng)用放置在容器中，帶來(lái)了快速與可移植性。從開(kāi)發(fā)、測(cè)試、上線，實(shí)現(xiàn)了“一次編寫(xiě)，到處運(yùn)行”。

總之，通過(guò)容器、微服務(wù)的有效結(jié)合應(yīng)用，最終幫助企業(yè)應(yīng)用演進(jìn)到互聯(lián)網(wǎng)架構(gòu)，實(shí)現(xiàn)IT投資和收益的最優(yōu)化。

1.3 微服務(wù)之間的通信

微服務(wù)軟件架構(gòu)的一個(gè)重要的特點(diǎn)是采用輕量級(jí)的通信機(jī)制，目前主流的技術(shù)方案是使用遠(yuǎn)程過(guò)程調(diào)用 （Remote Procedure Call，RPC）。本質(zhì)上講，遠(yuǎn)程過(guò)程調(diào)用借助網(wǎng)絡(luò)從遠(yuǎn)程計(jì)算機(jī)上請(qǐng)求服務(wù)，屏蔽了底層通信協(xié)議等網(wǎng)絡(luò)細(xì)節(jié)。RPC協(xié)議構(gòu)建于TCP或UDP，或者是HTTP上，允許開(kāi)發(fā)者直接調(diào)用另一臺(tái)服務(wù)器上的程序，而開(kāi)發(fā)者無(wú)需另外的為這個(gè)調(diào)用過(guò)程編寫(xiě)網(wǎng)絡(luò)通信相關(guān)代碼，使得程序開(kāi)發(fā)人員在開(kāi)發(fā)網(wǎng)絡(luò)分布式程序時(shí)可以更多關(guān)注業(yè)務(wù)實(shí)現(xiàn)，而較少的關(guān)注網(wǎng)絡(luò)細(xì)節(jié)。遠(yuǎn)程過(guò)程調(diào)用實(shí)現(xiàn)時(shí)使用的是客戶端-服務(wù)器端工作模式，是一種請(qǐng)求/響應(yīng)式的通信技術(shù)，它使得我們可以像調(diào)用本地函數(shù)一樣調(diào)用一個(gè)遠(yuǎn)程服務(wù)。在使用各類RPC風(fēng)格的實(shí)現(xiàn)時(shí)，我們只要通過(guò)IDL定義好接口，通常能夠自動(dòng)生成客戶端和服務(wù)端的代碼，非常易于使用。

2 基于微服務(wù)的終端軟件探討

2.1 基于微服務(wù)的終端軟件架構(gòu)

以軟件定義終端，所有終端的功能通過(guò)容器APP的方式實(shí)現(xiàn)，同時(shí)智能終端設(shè)計(jì)可裁剪的統(tǒng)一操作系統(tǒng)，屏蔽硬件的多樣化差異，為所有終端提供底層運(yùn)行環(huán)境。操作系統(tǒng)各層級(jí)間統(tǒng)一數(shù)據(jù)接口，使用容器技術(shù)對(duì)業(yè)務(wù)功能APP與底層系統(tǒng)的硬件資源做隔離，確保系統(tǒng)整體功能不受影響，同時(shí)可根據(jù)業(yè)務(wù)實(shí)際進(jìn)行容器內(nèi)APP資源權(quán)限合理分配，有效控制單一APP故障的影響范圍。

使用微服務(wù)架構(gòu)進(jìn)行設(shè)計(jì)，將容器分為基礎(chǔ)服務(wù)容器和高級(jí)業(yè)務(wù)容器?；A(chǔ)服務(wù)容器提供終端基礎(chǔ)業(yè)務(wù)功能的抽象，如電表、電力物聯(lián)網(wǎng)傳感器、脈沖量和交采模擬量等數(shù)據(jù)的高頻采集和存儲(chǔ)，高級(jí)業(yè)務(wù)容器通過(guò)調(diào)用基礎(chǔ)服務(wù)容器提供的服務(wù)接口，獲取所需數(shù)據(jù)，從而實(shí)現(xiàn)高級(jí)業(yè)務(wù)功能如電能質(zhì)量監(jiān)測(cè)和分析等。

2.2 容器之間的通信

容器之間的通信方式是基于微服務(wù)架構(gòu)的重要組成部分。經(jīng)過(guò)廣泛的調(diào)研和評(píng)估后，我們推薦采用gPRC框架。gRPC是Google公司基于HTTP/2協(xié)議標(biāo)準(zhǔn)設(shè)計(jì)的，其目的是面向移動(dòng)應(yīng)用市場(chǎng)，是目前主流的開(kāi)源RPC框架。gRPC的通用性體現(xiàn)在支持ProtoBuf（Protocol Buffers） 序列化協(xié)議，并且支持多種開(kāi)發(fā)語(yǔ)言；另外，為了提供健壯的客戶端，gRPC借助一種簡(jiǎn)單的實(shí)現(xiàn)方式進(jìn)行精確的服務(wù)定義，并且在此基礎(chǔ)上自動(dòng)生成后臺(tái)支持服務(wù)的客戶端庫(kù)；這種健壯的客戶端充分使用了高級(jí)流功能以及鏈接功能，能夠在很大程度上降低TCP連接數(shù)目，從而提高了網(wǎng)絡(luò)帶寬的利用率。

gRPC具有的優(yōu)勢(shì)包括：

接口描述性強(qiáng)。由于定義服務(wù)時(shí)使用的是ProtoBuf數(shù)據(jù)序列化協(xié)議（和XML、JSON等序列化方式類似），因此gRPC可以支持?jǐn)?shù)據(jù)的序列化操作，從而能夠廣泛應(yīng)用于數(shù)據(jù)存儲(chǔ)、通信協(xié)議等領(lǐng)域。

不同開(kāi)發(fā)語(yǔ)言的支持。gRPC對(duì)主流的開(kāi)發(fā)語(yǔ)言都支持，比如C/C++、JAVA、Go、Node.js、Python、Ruby、PHP和C#等，在GitHub中包括各個(gè)開(kāi)發(fā)語(yǔ)言的gRPC實(shí)現(xiàn)。除了支持各種開(kāi)發(fā)語(yǔ)言的實(shí)現(xiàn)外，gRPC還可以生成各類開(kāi)發(fā)語(yǔ)言的服務(wù)端庫(kù)文件以及客戶端庫(kù)文件。

支持HTTP/2標(biāo)準(zhǔn)。gRPC在設(shè)計(jì)之初就考慮了支持HTTP/2標(biāo)準(zhǔn)，因此和其他RPC框架相比，gRPC具備很多原生的功能，比如頭部壓縮、多復(fù)用請(qǐng)求等等。實(shí)際應(yīng)用時(shí)如果使用了這些功能，會(huì)在很大程度上降低TCP連接數(shù)目，提高網(wǎng)絡(luò)帶寬的利用率，節(jié)省網(wǎng)絡(luò)帶寬；另外，還能夠在一定程度上節(jié)省CPU使用、延長(zhǎng)電池壽命。最重要的是，gRPC的分布式特性也能夠提高Web應(yīng)用在云端上的性能，從而以一種透明的方式實(shí)現(xiàn)客戶端和服務(wù)器端的通信，并且在構(gòu)建通信系統(tǒng)時(shí)得到大大的簡(jiǎn)化。

正是由于gRPC有如上優(yōu)勢(shì)，gRPC目前才可以應(yīng)用在Google的云服務(wù)和對(duì)外提供的API中，包括Docker項(xiàng)目在內(nèi)的主流開(kāi)源項(xiàng)目都采用了gRPC框架。

3 結(jié)束語(yǔ)

容器作為一種輕量級(jí)虛擬化技術(shù)，可以更好的利用物理資源，降低系統(tǒng)開(kāi)銷。當(dāng)前容器己經(jīng)在虛擬化領(lǐng)域取得了一定成績(jī)，各種基于容器技術(shù)的應(yīng)用逐漸投入到生產(chǎn)環(huán)境中。可以預(yù)見(jiàn)容器技術(shù)會(huì)越來(lái)越普遍，而和容器關(guān)系緊密的微服務(wù)架構(gòu)技術(shù)也將受益。面對(duì)傳統(tǒng)終端軟件設(shè)計(jì)中碰到的各種問(wèn)題，容器化和微服務(wù)化無(wú)疑將是一種非常有意義的嘗試。

參考文獻(xiàn)：

[1]楊強(qiáng)，張鈞鳴.基于微服務(wù)架構(gòu)的大數(shù)據(jù)應(yīng)用開(kāi)發(fā)創(chuàng)新實(shí)踐[J].電力大數(shù)據(jù)，2019，22（03）：71-76.

[2]李貞昊.微服務(wù)架構(gòu)的發(fā)展與影響分析[J].信息系統(tǒng)工程，2017（01）.

[3]孫海洪.微服務(wù)架構(gòu)和容器技術(shù)應(yīng)用[J].金融電子化，2016（05）.