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