对于微服务 CD 中对于 SDD 的一些思考

167 阅读2分钟
原文链接: zhuanlan.zhihu.com

前言

在我们的微服务的体系当中,我们的服务被拆分成了多个细粒度的业务领域清晰的服务,但是由于服务的增多,也给我们的发布 CD 实践带来了挑战;

对于多个项目的 CD

这听起来就是一个很复杂的定义,这会让我们去思考一些复杂的问题,哪个项目有变更时触发 CD 的流程?在 CD 的流程中我们应该怎么去跟其他的项目进行交互?直觉告诉我不应该是这么复杂的一个流程,如果我们的流程一定需要这么复杂,那么一定是我们某个地方出了问题,所以我们可能需要换一个思路找到解决的办法;

软件定义交付(SDD)

最近看到了软件定义交付(SDD)宣言,这个名字给了我一些启发;结合之前看到过关于 GitOps 相关的一些文章,那么我们是不是可以在 CD 的流程当中把我们对于微服务项目的关注点进行转移,因为我们实际交互的使我们的业务实现(代码在作为业务实现时才能体现他的价值),所以我们应该更加的关注我们的业务点(即由我们多个微服务组成)的交互;那么我们是不是可以基于我们的业务建立一个定义交互软件的项目(在 k8s 中 helm 很好的做到了这一点),然后在该项目中进行整合我们的 CD 流程,因为该项目包含了我们交互业务的定义,所以它是能够代表我们的业务交付,同时也可以在它上面进行测试与E2E测试的;

总结自己近期的一些思考,欢迎讨论评论