justsmile
作者justsmile2018-07-30 13:54
研发工程师, 某银行

应用系统迁移上云的分析与实践

字数 4494阅读 4646评论 1赞 5

一. 应用迁移上云的场景分析

IaaS解决了物理机资源的资源管理和资源供给问题,通过对计算、存储和网络的统一性和抽象化实现基础资源的统一化供给。IaaS没有解决开发和运维之间的鸿沟,研发人员仍然需要关注运行在操作系统之上的各种基础中间件。PaaS目标是为应用提供运行的各种基础软件,提供实际业务的研发运行环境,从而让业务系统的研发更加简便、更加高效。容器作为PaaS实现的承载载体,有很多种方式,比如docker、rocket等。不过由于docker应用度和流行度更广,从而在某种程度上成为容器的代名词。

容器技术出现之前,构建PaaS环境需要面临组件种类繁多、改造成本高等各种挑战,不同PaaS平台构建的技术栈各不相同,因此对弹性扩展、高可用、监控和日志等要求各不相同,应用研发有更多需配合PaaS平台的东西。随着容器技术的迅猛发展,docker和kubernetes成为业界主流的技术选择,它们以应用为中心的设计理念很好的简化了对应用系统运行在PaaS上的技术要求。

在金融行业,按照业务交易的特点,应用系统一般分为OLTP联机型交易和OLAP分析型交易两种类型:

  1. 联机交易一般采用B/S架构模式,后端多为“负载均衡+web服务器+数据库”的模式,处理的业务交易多为数据库中单条数据记录的操作。根据业务交易的特征不同,可能有明显的业务高峰期,比如银行的柜台交易只有白天网点营业时间才会有业务交易请求,股票交易系统只有在股票交易日才会有业务交易请求。这类业务交易对交易时间比较敏感,需要交易的快速完成;
  2. 分析型交易一般在夜间或者联机交易的业务低峰期进行,具有一定的周期性,比如按日、按周或者按月进行,实现模式多为通过服务端定时启动的方式完成,一般是采用应用程序和数据库存储过程结合的方式完成。

业务系统迁移到PaaS容器中运行,需要从两个方面进行考虑:

  1. 从技术可行性的角度看,应用上云与其承载的业务系统无关,与业务系统的系统架构相关。比如传统的业务系统一般包含联机交易和批量作业两种业务,业务数据通常存储在数据库中,还有一些应用有特殊设计,比如有些业务系统会将一些非结构化数据存储在共享存储或者专用的大数据平台中、有些业务系统的多个web服务器之间需要互相感知关联信息,比如通过接口通知彼此的IP地址等。因此,需要对应用系统做好架构梳理工作。
  2. 从业务重要性的角度看,目前PaaS作为一项新兴的技术,正在逐步的完善和发展,任何新技术的尝试必然面临潜在的技术风险。因此在将诸多业务系统迁移容器的过程中,一方面需要对业务系统上容器的先后顺序作出一种权衡和选择,比如先迁移一些重要性低、交易量小或者内部管理系统等,一方面对可能需要面临的风险与挑战做好一定的风险评估和应对措施。

二. 应用系统迁移上云的项目实践

在实现应用迁移上云的过程中,一般会面临已有业务系统改造和新建业务系统两种场景。新建业务系统只需要按照应用上云的标准要求进行架构设计、研发、编码和测试即可,实现相对简单。已有业务系统迁移上云则需要面临业务系统改造问题。为测试应用系统改造的复杂性,笔者带领的团队专门拿一个内部系统进行改造和测试,最终实现成功迁移。

在系统现状方面,目前的业务系统采用spring mvc + mybatis +spring的java技术栈研发,数据库采用oracle rac,web服务器采用IBM 的was。部署环境中采用F5作为负载均衡。在迁移过程中遵循对现有系统最小改造的原则进行。

在基础运行环境方面,本系统在编码过程中采用eclipse内嵌tomcat作为web服务器进行测试,只有经过单元测试和集成测试后才会部署到was环境中进行后续测试。这种研发模式曾经遇到过由于tomcat和was的工作机制差异性,导致系统编码需要兼顾二者运行环境的兼容性。选择容器中的web容器时,虽然有jetty、liberty等多种选择,但考虑到本司对tomcat已经使用很久并且所有代码的编写都是先在tomcat进行本地测试,因此笔者选择了tomcat。鉴于业务系统的重要性,数据库仍然运行在PaaS外部,因此无需改动数据库使用模式。

在持续集成方面,本系统当初研发时采用maven方式管理jar包依赖,因此在改建目标代码时基本无需改造,只需在linux环境中使用mvn命令模式运行构建出war程序即可;然后,编写Dockerfile将编译出的war程序打包到image;最后将编译生成的image推送到镜像仓库,从而实现从代码到镜像仓库的自动化流转。整个流转过程采用部署在PaaS中的jenkins完成。jenkins运行在PaaS平台的容器中,并且以master-slave模式运行。这样每次触发代码构建时会自动生成jenkins的salve节点,构建结束后slave容器回收,从而有效节省资源。

在持续部署方面,在jenkins中安装kubernetes的插件,由于插件实现了与PaaS的良好集成,可以实现一键式自动部署任务。

在流程管理方面,由于实现了代码一键式编译和环境一键式部署,因此极大的减轻了研发人员操作环境的复杂性。同时鉴于对流程管理的需要,通过在jenkins设置用户权限和pipeline的方式有效实现了权限管理和流程控制。

在部门职责方面,由于PaaS平台的引入,对传统的系统开发和运维造成了一定影响,尤其是在开发运维等职能分工明确的金融行业。在最初引入PaaS平台时,我司由研发中心的一个部门牵头做PaaS研发,然后与研发中心和数据运维中心的各个相关职能部门进行沟通,最终确认以渐进式改变为原则,先引入PaaS平台,在实际操作经验中逐步调整和优化部门职责,最后达到各司其职。PaaS研发的牵头部门通过与研发中心和数据运维中心相关处室的多次沟通,最终形成了部门职能划分和系统研发投产流程的确定。在部门职能方面,数据运维中心提供操作系统、网络、IaaS等方面基础设备的资源和技术支持,研发中心负责平台的建设和自身运维,项目管理流程在现有流程基础上进行简化,并将项目投产流程转移到PaaS平台中进行pipeline管理和行政审批;在研发方面,由基础平台部门进行PaaS平台的牵头建设,项目管理、安全管理、测试部门等参与平台建设,并对平台功能进行需求设计和相关测试工作,同时完成与数据运维中心相关职能部门运维系统的接口和平台对接。

从应用改造迁移上云的过程可以看出,由于应用系统在研发过程中采用了maven管理jar依赖、使用jenkins进行持续集成和持续部署,因此后期在迁移上容器的过程中改动的工作量非常小。迁移上云的主要工作量更多消耗在了jenkins与PaaS的功能集成上面,但集成属于PaaS平台建设的内容,可可视作迁移上云时对环境的前提要求。

三. 应用迁移上云的微服务改造尝试

虽然应用轻松迁移上云,但应用系统还是一个单体应用。为满足组织级和应用级对各种业务功能的通用化需求,项目组随后开始实施对业务系统的微服务改造。

在架构选择方面,微服务架构面临dubbo和spring cloud两种选择。spring cloud是一系列框架的有序集合,它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发(如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等),均可以通过spring boot的开发风格做到一键启动和部署。相较于dubbo的框架定位,spring cloud可以视作微服务的一个整体解决方案,鉴于它目前的发展趋势、和spring boot的关系、业务发展趋势等,项目组选择了spring cloud。

在开源框架方面,项目组选择了spring boot进行系统研发。spring boot是由Pivotal团队提供的java研发框架,它简化了新Spring应用的初始搭建以及开发过程,尤其是该框架使用特定的方式来进行参数配置,从而简化了研发人员定义样板化配置的复杂性和工作量。目前,spring boot正在迅猛发展,成为快速应用开发领域的普遍选择。考虑到spring boot的技术流行性,项目组选择了spring boot。

在微服务划分方面,如何划分微服务的粒度,成为微服务设计的重点,如果粒度过粗,每个微服务作为一个应用运行时还是相对重量级;如果离地过细,作为应用运行时的微服务个数过多,运维难度较大。项目组在建设过程中主要采用如下原则和步骤:

  1. 总体原则:将整个团队分为多个小组,每个小组对应一个领域的微服务。在实践阶段,为便于管理和研发,不拆分过多个微服务,以每个小组不超过三个微服务为宜。
  2. 将系统按照功能拆分为OLTP和OLAP两种类型;OLTP的业务交易均为无状态应用,采用Deploy模式部署;OLAP的业务交易均为定时交易,采用CronJob模式部署;
  3. 首先讲OLTP和OLAP的业务均拆分为基础功能和业务逻辑两大领域,然后再对业务领域按照细分领域对象进行拆分,比如项目、资金等。在每个领域形成一个大对象的增删改查,比如项目的新增、删除、查询和修改等功能。业务对象的查询一般会需要多种条件,但结果一般分为单个对象或者对象列表两种类型,因此设计查询接口时,分为两种类型:单个对象查询和对象列表查询。对象修改接口也采用相同思路;
  4. 在拆分过程中如果业务领域的常见功能,则将其划归到基础功能领域。比如税额调整。虽然它是业务领域的问题,但从设计层面看可看做系统参数调整,因此就划归到基础功能领域;
  5. 由于业务功能在适应市场需求的过程中不停在变,但基础功能要求不变。在接口设计时对接口添加版本。比如,在内部某流程的资金审批方面,之前是五万需要领导审批,现在变更为十万需要领导审批。由于所有微服务URL均待版本号,因此过去的服务接口URL是/v1/flow/fund/cert/,金额改动后的服务接口会变为/v1.1/flow/fund/cert。这样调用此接口的新系统调用V1.1接口,未改造的系统则仍然调用V1接口。当功能变动比较大时,接口版本号会升级为V2。
  6. 当系统运行一段时间后,通过服务接口的分析可以查看哪些服务接口已经不再被调用,比如v1接口没有被微服务被调用,后续的系统变更中会考虑接口生命周期的结束和退出。

四. 应用迁移上云的实践总结

通过应用迁移上云的迁移测试实践可以看出:
1)现有的系统的技术体系在一定程度了决定了迁移的工作量和难易程度。由于系统在前期研发过程中使用了jenkins,并且使用maven管理jar包,因此迁移的工作量相对较小;
2)在由单体应用拆解为微服务进行迁移上云时,技术栈的选择比较明确,是spring boot+spring cloud,但是微服务的拆分粒度和如何总结梳理出微服务的划分是一个需要业务人员配合的复杂过程。现在随着service mesh的迅猛发展,istio与kubernetes的紧密结合又得到了快速发展,我们也正在相关技术的研发。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

5

添加新评论1 条评论

#wdtoyota项目经理, 国企
2018-07-31 23:52
有帮助,赞
Ctrl+Enter 发表

容器云管理平台选型优先顺序调查

发表您的选型观点,参与即得50金币。

作者其他文章