DevOps驱动的人保微服务平台建设之路
Posted EAWorld
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了DevOps驱动的人保微服务平台建设之路相关的知识,希望对你有一定的参考价值。
转载本文需注明出处:微信公众号EAWorld,违者必究。
引言:
2018年,我们在人保寿险进行了微服务平台建设。针对保险行业,微服务建设有哪些需求,我们又是如何应用DevOps理念的,本文我就和大家分享一下我们在人保寿险的微服务建设之路。希望通过本文,大家能够拨云见日,真正的使DevOps成为企业生产力增长的助推器。
目录:
一、项目建设背景
二、平台技术栈及架构解析
三、通过DevOps对微服务应用进行CI/CD
四、总结
一、项目建设背景
根据保险行业发展趋势,目前保险交易已经呈现高频化、碎片化、场景化等特点,对系统的处理能力、容量、业务连续性、需求相应速度、运维响应速度提出了更高的要求。为了提高项目建设的效率、质量、安全性、技术水平,缩短项目建设周期,降低项目建设成本,进而更好的支持业务与技术的发展与创新,人保寿险急需建设应用和服务的技术标准和分布式的应用平台。
那么建设分布式的应用平台有什么好处呢?
1.分布式应用架构解决了服务器性能的问题。单台服务器的性能毕竟有限,综合利用多个节点的处理能力,才能提高整体的服务能力。
2.将不同的业务模块部署在不同的服务器上,或者同一个业务模块分拆多个子业务,再部署在不同的服务器上,以此来解决高并发的问题。这样一来,模块的内聚性更高,更多的关注自身业务,模块与模块间耦合度更低,减少了业务复杂度。
3.分布式应用平台对分布式应用有结构化的管理,相比传统的管理模式,大大减轻了运维人员的负担,应用配置的修改发布可以通过友好的可视化页面轻松完成。
4.分布式应用平台同时解决了分布式应用的监控告警问题,对每一个应用服务进行实时的监控,出现问题能够立刻进行告警通知、第一时间响应。
二、平台技术栈及架构解析
经过项目初期的调研与考察,在人保寿险确定的平台架构技术如下:
分布式平台主要以Spring Cloud组件为技术支撑,主要用到Eureka作为注册中心、Feign用来做服务调用客户端、Ribbon来进行客户端的负载均衡,Hystrix用来作熔断、限流和降级。搭配配置中心Apollo、断路器监控中心Hystrix-dashboard 和Turbine,形成一套完整的分布式微服务架构。
(人保寿险DevOps项目平台技术栈)
在日志的采集和处理方面,我们采用了常见的ElasticSearch+Logstash+Kibana的架构,利用ELK一站式解决方案的便利性,为整个平台提供监控。至于开发测试阶段的持续集成、持续部署,我们通过DevOps+Maven+Git/SVN来完成。
(人保寿险DevOps项目分布式平台技术架构)
分布式应用逻辑架构总共由以下这几部分组成:
(1)服务网关API Gateway,在微服务架构中,所有的服务都变成了一个个细小的API,API Gateway作为整体架构的重要组件,它负责对应用的API进行统一的管理
(2)微服务平台,微服务平台负责应用服务的注册发现、负载均衡、应用配置的管理、服务调用链的监控和告警
(3)PaaS平台,PaaS作为业务基础平台,负责提供公共的各类中间件服务
(4)管理门户,提供友好的可视化界面对应用服务进行登记、配置管理、授权以及日志监控
(5)DevOps,高效自动化地完成微服务应用的持续构建和持续部署。
(6)SDK,为了在应用系统技术架构上形成统一的技术标准规范和统一的规划,弥补应用开发和运行缺乏的技术平台短板,我们向人保提供了SDK脚手架以及开发手册,降低了开发分布式应用的门槛,有效缩短了项目的进度
(7)流程和规范的制订,让项目的全生命周期得到管控,项目在持续构建的过程中不断精益提升,在持续发布的过程中始终可以提供可用的稳定的介质版本
(人保寿险微服务平台部署架构)
在人保寿险微服务平台中,我们明确了用域-系统-应用架构来进行微服务管理的部署模式。
针对人保寿险不同业务领域,例如寿险域、车险域分为不同域进行业务隔离;
每个域下根据公司的业务板块创建业务系统,业务系统这个定义在不同的客户处有不同的定义,有的叫项目、有的叫系统群,实质上都是由一组微服务应用构成的;
业务系统下部署微服务器应用,每个应用部署多个应用实例形成高可用,共同来支撑业务。
三、通过DevOps对微服务应用进行CI/CD
(DevOps对微服务应用进行CI/CD)
通过DevOps进行分布式应用的构建,可以很方便地进行项目构建、发布流水线的编排,可以让开发人员将更多的工作重心放在代码业务逻辑上,大大提高了生产效率和质量,解放了开发运维人员的生产力,减少了手工的重复劳动,避免了因为操作不当带来的损失。
对于人保寿险微服务应用进行持续集成和发布,我们很好地利用了DevOps的特点,本期项目DevOps的目标是通过CICD,对微服务类应用进行自动构建、自动发布、自动部署,减轻开发人员运维人员的负担,提高项目的效率和质量。
持续集成
持续集成模块的功能主要有代码库管理、构建定义管理以及构建实例管理等。在构建定义管理模块中,DevOps平台将构建任务分成了四种类型:
编译类任务:Maven、Ant、Gradle、纯前端构建等
测试类任务:Sonarqube、Jmeter、Selenium等
打包类任务:Npm、Archive、Docker等
其他工具类任务:Copyfile、Shell、介质提交到Nexus仓库、介质上传二方库等。
在每个构建定义上可以选择若干个需要的构建任务,通过原子步骤编排,组装成一个完整构建流程。代码提交时触发构建(支持gitlab、github、svn等常用代码库版本管理工具)、日构建等不同的构建触发策略等,支撑了持续集成的完整链路打通。
自动化部署
针对人保寿险的微服务应用,DevOps定制化了一套持续集成的构建定义。
(1)首先从代码库拉取代码,支持从Git,SVN拉取
(2)接着是构建,可以使用maven、ant、gradle构建,前端支持npm构建
(3)然后通过SonarQube进行代码的质量检测,生成质量报告
(4)最后进行编译介质的发布,在部署机远程执行脚本进行介质的发布
四、总结
截止到现在,人保寿险的一体化项目、微信项目、大数据项目都已经使用DevOps进行项目的持续集成、持续部署了,每天进行近百次构建,大大提升了工作效率,得到了客户的一致好评。随着DevOps的推广,将来会有更多的项目对DevOps进行使用。 那么,怎么才能更好的编排构建流水线?怎么才能让DevOps更贴近我们的业务,更好地与分布式平台整合?自动化运维的路还很长,而做好DevOps,就是向自动化运维迈进的第一步。
精选提问:
问1:DevOps中进行构建时对于各个节点的监控告警是如何实现的,持续集成各节点耗时,超过阀值告警、包括单元测试、持续集成等,包括定时任务是否正常发起,发起是否执行成功,主机资源使用情况等?
答:DevOps暂时没有支持对jenkins构建节点的监控告警,本次微课堂介绍的是对应用微服务的监控告警,通过对应用日志的采集,根据应用日志对应用进行监控。
问2:jenkins和sonar是容器化部署的么?
答:jenkins和sonar就是正常主机安装,没有通过容器方式部署。
问3:想知道你们用的spring cloud 版本.还有断路器监控中心Hystrix以及Turbine用的spring-boot-admin的监控是吗?为啥没有用链路跟踪呢?
答:Spring Cloud,现在有2.0.1,人保的版本是1.4.3。断路器监控中心用的是turbine。人保有自己的apm,所有没有用链路跟踪。
推荐阅读
关于EAWorld:微服务,DevOps,数据治理,移动架构原创技术分享
以上是关于DevOps驱动的人保微服务平台建设之路的主要内容,如果未能解决你的问题,请参考以下文章