基于微服务架构的智能终端软件架构探讨

曹宏宇 胡恒

摘 要：将低压配电侧集中器和智能配变终端两个设备进行融合，既是实现营配贯通业务需求、降低投资成本、提升台区运维效率的需要，也是支撑泛在电力物联网建设的一个重要手段。“软件定义终端”是实现终端融合的一种可行的方法。容器技术的出现，使一切皆软件的想法成为现实，也使得终端应用软件App化成为可能。但不可否认任何事物都具有两面性，应用软件容器化必然会导致终端软件变得越来越庞大和复杂，给整个软件系统的设计带来一些全新的挑战。传统的单点应用软件模式将难以适应未来智能终端的发展要求，因此应该重视新架构和新技术的引入。微服务（Microservices）是目前业界非常受欢迎的架构模式，企业和服务提供商正在寻找更好的方法将应用程序部署在基于容器的虚拟化云环境中，微服务被认为是未来的方向。

关键词：微服务；智能终端；集中器

中图分类号：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

引言

本文试图探讨将微服务架构和远程过程调用（RPC）用于终端软件设计，并如何利用该模式解决容器和App之间信息交互的难题。

1 微服务架构

1.1 微服务简介

作为一种全新的程序设计架构模式，微服务把一个整体应用程序拆分成多个小的服务，它们组成的一组服务可以相互协调，共同完成原有单一服务提供的功能。微服务架构中的每个组成服务都以独立进程的方式运行，而且构建时每个服务都对应具体的业务，不同服务间的通信开销是轻量级的。每个服务都可以单独部署，而且不推荐统一且集中的服务管理。在构建微服务架构的每个组成服务时，都需要根据其相关业务的上下文选择合适的语言和工具。

图1描述了典型的微服务架构。

采用微服务架构的主要优势有：

易于开发和维护。一个微服务只关注一个特定的业务功能，所以它的业务清晰、代码量较少。开发和维护单个微服务相对比较简单，整个应用是由若干个微服务构建而成，所以整个应用也会维持在可控状态；

单个微服务启动较快。单个微服务代码量较少，所以启动会比较快。

高可移植。微服务体量较小，功能较单一，这使得移植工作更容易。

易于测试。微服务依赖比较少，主要聚焦在功能測试，由于功能单一，代码对测试友好，无需过度测试。

局部修改容易部署。单体应用只要有修改，就要重新部署整个应用，微服务解决了这样的问题。一般来说，对某个微服务进行修改，只需要重新部署这个服务即可。

技术栈不受限。在微服务中，我们可以结合项目业务及团队的特点，合理地选择技术栈。

传统微服务架构的缺点主要包括：

需要较高的运维开销，提高了开发成本。和单体服务不同的是，传统的微服务架构在构建每个组成服务时，都需要完成构建、测试以及部署等工作，还需要单独的容器运行；如果要支持多语言环境的话会更加复杂。

存在隐式接口及接口匹配问题。虽然传统的微服务架构把单一服务进行拆分，实现了业务间的解耦合，但是多个服务间的协作需要新的接口，从而把原来的简单交互复杂化，在业务出现变更时可能需要统一协调发布。

增加了系统复杂性。微服务架构本质上是一种分布式系统，在提高了业务并发性的同时也带来了一定的复杂性和其他问题。例如，如果存在网络延迟，可能会导致数据不一致性，因此需要考虑容错机制。另外，还需要权衡异步机制、差异化版本带来的问题，开发人员还需要分析消息序列化、工作负载等在分布式系统上经常出现的问题。

1.2 微服务与容器

在容器技术出现之前，微服务通常需要独自或者共同部署在多台应用服务器或多个虚拟机上，微服务之间通过标准的通信接口实现访问。这样做的好处是当一个微服务出现问题时，并不会影响到其他的服务。而且，微服务可以基于资源的需求进行独立扩展，可以被部署在更小的主机上。各个微服务使用的开发语言也可以不同，只要保持接口协议统一。

然而，不容忽视的是，当微服务部署在多个主机上，大量微服务的管理也成为一个难题。另外，假如微服务是由不同程序语言开发的，那么实际部署时需要加载各自的库，從而增加了部署的复杂性，为了解决这一问题，容器技术应运而生。类似Docker容器技术等借助Namespaces及Cgroup等内核接口，实现了不同容器间的隔离；不同容器还可以共享同一内核。

目前流行的Linux容器主流方案是Docker和Rocket。Docker在实现时有一个libcontainer模块，此模块把相关的库程序、用户交互接口标准化；同时还为所有的容器镜像一个官方的资源库DockerHub。DockerHub类似于GitHub，简化了Docker容器共享和发布的流程。基于Docker的所有容器是部署在同一主机上的，因此避免了不同语言开发环境使用不同库文件的部署问题。另外，借助Docker的DockerFile还能够解决不同开发语言、不同框架以及不同库文件间的依赖性。

将微服务应用放置在容器中，带来了快速与可移植性。从开发、测试、上线，实现了“一次编写，到处运行”。

总之，通过容器、微服务的有效结合应用，最终帮助企业应用演进到互联网架构，实现IT投资和收益的最优化。

1.3 微服务之间的通信

微服务软件架构的一个重要的特点是采用轻量级的通信机制，目前主流的技术方案是使用远程过程调用 （Remote Procedure Call，RPC）。本质上讲，远程过程调用借助网络从远程计算机上请求服务，屏蔽了底层通信协议等网络细节。RPC协议构建于TCP或UDP，或者是HTTP上，允许开发者直接调用另一台服务器上的程序，而开发者无需另外的为这个调用过程编写网络通信相关代码，使得程序开发人员在开发网络分布式程序时可以更多关注业务实现，而较少的关注网络细节。远程过程调用实现时使用的是客户端-服务器端工作模式，是一种请求/响应式的通信技术，它使得我们可以像调用本地函数一样调用一个远程服务。在使用各类RPC风格的实现时，我们只要通过IDL定义好接口，通常能够自动生成客户端和服务端的代码，非常易于使用。

2 基于微服务的终端软件探讨

2.1 基于微服务的终端软件架构

以软件定义终端，所有终端的功能通过容器APP的方式实现，同时智能终端设计可裁剪的统一操作系统，屏蔽硬件的多样化差异，为所有终端提供底层运行环境。操作系统各层级间统一数据接口，使用容器技术对业务功能APP与底层系统的硬件资源做隔离，确保系统整体功能不受影响，同时可根据业务实际进行容器内APP资源权限合理分配，有效控制单一APP故障的影响范围。

使用微服务架构进行设计，将容器分为基础服务容器和高级业务容器。基础服务容器提供终端基础业务功能的抽象，如电表、电力物联网传感器、脉冲量和交采模拟量等数据的高频采集和存储，高级业务容器通过调用基础服务容器提供的服务接口，获取所需数据，从而实现高级业务功能如电能质量监测和分析等。

2.2 容器之间的通信

容器之间的通信方式是基于微服务架构的重要组成部分。经过广泛的调研和评估后，我们推荐采用gPRC框架。gRPC是Google公司基于HTTP/2协议标准设计的，其目的是面向移动应用市场，是目前主流的开源RPC框架。gRPC的通用性体现在支持ProtoBuf（Protocol Buffers） 序列化协议，并且支持多种开发语言；另外，为了提供健壮的客户端，gRPC借助一种简单的实现方式进行精确的服务定义，并且在此基础上自动生成后台支持服务的客户端库；这种健壮的客户端充分使用了高级流功能以及链接功能，能够在很大程度上降低TCP连接数目，从而提高了网络带宽的利用率。

gRPC具有的优势包括：

接口描述性强。由于定义服务时使用的是ProtoBuf数据序列化协议（和XML、JSON等序列化方式类似），因此gRPC可以支持数据的序列化操作，从而能够广泛应用于数据存储、通信协议等领域。

不同开发语言的支持。gRPC对主流的开发语言都支持，比如C/C++、JAVA、Go、Node.js、Python、Ruby、PHP和C#等，在GitHub中包括各个开发语言的gRPC实现。除了支持各种开发语言的实现外，gRPC还可以生成各类开发语言的服务端库文件以及客户端库文件。

支持HTTP/2标准。gRPC在设计之初就考虑了支持HTTP/2标准，因此和其他RPC框架相比，gRPC具备很多原生的功能，比如头部压缩、多复用请求等等。实际应用时如果使用了这些功能，会在很大程度上降低TCP连接数目，提高网络带宽的利用率，节省网络带宽；另外，还能够在一定程度上节省CPU使用、延长电池寿命。最重要的是，gRPC的分布式特性也能够提高Web应用在云端上的性能，从而以一种透明的方式实现客户端和服务器端的通信，并且在构建通信系统时得到大大的简化。

正是由于gRPC有如上优势，gRPC目前才可以应用在Google的云服务和对外提供的API中，包括Docker项目在内的主流开源项目都采用了gRPC框架。

3 结束语

容器作为一种轻量级虚拟化技术，可以更好的利用物理资源，降低系统开销。当前容器己经在虚拟化领域取得了一定成绩，各种基于容器技术的应用逐渐投入到生产环境中。可以预见容器技术会越来越普遍，而和容器关系紧密的微服务架构技术也将受益。面对传统终端软件设计中碰到的各种问题，容器化和微服务化无疑将是一种非常有意义的尝试。

参考文献：

[1]杨强，张钧鸣.基于微服务架构的大数据应用开发创新实践[J].电力大数据，2019，22（03）：71-76.

[2]李贞昊.微服务架构的发展与影响分析[J].信息系统工程，2017（01）.

[3]孙海洪.微服务架构和容器技术应用[J].金融电子化，2016（05）.