探讨微服务在燃气企业数字化转型中的实践应用

陈徐栋

（江阴天力燃气有限公司，江苏 无锡214400）

随着大数据、人工智能、云计算等新技术的高速发展并且逐步向产业和行业下沉，数字化的浪潮已经不可避免地到来，城燃企业也同样面临着向新兴数字化转型的迫切需求。而在数字化转型中，IT的转型或升级是数字化转型之路上最重要的革新力量。

数字化的本质，是通过上述新技术与企业的业务进行深度融合来实现商业模式的创新以及企业效率的提升，核心就是快速响应和准确洞察。但城燃企业传统的烟囱式信息化架构，往往无法满足这样快速接入、融合支撑[1]、弹性扩展等的需求。

那么如何打破烟囱式架构、释放数字资产的价值呢？运用“去中心化”的微服务架构，为应对这样的挑战提供了一个很好的解决方案。

1 微服务

1.1 微服务定义及概述

2014年，MartinFowler与JamesLewis共同提出了微服务（Microservices）的概念，定义了微服务是由以单一应用程序构成的小服务，自己拥有自己的进程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用HTTPAPI通信。同时服务会使用最小规模的集中管理（例如Docker容器）能力，服务可以用不同的编程语言与数据库等组件实现[2]。

通俗点讲，微服务就是把传统的单体应用根据实际的情况进行解耦，拆分成一个个单独的服务，每个服务专注于做特定的事，提供特定的服务。这样的服务都可以单独进行部署及迭代，并且能够更加根据实际情况拥有自身对应的数据库。比如可以将原来应用中的销售功能解耦拆分出来形成一个单独的微服务，这样做的好处在于，如果遇到类似于调价前用户集中抢购的情况，只要对销售服务资源进行调整即可。

1.2 微服务特点

微服务架构具有低耦合、组件化、独立部署、独立扩展、去中心化等特点，主要体现在以下方面：①服务粒度小。一个系统被解构为多个颗粒度较小的服务，每个微服务的可维护性和开发效率较高。②独立进程和部署。每一个服务都可以独立部署及独立运行，这种方式能够实现灵活的代码组织和敏捷开发，降低了业务迭代时服务发布的风险，扩展性也很强。③去中心化。每个微服务可以根据自身的特性和整体发展的需要，自由选择最适合的技术栈。

1.3 微服务优缺点

相比传统架构，微服务具备以下优势：①由于服务足够小，因此易于被理解，也易于开发、维护以及迭代更新；②各服务间独立性强，易于部署；③由于每个服务较小且独立，易于在横向纵向上扩展，也易于按需求对硬件资源进行扩容，因此可扩展性较强；④各服务可以用不同的语言开发，数据库也可不同，兼容性强；⑤可使开发团队职责清晰，与IT组织的匹配性更强。当然，微服务架构也存在一些缺点，诸如它有分布式系统固有的复杂性，对运维的要求也较高。

2 实践应用-技术框架

2.1 架构设计及搭建

首先对燃气企业最复杂最重要的主营业务系统（物联网表营销系统）进行了改造，将原先复杂庞大的单体业务系统进行解耦并微服务化，并选择了spring boot来进行开发，最终完成的智慧燃气云系统架构，如图1所示。

从图1中可以看出，整个微服务架构的访问链路为：外部请求（web/app）—负载均衡—服务网关（API GateWay）—内部微服务—数据及消息，其中各微服务与APIGatway之间的调用，则会通过统一的服务注册配置中心来完成。

图1 智慧燃气云系统架构

2.2 微服务的服务网关（APIGatway）

燃气公司的业务功能繁多，可提供的服务也非常多，但显然客户端是不需要和每一个服务逐一打交道的，这就需要一个统一的对外入口，在这里搭建了微服务的服务网关（APIGatway）。APIGatway主要包含了对请求的路由和过滤两个功能，它能动态地将外部请求路由到所需要的的内部微服务集群中，是实现外部访问统一入口的基础过滤器。这样，虽然内部微服务是一个复杂的分布式网状结构，但外部通过网关来看是一个整体，屏蔽了内部服务的复杂性。APIGatway还具有鉴权、限流、安全等功能。同时，由于它对外暴露的唯一接口，所有的外部请求都将通过它来访问，为了应对高并发、高可用，需要对APIGatway进行集群形式的部署，并在前端搭建Nginx（应用层）/SLB（网络层）来进行负载均衡。以上的APIGatway采用了SpringcloudNetflix框架的组件Zuul来实现网关服务。

2.3 微服务的服务注册与发现

对原先的业务进行了解耦微服务化，这样就形成了二十几个微服务组成的微服务集群，那么这些服务之间的通信，就需要服务提供方注册报告服务地址以及服务调用方能发现服务目标，因此引入了Eureka来进行所有微服务的注册发现管理。首先搭建EurekaServer以提供服务注册服务，所有微服务启动后都会在EurekaServer进行注册，并通过Eureka Client连接到EurekaServer后定时发送心跳。Eureka默认心跳周期是30s，表明服务仍处于存活状态，如果连续3次未收到心跳，才会判断服务死亡然后将之从注册中删除。

2.4 熔断降级监控

新的微服务架构其实是一个分布式系统，同时微服务之间存在着复杂的依赖关系，依赖的调用不可避免地会存在超时、异常、失败等问题，很可能某个服务的一次延时就会在短时间内耗尽系统资源并导致整体服务崩溃。为解决这样的雪崩效应，搭建了Hystrix来进行容错处理，它可以通过熔断、隔离、回退、降级、限流等机制，对整个微服务集群进行弹性容错保护，以保证系统的稳定性。

3 实践应用及效果

在没有采用微服务架构前，公司的营销系统平台采用的是传统的架构，如图2所示。

图2 公司的营销系统平台架构

从图2中可以看到，原来的所有技术架构以及业务应用还是沿袭着传统的烟囱式的、单一的部署方式，存在着诸多弊端：①集中式架构无法适应技术的发展。无论是大数据分析的需求，还是物联网带来的海量数据，这些新的情况都需要向分布式架构部署转变。②单体架构的业务应用无法面对公司的发展及市场的竞争。原先单体架构对于适应业务的高并发需求、横向扩展性等非常有限，业务的处理规模及发展也存在着瓶颈，受到了极大的限制。③后期迭代及扩展效率低下。随着业务的不断发展，业务平台也不断地进行迭代更新，功能越来越多，软件代码也越来越复杂。原先的架构导致这些代码都融合在一个应用程序中，该应用中的各项功能服务之间的逻辑关系也都是在一起的，这就导致如果面临功能扩展或者逻辑调整，整个迭代的复杂程度会越来越大，时间周期也会越来越长，效率会急剧降低，代码的可维护性下降，并且建设和维护成本会显著上升。同时在原先的架构中，一个应用程序中的各项功能服务一般都是访问同一个数据库，那么如果遇上服务或者数据库发生问题，则极易造成全局性的问题。现在按照上文所述的微服务架构，对整个“物联网表营销系统”平台进行了解耦及重构，重构后的业务结构如图3所示。

图3 重构后的业务结构图

从图3可以看出，前端请求和后端的业务服务中间通过网关来转接，后面的业务服务由原来的一个笨重的整体转变为各司其职的状态，每个业务服务只专注于自身服务范围内的职责。实践中根据公司具体的业务现状以及整体的信息化建设现状，将原先的业务平台进行了合理的解耦，比如通讯采集微服务仅负责与各种物联网设备进行通讯并采集其数据；营收结算微服务负责按照公司的结算规则定期对用户的缴费用气情况进行结算；设备微服务负责所有的设备全生命周期管理，包括出入库、维修等；派单微服务则专门负责整个工单系统的派单、接单、回单等。各微服务系统之间的逻辑关系非常清晰，管理方便。并且能够根据各种服务的特性，部署不同的数据库。比如对于这里面海量数据处理以及后续预期扩展性要求较高的物联网表通讯采集服务选用了MongoDB，对于适用关系型数据库及稳定性要求较高的其他业务服务选用了Mysql。同时这样的架构也使故障可隔离，比如假设通讯采集服务发生故障，并不影响其他业务的使用，类似开户报装、充值缴费等业务仍旧可以正常运行，而不像以前，一旦发生故障，则所有的业务都将停止，造成巨大的恶劣影响。

改造上线后，最直接的效果就是原先的开发上线周期明显变得更加敏捷。通过统计了3个月的开发需求迭代记录发现，显示由原来的平均32人天/项大幅提升至平均15人天/项，同时，由于微服务架构将相关联的业务逻辑及数据放在一起形成了独立的边界，某些服务的更新不影响其他服务，大大提高了快速交付能力。本案例中，改造后的迭代上线时间也大幅缩短，由原先4～6h大幅缩短至1h以内，这些都意味着今后这个架构平台对于企业数字化转型需求的支持能力是显著提升的。

微服务架构的价值还不仅仅体现在当下，其通过对业务服务的解耦拆分，将不同的业务应用及数据分布式部署在云平台上，能够真正发挥云计算的算力，使城燃企业的信息化系统更适合云上生态。同时微服务架构的搭建，还可以使燃气企业未来能够更加方便、高效、精准地搭建自己的数据中台及业务中台，从而为大数据、AI等数字化转型新技术提供强有力的支撑，比如通过用户画像分析、消费行为分析等实现精准营销，来赋能城燃企业数字化转型。

4 结束语

本文通过实践案例阐述了微服务架构的搭建以及在城燃企业中的具体应用。可以看到，微服务这种去中心化的架构理念不仅能有效解决原先烟囱式架构的各种痛点，也比较契合云计算、大数据分析以及人工智能等新技术的发展，更能够给未来燃气企业的业务融合、大数据分析、数据资产化等提供很好的基础支撑，并为正探索数字化转型的燃气企业提供了一种比较适宜的方法。