2023年03月19日 13:56:15 来源:上海派拉软件股份有限公司 >> 进入该公司展台 阅读量:0
持续集成对于微服务的意义
一谈到微服务,大家首先想到的是如何拆的问题:拆的粒度、拆的时机、拆的方式。
这当然没错,但要提供一个完整的服务,不是将每个微服务都开发完成就结束了。
大家可以想象将一辆整车拆成零件,然后再组装回去的过程,就可以知道拆虽不容易,合则更难,需要各种标准,各种流水线,才能将零件组装成车。
那么接下来让我们来看下软件拆的过程:
之前的单体应用:一个Java后端和一个数据库便搞定了;
数据量增大,单体架构无法支撑,架构变更,最外面接入Nginx负载均衡,数据库使用一主多从,进行读写分离等等。
这时候系统庞大,但实际服务的仍是单体应用的java后台,当客户不断提出新需求,业务逻辑开始交织,质量开始无法保证,灾难开始。
现在的微服务架构
微服务,优化架构,对业务解耦。
接入层的设计、服务发现-服务编排、消息队列与异步化、配置中心、日志中心、熔断限流降级、缓存、数据库-分布式数据库-分布式事务,再到无状态化、容器化….
业务解耦,微服务变多,如何让各服务顺畅的动起来尤其重要。
那么,如何让各微服务“互动起来”呢?
持续集成要上场了…..
持续集成就是让微服务不断的尝试在一起,就是制定一系列流程,将需要在一起的各个层次规范起来,方便微服务在一起,强迫微服务在一起,完成特定业务功能。
DevOps就是实现强迫微服务在一起的工具,工具有很多,在此就不展开了。
可以参考:/jenkins/
https://juejin.im/post/5ca8082df265dabd
想做好持续集成靠仅有的工具和流程是不够的,还需要文化。
因为微服务之后,模块繁多,让少数的运维能够很好的管理所有的服务,压力很大并容易出错。
但开发往往被分成很多个团队,每个模块负责自己的部署,则不易出错,所以一部分运维工作就需要交给研发来做,需要将研发和运维打通。
如果企业没有这个互通概念,持续集成也基本凉凉..
有了这个文化,还需要日常管理流程来保证持续集成的有效运行。
比如,每天早上,件事情就是开站会, 一起说我昨天做了什么,今天打算做什么,有什么阻碍,这个站会对于开发有比较大的压力。
例如你的一个功能block了依赖方的开发,在会议上会暴露出来,大家都知道这件事情了,一天block,两天block,第三天你都不好意思去说了…
到了晚上,一天的成果物要提交,持续集成要求每天都提交代码,这样才能降低代码集成的风险。
如果埋头写一周一起提交,这样往往集成不成功。
提交不是马上进入主库,而是需要通过代码审核、审核完成还要通过静态代码检查、通过单元测试,编译完成之后上传nexus,生成Dockerfile。
凌晨,会有自动化的脚本将Docker镜像通过编排部署一个完整的环境,然后跑集成测试用例,测试不通过,则会发出邮件来,是因为当天谁的哪个提交,导致测试不通过,抄送所有人,这是另一个压力,因为第二天的早会上会过昨晚的问题。
通过日常管理过程,层层保证质量。
然而持续集成只是开始,持续交付、持续部署才是目标,持续改进才是重点,这个厉害了,在此我们也不展开了…
So,持续集成更是一种研发能力的象征。
持续集成、持续交付、持续改进,这么好的实践我们没有理由拒绝,在派拉的产品研发过程中都进行了实践并取得了良好的成果。
派拉统一身份管理与安全认证平台基于标准的微服务架构,熔断、限流、弹性伸缩等是标配。
微服务解决的问题之一,就是快速迭代,让需求变更不再是问题;
微服务解决的问题之二,是高并发,让性能不再是问题。
派拉统一身份管理与安全认证平台的交付物为Docker镜像与Pass平台集成,根据并发自动启动容器,时刻保证用户体验,使用Docker镜像作为交付,能够更好的保证环境的一致性,做到原子的升级和回滚。