阿里技术专家：持续交付与微服务背后的实践逻辑

上图是一个持续集成流水线的不同状态的样子.可以看到刚开始的两个stage,代码检出和集成测试,是由代码提交自动触发的.到了第三个stage,也就是部署测试环境,就需要手工批准了,所以出现了一个按钮给你按.后续的预发和生产环境也都类似.

持续交付部分就讲到这里,下面是个小结：

接下来我们再聊聊微服务.

关于微服务的概念,《微服务设计》一书给出的定义是：一些协同工作的小而自治的服务.微服务能够带来很多的好处,帮助我们更好的进行持续交付.当然微服务本身也需要很多实践的支撑,比如Martin Fowler就在他的bliki(http://martinfowler.com/bliki/MicroservicePrerequisites.html)中提到了“You must be this tall to use microservices”.而这个’tall’中的很多内容都已经涵盖前面讨论的那些持续交付的技术实践中.所以可以说微服务和持续交付也是相辅相成的关系.

使用微服务之后,显然你需要部署的服务就会增多.如果一个服务的自动化部署和相应的流水线都没有做好,那么服务多了之后部署的复杂性就可想而知了.所以只有把持续交付的实践先做好,才有可能顺利地使用微服务.

反过来看,微服务架构下,每个服务都很小.因此如果我的某次修改只涉及了一个微服务的代码,我只需要发布这一个服务即可.那么相应的测试工作也就简单的多.

其实按理说,虽然服务拆开了,但是还是需要这些服务在一起才能完成整个系统的功能.所以只修改一个服务,还是有可能影响整个系统的功能的.但是因为它们是不同的服务,所以一定会有非常清晰的API接口.这种API接口其实跟一个单块系统中的模块化的概念很类似.只不过API容易做的清晰,而单块系统中的模块化的边界很难维持.所以从这个角度看,微服务带来的其实是“强制的模块化”,从而带来更好的设计.

好的,话说回来.既然每次发布只涉及到需要修改的那些微服务,那么影响的面就相应的较小,所以就可以更加放心大胆的去做发布,也就进一步促进了持续交付.

微服务所涉及的话题非常多,大家可以移步《微服务设计》这本书查看所有的话题.这里只分享一点,那就是使用渐进式的方式进行微服务化.当然其实“渐进式”是我做大部分变动时的一个通用原则,比如重构,架构变化等.

渐进式微服务化的一个场景就是当你要新做一块相对来说比较大,而且比较独立的功能时,就可以考虑,是否可以单独写在一个服务中.举个例子,若干年前我在一个比较大的Java Spring项目上工作.然后客户有了一块新的业务,最终希望以主站上的一个tab页的形式存在.但我们都不想在这个陈旧的系统上继续开发.最终的方式就是新启一个应用.使用当时开发效率最高的技术.

（编辑：网站开发网_盐城站长网 ）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!