En 400-6655-581
3
返回列表
> 走进派拉 > 新闻资讯 > 技术干货 > 技术干货 | 微服务时代,为什么需要做持续集成

技术干货 | 微服务时代,为什么需要做持续集成

2019-07-03

持续集成对于微服务的意义

一谈到微服务,大家首先想到的是如何拆的问题:拆的粒度、拆的时机、拆的方式。


这当然没错,但要提供一个完整的服务,不是将每个微服务都开发完成就结束了。


大家可以想象将一辆整车拆成零件,然后再组装回去的过程,就可以知道拆虽不容易,合则更难,需要各种标准,各种流水线,才能将零件组装成车。


那么接下来让我们来看下软件拆的过程:

之前的单体应用:一个Java后端和一个数据库便搞定了;


数据量增大,单体架构无法支撑,架构变更,最外面接入Nginx负载均衡,数据库使用一主多从,进行读写分离等等。


这时候系统庞大,但实际服务的仍是单体应用的java后台,当客户不断提出新需求,业务逻辑开始交织,质量开始无法保证,灾难开始。


现在的微服务架构


微服务,优化架构,对业务解耦。

接入层的设计、服务发现-服务编排、消息队列与异步化、配置中心、日志中心、熔断限流降级、缓存、数据库-分布式数据库-分布式事务,再到无状态化、容器化….


业务解耦,微服务变多,如何让各服务顺畅的动起来尤其重要。


那么,如何让各微服务“互动起来”呢?


持续集成要上场了…..


开发运维一体化


持续集成就是让微服务不断的尝试在一起,就是制定一系列流程,将需要在一起的各个层次规范起来,方便微服务在一起,强迫微服务在一起,完成特定业务功能。



DevOps就是实现强迫微服务在一起的工具,工具有很多,在此就不展开了。

可以参考:https://www.w3cschool.cn/jenkins/

https://juejin.im/post/5ca8082df265da30813813bd



想做好持续集成靠仅有的工具和流程是不够的,还需要文化。

因为微服务之后,模块繁多,让少数的运维能够很好的管理所有的服务,压力很大并容易出错。



但开发往往被分成很多个团队,每个模块负责自己的部署,则不易出错,所以一部分运维工作就需要交给研发来做,需要将研发和运维打通。



如果企业没有这个互通概念,持续集成也基本凉凉..


有了这个文化,还需要日常管理流程来保证持续集成的有效运行。


比如,每天早上,第一件事情就是开站会, 一起说我昨天做了什么,今天打算做什么,有什么阻碍,这个站会对于开发有比较大的压力。


例如你的一个功能block了依赖方的开发,在会议上会暴露出来,大家都知道这件事情了,一天block,两天block,第三天你都不好意思去说了…


到了晚上,一天的成果物要提交,持续集成要求每天都提交代码,这样才能降低代码集成的风险。


如果埋头写一周一起提交,这样往往集成不成功。


提交不是马上进入主库,而是需要通过代码审核、审核完成还要通过静态代码检查、通过单元测试,编译完成之后上传nexus,生成Dockerfile。


凌晨,会有自动化的脚本将Docker镜像通过编排部署一个完整的环境,然后跑集成测试用例,测试不通过,则会发出邮件来,是因为当天谁的哪个提交,导致测试不通过,抄送所有人,这是另一个压力,因为第二天的早会上会过昨晚的问题。


通过日常管理过程,层层保证质量。


然而持续集成只是开始,持续交付、持续部署才是目标,持续改进才是重点,这个厉害了,在此我们也不展开了…


So,持续集成更是一种研发能力的象征。

派拉
我们的实践

持续集成、持续交付、持续改进,这么好的实践我们没有理由拒绝,在派拉的产品研发过程中都进行了实践并取得了良好的成果。


派拉统一身份管理与安全认证平台基于标准的微服务架构,熔断、限流、弹性伸缩等是标配。


微服务解决的问题之一,就是快速迭代,让需求变更不再是问题;


微服务解决的问题之二,是高并发,让性能不再是问题。


派拉统一身份管理与安全认证平台的交付物为Docker镜像与Pass平台集成,根据并发自动启动容器,时刻保证用户体验,使用Docker镜像作为交付,能够更好的保证环境的一致性,做到原子的升级和回滚。







留下您的联系方式,我们专业人员将会为您服务