云架构下RS10系统迁移的策略和挑战

戴云鹏，乔运华，班玉荣，周文坤，张宵铭

（1.北京机械工业自动化研究所，北京 100120；2.北京机械工业自动化研究所有限公司，北京 100120）

0 引言

随着时间的发展，RS10系统的功能越来越多，代码也越来越复杂。在这种情况下，系统的迭代和重构逐渐变得困难，即使出现了更适合系统的框架，也需要在昂贵的时间成本和人力成本面前让步，不得不继续使用原来的框架。系统启动需要的时间也越来越长，这对于需要多次重启系统的底层开发者来说是一种折磨，严重的降低了系统的开发效率。由于所有模块都运行在一个进程中，任何一个模块中出现错误，都有可能弄垮整个进程，而随着系统变得复杂，系统出现错误的可能性逐渐增大，系统的稳定性随之降低。这些问题是单体式架构无法解决的，因此将单体式架构的系统迁移到更加支持复杂功能，更加容易扩展的基于微服务架构的云平台上已经变得刻不容缓。

1 RS10云平台

RS10云平台采用了docker容器引擎和Kubernetes编排调度引擎。平台上负载的功能模块主要包含持续集成模块、镜像仓库模块、负载均衡模块、存储模块、安全认证模块、网络模块、日志模块、监控模块这八个模块。其中持续集成模块主要作用是帮助开发人员自动化完成代码编译、构建及镜像发布，并将生成的镜像自动部署运行到平台上。镜像仓库模块主要作用是存储和管理镜像，无论是常用的镜像，还是用户打包的镜像，都可以传输到镜像仓库中。负载均衡模块负责将外部用户访问平台服务的请求转发给平台内运行的相应服务，并将访问流量分摊给运行中的容器应用。存储模块负责提供多种类型的存储资源，在容器应用需要时动态绑定。安全认证模块用于防止平台中各个主机节点之间的通信内容被第三方窃取和篡改。平台各个主机节点之间采用客户端证书认证方式，客户端和服务端需要相互验证证书，双方都确认证书的正确性后才会协调通信加密方案。网络模块是整个平台运行的基础组件，在平台搭建之初运行，负责为平台中运行的每个容器应用分配独立的IP地址，使所有容器应用之间都可以跨主机相互通信。日志模块负责收集、存储、展示整个平台及平台内各个容器应用的日志。监控模块用于监控平台中所有资源的使用情况，并提供图表展示，同时负责将监控到的异常情况发送给指定人员。

图1 RS10云平台层次结构

2 系统迁移策略

系统从单体式架构迁移到云平台的过程应该是平缓的，不应该是一开始就将所有代码重写，这样既充满了风险，又不符合企业发展的需要，系统的迁移应该是逐步的，有策略的。

2.1 从新服务到旧服务

系统在迁移的过程中，客户需要的新功能如果继续在原有的单体式架构的系统上扩展，不但会因为原系统太复杂而需要很多时间，而且再次迁移到新平台上会造成二次开发，浪费时间的同时还会造成人力资源的浪费。因此客户需要的新功能可以直接在新平台上进行开发，这样可以让开发一步到位，减少资源和时间的浪费。在开发完成新服务之后再迁移原来的旧服务。

2.2 从重要到次要

所有的服务都是系统的组成部分，系统迁移的目标也是将所有的服务都迁移到云平台上，但是有的服务是系统所必须的，是系统的基础服务，如日志服务，安全认证、监控服务等，这些服务为系统的运行提供了最基本的安全和功能保障，每个服务的运行都要和这些服务进行协同，因此这些使用最频繁的，也是最重要的服务应该首先迁移。其次还有一些其他的业务功能方面的服务，如邮箱、工作流等大部分用户都要使用的服务，需要在基础服务迁移之后进行迁移，保证新平台上的系统能够满足大多数用户的需求，最后再将一些用户使用较少的功能迁移到新平台上。

2.3 新旧系统可以相互访问

因为系统的迁移是逐步的，但是有些用户在用到新系统上的服务的同时，还会用到旧系统上的服务，在系统迁移完成之前，很多用户都会有这样的需求，因此需要保证新平台上的服务和旧有的系统之间可以相互访问，这样既保证了系统更新的稳步前行，又不会影响客户的使用体验，保证了系统可以稳步迁移。

3 系统迁移面临的挑战

3.1 配置文件的分散

在单体式架构下，配置文件是集中的，配置文件的修改方便且快捷，但是在微服务架构下，每个微服务都是独立部署和运行的，如果将每个服务的配置信息都和镜像打包在一起，就会出现配置文件分散的问题。每当系统部署的环境发生改变，如从开发环境变成测试环境，都要重新修改配置信息并打包镜像，随着系统中的服务不断增多，这个问题会变得越来越突出。因此不同于单体式架构下将配置文件和程序同时集中在一个war包或ear包里面的方式，微服务架构下的配置文件需要和程序分开，将所有配置文件集中在一起，集中进行修改。采用nacos组件管理系统的配置文件可以解决这个问题。nacos可以将配置文件集中到一个UI界面上进行修改，同时相同的配置可以合并，例如连接数据库相同的服务可以共用一个数据库配置文件，这样方便修改的同时减少了文件的数量。

图2 nacos配置文件管理

3.2 文件的存储

在单体式架构下，文件的存储是一个很容易解决的问题，只要存储到本地服务器即可，但是在微服务架构下，服务运行在不同的节点上，文件的存储和共享就变成了一个需要考虑的问题。如果在每个节点上都指定一个目录，负责存储运行在本节点上的服务上传或修改的文件，会遇到很多问题。例如邮箱服务运行在A节点，会把邮件以文件的方式存储在A节点上。但是由于A节点资源紧张，邮箱服务调度到了B节点上运行，由于不同节点上的目录无法共享存储文件，邮箱服务会发现在服务调度之前收到和发出的邮件无法读取。因此为了解决这个问题，需要一个可以在不同节点上共享存储目录的文件系统。RS10系统使用了nfs，即网络文件系统。nfs分为服务端和客户端两部分，文件存储在服务端，客户端只要将服务端的目录挂载在本地，就可以像使用本地文件一样使用资源[1]。这样可以完美解决不同节点上的服务无法共享文件的问题。同时nfs可以设置客户端的权限，既可以将客户端的节点设置为只读，也可以设置为具有读写权限，可以根据客户的需求灵活设置权限。nfs依赖于RPC协议传输数据，服务端通过网络访问位于服务端的文件，本身并不占用磁盘空间，这无疑极大地节省了系统的磁盘资源，避免磁盘被重复的文件占用资源。

3.3 系统的响应速度

微服务架构服务间通过TCP/IP进行通信，不同节点上的服务通信势必要受到网络延迟的影响，使系统的响应速度变慢。但是网络延迟无法在系统方面解决，因此为了系统的整体响应速度不受影响，需要提高数据库的响应速度。为了提高数据库的响应速度，RS10系统使用redis作为公共缓存。不同于一般使用的数据库在磁盘上进行IO操作，redis运行在内存上，因此拥有极快的读写速度。将数据库中使用频繁的数据存入redis中，这样客户端发送请求之后，首先到redis中查询数据，如果有数据则直接返回，否则到一般数据库中查询，并将数据存放到缓存中[2]。这样看似增加了一个步骤，使访问变得复杂，但是相同数据只需要在数据库中查找一次，剩余查询在缓存中进行，这无疑大大提高了系统整体的响应速度，提高了系统的用户体验[3]。同时redis还有限流的功能，可以保证高并发下系统的稳定。

图3 数据库访问示意图

4 结语

系统的迁移是复杂的，从单体式架构到微服务架构的迁移，必须要讲究策略。一开始就将代码完全重写，既有很大的风险，又不符合企业发展的需要。采用从新服务到旧服务、从重要到次要、新旧系统可以相互访问的策略，将新功能的开发放在新平台上，在满足系统升级扩展的同时，将旧有系统的功能逐渐拆分，平滑且稳定的迁移到新平台上，将系统迁移的风险降到最低，这样可以最大程度的保证系统在新平台上的稳定性。在迁移过程中，一定会遇到很多挑战，如配置文件的分散，文件存储困难等。但结果是可以预期的，在稳定的迁移策略下，困难终将被一一克服。