62
《广播电视网络》 2021年第1期 总第373期
·东方有线专栏·
1 引言
微服务是近年来兴起的一个概念。在新的系统设计中，总会以微服务架构作为卖点。但对微服务概念的提出者来说，微服务只是一种软件架构风格，并没有完全标准化的定义。为何要使用微服务？何时使用微服务？微服务解决了什么问题？这些都需要我们在实践中一一给予解答。本文就以东方有线接入网网管系统的微服务实践为例，简述微服务切入的点与面。 2 接入网网管系统的现状
2.1 标准化
在NGB 与FTTH 的业务发展过程中，多数广电运营商都会建设由标准协议管理的综合网管。东方有线的
接入网网管系统经过多年的迭代，也已完成了对拓扑、性能、告警等管控的标准化带内功能。 从图1可知，接入网网管系统对南向网元提供SNMP 与CWMP 协议的查询、配置、管理功能，对北向提供
Web Service 业务接口、查询诊断功能，并且通过对Telnet 人机命令的模拟，提供运维代理登录功能。
东方有线接入网网管选择带内管理的方式，利用业务内网络完成网络设备的管理。在业务通道正常的情况下，是一种不需要添置额外管理设备的便捷管理方式。
2.2 发展与瓶颈
在简单的功能场景中，网管系统的功能实现与封装在小数量级的网元非常容易实现。但随着管理网元的数
量级迅速扩增，每一个阶段的网管系统会面临不同的问题。
现在，面对数量近千的OLT、30~50万量级的揽桥、ONU 以及百万量级的终端，集中化的功能实现与本地高可用主从部署方案在系统IO 负载与核心数据库的利用上就显得捉襟见肘。
在传统做法中，IO 读写方式改进、数据库读写分离、核心功能拆分、缓存设计以及异步队列设计等都是改进的方式。接入网网管系统在主要改进方式上都做了相应的尝试。
2.3 系统优化与分布式演进2.
3.1 IO 交互模型
传统BIO（同步阻塞）模型建立管道后，在IO 读写未完成的情况下，线程会被占用（阻塞）。该方式简单，但面对大量的并发尤其是CWMP 协议下的长连接交互，大量的线程会因为无效等待而占用大量的系统资源。所以，接入网网管的底层会采用NIO（异步非阻塞）模型。其核心实际是在IO buffer 后增加缓存Channel 和单阻塞Selector 线程来维护与恢复IO，以避免大量的应用操作占用线程。
fxdis
有一个烧水的例子可以帮助理解。BIO 表示用水壶烧水，在水壶烧开前人（线程）不会离开。而NIO 则是给水壶增加了一个报警壶嘴（Selector），当壶嘴（Channel）有蒸汽通过时会产生蜂鸣。在蜂鸣出现前人不需要守候在一边，可以去处理其它的事情。
当然，在实践中我们会使用MINA 这样的NIO 框架来包装简化底层实现，使我们的应用简练高效。
2.3.2 消息队列
在理解IO
模式的改进后，消息队
变化的互联网时代的首选可能并未在传统IT 企业中做深入的讨论。因此，本文试着从网管系统切入，引出微服务化的进程，寻微服务在实施上的落脚点，并给出了实践的案例。
关键词：微服务 Spring Cloud
63
《广播电视网络》 2021年第1期 总第373期
列作为缓冲池的原因也显而易见。考虑大量的告警、心跳消息，异步、错峰、削峰功能对高并发系统来说都是非常重要的。但另一个重要的原因是，通过MQ （消息队列）我们可以为应用解耦，提供分布式部署的基础，并最终在重要性或承载能力维度上分离业务。
IO 侧的多路复用改造减少了线程
占用带来的系统损耗，消息队列对业务的解耦又为分布式部署提供了负载分配的自由度。当FTTH 业务逐步替代NGB 业务后，我们也可以很容易地增减调整消费队列的完成业务负载调整。
2.3.3 缓存设计
面对大并发量的信息处理，核心逻辑的性能改造也是一个重要组成部分。在迭代中我们发现剩余的瓶颈
多出现在高频数据库读写中，但实际上并不是所有的数据都重要到需遵从ACID 原则。心跳、日志等不太重要的海量数据无需频繁交互数据库；性能采集值与配置信息等在一段时间内不会频繁修改，无需重复查询；被判定为终端的非法访问可以计入静默名单，不应纳入数据库逻辑。我们一般通过REDI
S 内存数据库来提供缓存设计。
在网管系统中，我们通过缓存层更新网元心跳数据、记录其变化，并在每日的固定时间完成数据库持久化并触发心跳变化的校验；通过缓存层过滤查询请求，避免频繁重复的网元查询，减少网元负荷；利用缓存层设计黑白名单，减少非法或托管网元对后台数据库进行异常的数据请求。通过合理的缓存设计，我们补足了核心数据库的处理环节。
2.3.4 微服务思考
通过上述整体迭代，网管系统已完全适合分布式部署。独立的功能子模块可以进行分主机服务的拆分，具体如图2所示。
那么能不能进一步让功能子模块
支持跨系统服务？笔者认为答案是肯定的。阻碍单体架构转变为分布式架构的主要问题只是其能否做好业务逻辑的状态解耦。而网管系统的功能组成包含了CWMP、SNMP、TRAP 等诸多无状态可重用的服务，其完全可以被抽象出来提供系统复用。
随着虚拟化和基础云技术的发展，更多的系统会进行分层架构重构以利用虚拟化弹性扩展优势。存储与中间
件先完成抽象与剥离为系统提供数据解耦和状态保存，然后完成业务核心功能的通用服务包装为系统的高可用、
金属型铸造机高性能弹性部署提供可能。在此基础
上，不同的企业会有不同的服务方案，
图1
图2
·东方有线专栏·
而基于Spring Cloud框架的微服务方案则是当前较流行的一种。
3 微服务实践3d蓝光播放器
3.1 方案选型
从研发角度来说，使用一种风格规范“中间件”并以此解决异构系统间的协调问题并不鲜见。从早期解决异构下应用进程通信的RPC方案，到后来的支持协议适配、服务路由与编排、企业服务总线（ESB方案），再到现在的微服务框架，核心的“差速器”想法（规范与协调）并没有发生根本性改变。
Spring Cloud成为微服务框架选型，是因为它是一套一站式的解决方案，而且其组件丰富、社区活跃度高。作为构建微服务框架所需的编程框架，Spring已被大量JAVA企业应用使用，从而让我们轻松实现新微服务建设或原有JAVA企业应用的微服务包装。3.2 组件选择
我们从众多的Spring Cloud组件组合中选择了较新的注册配置、服务网关、负载均衡、熔断限流、链路监控及文档调试等微服务组件。
（1）注册配置中心是微服务的挂牌中介，为服务网关记录微服务地址、部署节点、命名空间以及一些独立的配置信息。
（2）在微服务的使用中，服务调用者实际访问的是微服务生态中的服务网关组件。服务网关会根据注册配置中心所管理的信息为微服务提供规范访问、负载均衡、功能过滤等功能。我们选用Spring Cloud Gateway（Spring Cloud Gateway）来完成这部分的工作。简单来说，服务网关既可以只简单地做路由工作，又可以通过插件的方式添加过滤器组件为微服务调用提供额外的鉴权、负载均衡或熔断限流作用。
（3）开发人员在使用spring boot
构建微服务时可以激活文档与调试模
块，帮助微服务更清晰地展现接口中
的内容，并提供直接的模拟服务测试
功能。Knife4J组件会对符合注释规则
的微服务自动生成对接文档和调试案
例（注册中心的信息面向系统，而文
档调试模块的信息面向使用者）。该
模块的引入能对微服务平台发展起到
极大帮助。笔者认为，该系统功能组
件可以真正转变为通用微服务的核心
功能——自助。
（4）微服务的便利性会促成一段
时间的野蛮生长。在大量微服务组合
产生后，会形成非常复杂的链路关系。
通过预埋Skywalking组件的微服务探
针，可以帮助我们跟踪链路、监控性能。
当然，监控的注入会产生一定的系统
额外负荷。
3.3 微服务设计
选择一套框架只是完成了微服务搭
建的第一步，让我们更快地建立一个更
具标准化的基于网络调用的功能服务体
系。接下来就是实际的微服务设计，通
以车代磨
常网管系统的微服务实践有三组尝试。
第一组尝试完成基本功能组件的
抽象及微服务化。在前面的章节中，
接入网网管在分布式部署中已自然分
隔了可重用的功能。除了较独有的
BCMP服务之外，在通信环境中SNMP
服务是一个非常通用的标准协议服务，
其与网元交互的管理功能在所有系统
应用中几乎都是相同的。配合不同的
路由和解析规则，同样的微服务实际
可以支撑不同的业务使用，诸如网元
系统、认证系统或企业NAS等。
第二组尝试借助消息队列的虚拟
节点、集以及多租户能力完成中间
件的微服务包装。网管系统中日常承
载的Trap处理、网元批量处理、心跳
处理等都会使用到消息队列组件。但
实际上，消息队列类中间件组件可以
作为PaaS架构中的平台服务被提供给
不同的应用使用。借助集部署，通
过虚拟主机和队列的划分，消息队列
组件非常容易被独立出来。在这里，
MQ的访问代理实际是一层转义逻辑。
通过Spring Boot把MQ生产者/消费者
调用转义为Http的CRUD方法，中间
电梯轨道
件的取用同样适宜微服务包装规则。
第三组尝试包装持久化方案（关
系型、内存型、网络存储脚本）的连
接池和为瘦连接方式提供微服务访问
能力。再进一步，如果系统本身的业
务逻辑调用就基于良好的数据库设计
三范式设计数据，这种逻辑调用就很
容易被微服务框架包装。持久化的数
据库表和CRUD逻辑与微服务的DTO
（数据传输对象）和Http方法一一对应，
有天然的替代优势。这样的包装方式
可以被认为是一种DaaS（数据即服务）
的实现方式。
至此，笔者已基本介绍了接入网网
管的微服务改造方案。在该阶段，我
们仅仅完成了理想化的微服务实践，
更多的维护工作后移、数据一致性问
题的排查、远程调用的性能改进还需管式反应器
要更进一步的思考。但与单体系统的
迭代一样，只有实践才能遇到问题，
只有遇到问题才能解决问题。
4 总结
本文从系统建设的自然演进入手，
介绍了接入网网管的迭代改进方法以及
实践中的微服务改造方案。通过这些实
践经验的积累，我们会在未来更好地构
建基础和场景的应用，为公司在快速的
业务变化中高效地组织人力、技术栈和
积累可复用资产提供一些方向。RTN
64《广播电视网络》 2021年第1期 总第373期
