曹宏宇 胡恒

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

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

中圖分類號：TP311.13 文獻標志碼：A 文章編號：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)和遠程過程調(diào)用（RPC）用于終端軟件設(shè)計，并如何利用該模式解決容器和App之間信息交互的難題。

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

1.1 微服務(wù)簡介

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

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

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

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

單個微服務(wù)啟動較快。單個微服務(wù)代碼量較少，所以啟動會比較快。

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

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

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

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

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

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

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

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

1.2 微服務(wù)與容器

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

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

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

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

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

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

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

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

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

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

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

2.2 容器之間的通信

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

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

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

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

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

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

3 結(jié)束語

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

參考文獻：

[1]楊強，張鈞鳴.基于微服務(wù)架構(gòu)的大數(shù)據(jù)應(yīng)用開發(fā)創(chuàng)新實踐[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）.