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

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

前言

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


对于多个项目的 CD

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


软件定义交付(SDD)

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



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


一些讨论

Q:微服务中整套cd流程难点在哪儿?

A:我们发布的是业务,但是每个业务包括多个微服务,那我们根据什么去触发我们的cd的流程?因为我们的微服务没有一个是能够完全定义我们的业务的,这个就是难点,如果还是以微服务项目为出发点去进行cd,你仔细思考一下会发现很复杂。所以我们需要一个能够完整定义我们业务的项目来作为我们cd的中心。这是一种思维的转变,转变后会发现逻辑其实会回归简洁;

Q:我尝试理解一下 为了减少发布复杂度 把微服务之上再加一层 这一层也就是你说的cd中心会把微服务按照业务做一个聚合 然后我们后面只需要管理这一层 然后这一层去管理微服务的发布 来达到降低复杂度的目的?

A:差不多是这个意思,但是最主要的原因是我们的发布应该以业务为中心,当我们以业务为中心并以软件来定义业务交付时,情况自然变得简单了起来。

编辑于 2018-12-01