微服务在智慧城市平台建设中的应用初探

向逸尘　林浩宇　徐源

摘   要：我国目前对智慧城市建设的投入越来越大，各类平台软件层出不穷，但各种问题也随之涌现，如何彻底消除信息孤岛，形成真正的信息互联互通，仍然是需要进行进一步研究的。在这种背景下，通过分析智慧城市建设的现状，介绍了微服务设计理念，给出了微服务在软件平台建设中进行应用的实现方式，最后对微服务的优势与劣势进行了探讨。

关键词：微服务;智慧城市;系统集成;服务注册;服务发现

中图分类号：TP311 文献标识码：A

Abstract：At present，China's investment in the construction of smart cities is increasing，and various kinds of platform software emerge in an endless stream，but a variety of problems also emerge. How to completely eliminate the information isolated island and form a real information interconnection and interoperability still needs further study.Against this background，this paper analyses the current situation of smart city construction，introduces the concept of micro-service design，gives the implementation method of micro-service application in software platform construction，and finally discusses the advantages and disadvantages of micro-service.

Key words：micro-service;smart city;system integration;service registration;service discovery

智慧城市是数字城市更高级别的体现，旨在利用各类信息技术或创新技术，集成城市的各类系统和服务，提升资源运用的效率，优化城市基础管理和市政基础服务，从而最终达到改善市民生活质量的目标。在当今的互联网经济时代，城市智能化已经成为了衡量城市综合实力和城市文明程度的一個重要指标。从国家第十二个五年计划开始，智慧城市建设已经成为我国的一项基本政策。

据了解，到目前为止，全国各地已经建设成了非常多的智慧城市相关软件平台，这些软件平台的统一目标是消除所谓的“信息孤岛”，实现数据互通共享。但是随着时间的推移，会发现这些平台软件只是消除了小的“信息孤岛”，然后形成了更大的“信息孤岛”，每个平台都有自己的编程语言，有自己的通信规则，平台与平台之间，又缺乏有效的数据互通手段，导致政府各级部门之间的信息仍然显得闭塞，无法畅通。

针对这种情况，结合微服务设计理念，提出了彻底解决智慧城市“信息孤岛”的一种设计思路。

1   微服务概述

所谓的微服务，其实是软件系统在架构方面的一种设计理念，是一种架构思想。其主要的目标是把本来相对独立的一个大的系统拆分成若干个小型的服务，拆分出的这些小型服务全部在相互独立的进程中运行，每个微服务都会围绕着系统中一些耦合度较高的业务功能进行搭建，每个服务都需要维护自身的数据存储、业务以及自动化测试案例，并需具备独立部署的能力。由于有了轻量级的通信协作基础，所以所有微服务都可以使用不同的语言来编写，充分支持不同平台、不同系统、不同服务的有效互联互通。微服务的总体架构如图1所示。

微服务架构思想有很多优点，最大的优点就是易于开发、维护。每一个微服务都只用关注某一个特定的业务逻辑，所以每一个微服务的业务非常清晰、代码量很少[1]。由于整个应用是由若干个微服务构建而成的，所以整个应用也被维持在一个可控状态。因为拆分之后的单个微服务代码量比较少，所以启动速度相对来说会比较快。单个应用若是面临修改，整个应用都要重新部署，而对某个微服务进行修改，则只用重新部署这个服务即可。

其次，微服务架构的过程中，还可以根据具体的项目业务以及团队人员的特点，合理的选择技术栈，不同的需求都能使用最合适工具和技术，使得整个系统更加高效与流畅。最后，还可以根据需求的变化，实现细粒度的扩展，当某个微服务遇到瓶颈时，就可以有的放矢的针对问题来增加内存，升级CPU或者增加节点，在节约成本资源的情况下完美的解决问题[2]。

最后，高效的可扩展性也是微服务的一大优点，微服务通过注册中心对所有服务进行管理，可以通过HTTP（S）、RPC、gRPC等多种方式接入任意语言、任意平台的服务，非常适合智慧城市领域的应用扩展。对于已经建设完毕的外部系统来说，只要按照一定的规则进行好约定，就可以方便的接入微服务架构的系统中，实现完全的数据共享和互通，从而实现微服务的高扩展性。

2   微服务的框架搭建

介绍的微服务主要使用Java SpringCloud框架进行搭建。SpringCloud是基于SpringBoot的一整套实现微服务的框架。他提供了微服务开发所需要的各种配置管理、服务发现、断路器、智能路由等组件。

2.1   注册中心

注册中心是微服务的核心，是微服务的心脏，一切服务都通过注册中心进行交互。本文使用的服务注册中心是Eureka，可以实现服务的注册与发现，它满足了分布式基本定理（CAP定理）中的AP原则[3]，即高可用性与分区容错性，在它的实现中，节点之间是相互平等的，即使部分注册中心的节点挂掉也不会对集群造成影响，哪怕集群只剩一个节点存活，也可以正常提供发现服务。

Eureka的架构如图2所示。

服务启动后向Eureka注册，Eureka Server会将注册信息向其他Eureka Server进行同步，当服务消费者要调用服务提供者，则向服务注册中心获取服务提供者地址，然后会将服务提供者地址缓存在本地，下次再调用时，则直接从本地缓存中取，完成一次调用。

当服务注册中心Eureka Server检测到服务提供者因为宕机、网络原因不可用时，则在服务注册中心将服务置为DOWN状态，并把当前服务提供者状态向订阅者发布，订阅过的服务消费者更新本地缓存。

服务提供者在启动后，周期性（默认30秒）向Eureka Server发送心跳，以证明当前服务是可用状态。Eureka Server在一定的时间（默认90秒）未收到客户端的心跳，则认为服务宕机，注销该实例。

注册中心的启动类需要打上一个开启Eureka Server的注解@EnableEurekaServer，这个注解则包含了包括@ComponentScan，@SpringBootConfiguration和@EnableAutoConfiguration三个注解，是SpringBoot的通用启动注解。

注册中心的xml配置文件则需要配置注册中心运行的端口号、配置注册中心的主机名、配置是否向注册中心注册自己、配置是否检索服务还有配置是否关闭Eureka的保护机制等。

成功运行注册中心后访问8010端口，主页面如图3所示。

服务提供者的启动类需要@EnableEurekaClient和@EnableFeignClients两个注解，@EnableEurekaClient表明此服务是Eureka客户端，@EnableFeignClients用于告知框架扫描所有通过注解@FeignClient定义的feign客户端。它又通过注解@Import导入了类FeignClientsRegistrar（feign客户端注册器）

服务提供者的xml配置文件则要配置此服务的名称与注册中心的路径。

最后是服务消费者的代码，配置文件与启动类和服务提供者相同，但需要一个额外的接口类，代码如下：

@FeignClient（"provider"）

public interface MicroService {

@RequestMapping（"/b"）

public String getMsg（）;

}

@FeignClient用于创建API接口，该接口是RESTful风格的，括号中填入服务提供者在配置文件中设置的名称，@RequestMapping括号中的路径则是服务提供者具体服务的路径。

此时服务消费者即可使用服务提供者发布的服务。

2.2   Sidecar多语言支持

在智慧城市领域，平台建设厂商非常多，无法统一要求所有厂商均使用Java语言进行开发。对于非Java语言开发的服务，可以使用Sidecar组件来将异构语言接入到SpringCloud框架中。

Sidecar全名为Spring Cloud Netflix Sidecar，包含一个简单的http api来获取给定服务的所有实例（即主机和端口）[4]。之后可以通过从Eureka获取其路由条目的嵌入式Zuul代理来代理服务调用。可以通过主机查找或通过Zuul代理访问Spring Cloud Config服务器。但是第三方程序必须执行健康检查，以便Sidecar可以向应用程序启动或关闭时向Eureka报告。所谓健康检查，就是指异构语言需要一个模仿SpringBoot健康检查接口的可访问uri，返回一个json文档[5]。文档内容为：{ status：'UP' }。

Sidecar的流程图如图4所示。

与普通服务提供者类似，Sidecar也需要将自己在注册中心上进行注册，xml配置文件除了常规的配置端口号，服务名，注册中心地址外，还需要用sidecar.port配置监听的第三方程序端口号，使用sidecar.health来配置健康检查接口的路径，若第三方服务与Sidecar服务不在同一台电脑上运行，则还需要eureka.instance.hostname这条配置来指定第三方程序的hostname，以便进行监听。

Sidecar的启动类也与普通服务提供者略有不同，只需要@EnableSidecar与@SpringBootApplication这两个注解，@EnableSidecar注解整合了@EnableCircuiBreaker，@EnableDiscoveryClient和@EnableZuulProxy，是Sidecar服务的专用启动类注解。

其余配置与代码基本与普通服务提供者相同，这里不过多赘述。

此时服务消费者可以通过Sidecar使用其他语言的服务，实现了第三方语言的接入[6]。

3   微服务在智慧城市建设中的应用

3.1   微服务的设计原则

微服务系统所遵循的设计原则有以下几点：

（1） 無限扩展原则。也就是通过集群、负载均衡、数据分区和业务拆分，来保证系统可以进行无限扩展。

（2） 服务自治原则。即每个微服务都应当具备独立的业务能力。每个服务的开发、测试和部署都必须可以独立进行，并可形成自身的一套完整的业务链，不依赖于其他服务而存在[7]。

（3） 前后端分离原则。前后端分离是近十年来非常火的一种开发方式，指的是前后端的代码分离和项目分离。前端后端形成两个分开部署的项目，只通过数据接口进行通信。前端只负责页面展现和数据呈现，后端只负责数据处理和逻辑运行。对于微服务来说，前后端分离是必须的，单个服务的前后端业务绝对不能耦合在一起，否则其他服务就完全无法调用了。

3.2   微服务系统的建设

微服务架构的核心思想是对现有业务进行服务拆分，然后通过数据总线、服务发现等相关通讯机制对所有微服务进行串联。

一个典型的智慧城市微服务系统的架构图如图5所示：

如何对服务进行拆分，是微服务设计的一个重点内容，拆分的好，微服务如鱼得水;拆分的不好，微服务反而会成为拖累，增加系统的整体复杂度，影响使用和后续扩展。从图中可以看出，本系统中，对每个业务都要用到的基础功能进行了拆分，比如：用户管理、日志、GIS（地理信息）、资产、设备管理、消息推送、服务状态管理等统统都作为一个基础服务进行发布，这样可以确保在未来扩展的过程中，不会出现老业务与新业务的耦合。

这些服务通过服务发现中心进行统一管理，通过AMQP消息总线进行业务数据互通。同时，对前端应用提供API接口支持，供前端页面进行数据展示。也提供了对外数据接口，供尚未支持微服务架构的系统进行调用。而其他系统若要接入本系统，则仅需根据规则对接口做稍许不涉及业务逻辑的修改，然后在服务发现中心中进行注册，就可实现数据接入，非常方便。

4   微服务的优势与不足

上文已经详细介绍了微服务思想以及注册中心在智慧城市平台软件中的应用方式。

通过分析可以看出，微服务最大的技术优势就是解耦，提供容错率，一个服务出现问题并不会让整个系统瘫痪。在软件系统整体功能不变的情况下，系统分解为多个服务。每个服务都有一个明确定义过的边界[8]。微服务架构提供了模块化的解决方案，给采用单体式编码方式很难实现的功能提供了实现的可能，因为单个服务很容易开发和维护。每一个服务都可以是高内聚的，可以在自己内部制定任意合理的规则，并且不影响其他服务[2]。

微服务思想的业务优势是他的高融合性，可以通过HTTP（S）、RPC、gRPC等多种方式接入任意语言、任意平台的服务，非常适合在智慧城市领域进行多种应用扩展和多平台融合。

当然微服务也有种种不足，在实践过程中发现，HTTP请求的耗时可能会成为一个瓶颈，制约系统整体效率的提升。应对方式是采用gRPC方式进行数据交互，gRPC的数据传输效率比传统的REST API高非常多，据测算，gRPC每次时长大致为2000ns/op，但是REST在同等情况下每次耗时为40500000ns/op。原因是因为gRPC是基于HTTP2的，而REST API是基于HTTP1.1的，两者在基础效率上有非常大的差别[9]。

微服务的不足也体现在他的复杂性，低耦合势必带来测试和部署的困难，以前只需要部署一套系统，现在需要部署多种服务。在实践中发现，通过自动化测试和自动化部署工具，可以有效降低采用微服务思想的系统的测试和部署难度，大幅减少人为出错的机会，有效提升工作效率[10]。

5   结   论

介绍了智慧城市发展现状以及微服務思想，分析了微服务在智慧城市平台软件建设中的优势与劣势。现在可以认为微服务思想是一种十分先进且有效架构设计思想，他充分体现了数据的融合和互通，可以充分满足智慧城市平台软件建设需要。除了介绍的Spring Cloud之外，承载了微服务思想的框架还有很多，研发人员大可不必拘泥于某种特定的框架之中，毕竟开放才是微服务的核心，开放才是微服务的意义，开放也会是智慧城市的未来。

参考文献

[1]    周立.微服务架构和概述[EB/OL].https：//www.cnblogs.com/aGboke/p/9051376.html，2018

[2]    舒德伟，许后磊，陈亚军. 基于Spring Boot微服务架构的河长制信息管理系统设计与实现[J]. 数字技术与应用，2018，36;（02）：154—156.

[3]    段学志. CAP原则（CAP定理）、BASE理论[EB/OL]. https：//www.cnblogs.com/duanxz/p/5229352.html，2016

[4]    杨阳. Spring Cloud Netflix多语言-非java语言支持之Sidecar [EB/OL].https：//blog.csdn.net/yang00322/article/details/77964703，2017

[5]    郭栋，王伟，曾国荪.一种基于微服务架构的新型云件PaaS平台[J]. 信息网络安全，2015（11）：15—20.

[6]    王雪峰，阎志远，翁湦元. 基于微服务架构的高铁Wi-Fi运营服务系统设计与实现[J]. 铁路计算机应用，2018，27（06）：31—34.

[7]    程秋明.微服务设计原则[EB/OL] .https：//blog.csdn.net/chengqiuming/article/details/80456040，2018

[8]    孙海洪. 微服务架构和容器技术应用[J]. 金融电子化，2016（5）：63—64.

[9]    程宝平，王兆辉，汪胜，等. 面向企业协作服务的新型业务架构探索与实践[J]. 电信工程技术与标准化，2017（08）：20—25.

[10]  陈世新. 大型互联网公司微服务架构的10个核心问题

[EB/OL]. https：//www.jianshu.com/p/103e9dcfca19，2016