IaaS解决了物理机资源的资源管理和资源供给问题,通过对计算、存储和网络的统一性和抽象化实现基础资源的统一化供给。IaaS没有解决开发和运维之间的鸿沟,研发人员仍然需要关注运行在操作系统之上的各种基础中间件。PaaS目标是为应用提供运行的各种基础软件,提供实际业务的研发运行环境,从而让业务系统的研发更加简便、更加高效。容器作为PaaS实现的承载载体,有很多种方式,比如docker、rocket等。不过由于docker应用度和流行度更广,从而在某种程度上成为容器的代名词。
容器技术出现之前,构建PaaS环境需要面临组件种类繁多、改造成本高等各种挑战,不同PaaS平台构建的技术栈各不相同,因此对弹性扩展、高可用、监控和日志等要求各不相同,应用研发有更多需配合PaaS平台的东西。随着容器技术的迅猛发展,docker和kubernetes成为业界主流的技术选择,它们以应用为中心的设计理念很好的简化了对应用系统运行在PaaS上的技术要求。
在金融行业,按照业务交易的特点,应用系统一般分为OLTP联机型交易和OLAP分析型交易两种类型:
业务系统迁移到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)现有的系统的技术体系在一定程度了决定了迁移的工作量和难易程度。由于系统在前期研发过程中使用了jenkins,并且使用maven管理jar包,因此迁移的工作量相对较小;
2)在由单体应用拆解为微服务进行迁移上云时,技术栈的选择比较明确,是spring boot+spring cloud,但是微服务的拆分粒度和如何总结梳理出微服务的划分是一个需要业务人员配合的复杂过程。现在随着service mesh的迅猛发展,istio与kubernetes的紧密结合又得到了快速发展,我们也正在相关技术的研发。
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞5
添加新评论1 条评论
2018-07-31 23:52