K8S云平台下云ESB迁移心得

Posted 2021-06-28 数通畅联

K8S云平台的部署方案是目前项目中主推的部署模式，后续项目都会采用云平台模式，通过云平台不仅可以实现部署的便捷化，同时对于从开发到测试再到生产环境的部署提供了平台的快速配置与推送，并且对于后续项目运维工作提供了统一平台，可以大大降低运维的难度。

本次某大型央企“云ESB产品+培训”项目，也是公司iPaaS集成平台系列的典型项目形态，在前期开发培训时只是搭建了非高可用的开发环境，生产服务器部署后需要将ESB整体迁移至生产环境，因此根据实际项目梳理了云平台开发模式下ESB服务器迁移的步骤以及相关的工作内容。

1总体说明

云平台环境下的迁移主要是用于测试服务器与生产服务器间的迁移，通过K8S云平台部署的环境，生产环境一般采用5-7台服务器进行高可用部署，而测试服务器采用3台服务器的最低配置。在实际项目开发时，如果前期在测试服务器上开发，迁移生产服务器时，就需要将测试服务器上的数据、服务等整体迁移。

下图为云ESB的运行机制图：

 

通过搭建K8S集群实现云ESB的部署运行，在K8S内通过容器部署云ESB、Redis、私有镜像库等，从而实现集群化部署管理，借助于NFS、DRDB等技术实现集群的高可用部署，满足实际应用的部署运行。管理端通过部署UMC云管理平台实现对K8S集群的管理，提供包括集群配置、产品升级、容器扩容等管理功能，同时通过nginx代理绑定虚拟IP，从而实现其他应用的访问。

下图为实际项目中常用的高可用部署架构：

 

出于安全考虑，整套环境部署采用内网环境，外部通过VPN访问，通过Nginx和Keeplived代理的虚拟IP访问K8S集群，K8S集群采用3台Master和4台Worker的部署方式，其中Master主要满足数据库、镜像库、高可用、Redis的部署，同时通过Master管理4台Worker服务器，实现云ESB的部署，云ESB运行在4台Worker服务器上，外部访问统一通过虚拟IP访问。

1.1需求说明

1.搭建高可用的生产服务器环境，同时满足实际业务中数据量的要求；

2.将在测试服务器开发的ESB服务/流程迁移到生产服务器，同时保证不需要再重新开发，而且迁移后的流程可以满足实际业务的需求；

3.迁移的过程中允许对ESB流程、业务系统中涉及IP地址、端口的内容手动进行调整；

4.迁移后根据实际需求，可以开放内网中各个服务器直接的网络互通，但只根据需求开放部分服务器的IP和端口；

5.原则上使用内网环境，不允许所有服务器开放外网，支持通过VPN访问，如有需要，可以使用代理服务器通过Nginx代理开放外网访问。

1.2系统资源

系统资源主要是服务器的配置信息，包括测试服务器和生产服务器，一般测试服务器采用3台服务器的最低配置，或者采用单机的本地化开发模式；而生产服务器采用高可用的K8S集群部署，具体服务器的配置可以根据实际项目的规模、数据量、预算等进行服务器规划，具体配置在此不再过多说明。

1.3部署资源

主要是各服务器的资源部署情况，特别是数据库的部署服务器，下表是一个K8S高可用集群的资源部署情况，其中mysql数据库单机部署在master1上，master1上的MySQL数据库即为数据迁移时的目标数据库。

 

2准备工作

在进行服务器迁移之前，首先需要对需要迁移的内容进行准备确认，包括测试数据库、生产数据库、ESB工程/服务/流程等，数据库需要有地址、端口、用户名、密码、数据库等信息，保证可以进行数据访问和操作；如果ESB的内容较多，需要列出服务清单，避免出现遗漏。

2.1数据准备

主要是准备数据库的连接信息，保证可以通过数据库管理工具访问相关的数据库，获取数据以实现不同服务器之间的数据库数据同步操作。

如下表的数据库连接信息，需要包含完整的连接信息，需要明确到具体的数据库，如果是本次开发，需要多个数据库进行数据合并，还需要明确到具体的数据表和数据。

 

2.2服务梳理

主要是对项目中开发的ESB工程/服务/流程进行梳理，并且输出Excel文档进行整理记录，通过记录不仅可以梳理实际业务场景，同时在迁移时可以根据Excel进行结果对比和确认。

下表是部分系统的服务/流程梳理：

 

2.3系统信息

系统信息主要是梳理各个系统的访问IP地址、端口等信息，系统信息的梳理主要是为了服务器迁移后处理流程中的服务地址，在通过ESB进行服务/流程开发时，由于涉及各个系统的服务封装，所以大量的使用了Http调用组件，而开发时Http调用的URL都是直接在流程组件中定义。后续各业务系统升级、迁移时，随着服务器地址变更，必然带来大量地址的切换，为了避免大量调整ESB流程，所以在迁移生产环境时直接通过ESB的全局变量配置好各业务系统地址，后续调整时直接在SMC中修改，避免修改流程。

下表是系统信息收集的样例：

 

3数据迁移

数据迁移，即数据库迁移，主要包含两个步骤，一是数据的迁移，二是数据的处理。数据迁移是将开发环境下的数据迁移至生产环境，因为生产环境是初始化数据库，所以可以整库迁移，数据处理主要是在数据迁移后，在生产服务器将一些测试工程、服务、流程进行删除，以及对一些无用日志等数据进行清空处理。

3.1数据迁移

数据迁移的方式有很多，可以通过数据库的备份工具对数据库进行备份还原，也可以将源数据库导出成脚本，再导入目标库。本次通过Navicat的数据传输将测试服务器上的数据全量导入到正式服务器的开发环境数据库中。

 

3.2数据处理

1.进入正式服务器的ESB数据库，手动修改db_resource数据表，将ESB的连接信息改成正式服务器的连接信息：

 

2.进入正式服务器的ESB数据库，清空正式服务器ESB数据库中所有日志表的数据，同时删除历史日志月表以及应用集成的日志表：

 

3.访问生产服务器上ESB的SMC，在服务工程中进行数据处理，根据各个系统使用的服务情况，将测试服务、流程删除，只保留正式使用的服务和流程。

3.3注意事项

1.对于ESB数据库，在进行全量导入后，一定要先到db_resource表中手动将ESB的数据库连接改成新的数据库连接信息，否则可能造成ESB无法访问的问题；

2.如果目标库是初始化数据库可以采用全量导入的方式，如果是非初始化数据库，一定要采用增量脚本的方式进行数据同步，避免对目标库的数据进行覆盖；

3.在清理数据时，注意系统功能月表（ws_statistics202103、ws_log202103、mf_statistics202103等），可以清空数据、删除历史月表，但要保留当前月的月表，避免SMC出现页面报错；应用集成中不再需要的应用集成配置可以把对应的月表全部删除。

4开发部署

在数据库迁移并且处理好数据后，就需要对ESB的工程进行部署，将设计器中的工程部署到正式服务器，同时调整对应的各业务系统的调用地址以及服务测试，由于系统IP的变量配置主要影响后续运维工作，所以该工作可以放在最后进行。

4.1工程部署

在ESB设计器中将各个工程连接的服务器由开发服务器调整为生产服务器的开发环境，并将ESB工程部署的生产服务器，注意如果工程中有测试或者已经废弃的服务、流程，要卸载、删除。

1.设置ESB应用，配置应用服务器：

 

2.选择服务器配置，增加正式服务器配置：

 

3.通过复制原服务器配置快速新增：

 

4.修改正式服务器名称和地址，并测试连接：

 

5.选择正式服务器进行更换：

 

6.更换完成：

 

7.检查服务流程：展开工程目录，检查各级目录下的服务、流程是否有缺失，如果有缺失，说明数据库迁移数据没有迁移全，需要检查迁移数据：

 

8.如果服务、流程无缺失，直接部署ESB工程：

 

4.2系统调整

各业务系统调整ESB服务、流程调用的代码（系统内部代码），将调用地址改成正式服务器地址。为了便于各系统进行调整，可以在服务部署到正式服务器后，对正式服务器的所有服务进行统一梳理，重新整理系统的服务地址。

 

4.3变量处理

为了降低后续其他系统服务器迁移时ESB调整的工作量，将各个系统的访问地址、变量信息等统一维护到SMC的全局变量中，ESB的服务、流程统一采用全局变量，ESB服务或流程中直接引用。

1.各业务系统开发的ESB服务调整，所有使用到Http调用组件进行服务调用（包括Web和Http）的流程都需要进行调整；

2.打开流程的Http调用组件，找到调用URL：

 

3.删除URL的IP地址和端口号：

 

4.鼠标定位调用URL的开头，选择变量：

 

5.找到esbconfigs/SysIPConfigs下对应的业务系统地址（各系统对应的编码和地址参考2.3梳理的系统信息）：

 

6.选择地址变量：

 

7.流程保存、部署。

4.4服务测试

在服务迁移之后一定要进行整体测试，从整个业务维护的角度出发，对集成工程中所涉及到的主数据集成、业务集成等各个功能点进行测试，可以参考2.2梳理的服务清单，根据服务清单和业务场景进行整体测试。

5个人总结

本次项目是第一次直接参与云平台环境下的集成项目，虽然只是进行ESB的产品培训和搭建工作，但在项目过程中，无论是对云平台、ESB等相关产品，还是对主数据集成、业务集成的实施模式都有了更深的体会。

5.1实施模式

本次项目主要是提供ESB产品，以满足项目中主数据集成、业务集成的需要，在项目过程中，也了解了其他厂商的主数据产品，为我们主数据产品的后续升级完善提供了一定的借鉴。通过ESB支持主数据集成对于主数据集成模式更加熟悉，虽然本次没有使用ESB的应用集成模式，都是通过ESB进行服务封装和转换，但是这种方式反而降低了主数据实施的工作量，职责分工比较明确，数据接收方进行服务封装，数据提供方只负责调用接口发送数据。

5.2产品应用

本次是第一次在实际项目中使用UMC云平台，虽然只部署了ESB一款产品，但是在这个过程中，对于UMC、ESB产品，以及K8S云平台部署和使用有了更加深入的了解，对于UMC的使用以及通过UMC进行日常运维监控、产品部署升级也更加熟悉，由于后续项目都会采用云平台的模式，所以也为后续项目实施提供了经验。

5.3个人总结

ESB产品培训相对于实施项目工作量和时间都相对少，而且由于ESB产品本身相对成熟，所以在实际项目中并未遇到太多难题，即使涉及到产品问题大部分也是产品使用上需要优化的内容而非产品BUG。由于ESB需要交付客户以及各个系统的开发人员使用，所以也促进了自己对ESB产品功能的更深入了解，便于在实际使用过程中出现问题时的快速定位与处理。

本次项目虽然只是培训项目，时间并不长，但是对于个人来说还是非常有帮助，不仅仅是对UMC、ESB等产品以及项目实施的了解，更多的是对项目管理方面的帮助，由于是作为项目成员协助项目推进，通过平时和项目经理的交互和工作，发现自身还存在很多不足。作为项目经理，不一定需要太强的技术能力，但是在关键时刻或者遇到问题时，需要能够提供思路和方向，指导成员工作；把控好时间节点和工作量，合理控制需求，分期推进项目，不要过渡需求蔓延；在平时工作中，更多是要与客户沟通，交互需求、方案、计划和结果，而不是亲自去做具体的工作；对于团队的工作进度要实时把控，及时了解进度，进度拖延时要及时查找原因，协调资源推进工作；要具备很强的协调组织能力，不仅仅协调团队内，更要去协调客户、协调其他厂商，来保证项目的有效推进。