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

上图是一个持续集成流水线的不同状态的样子.可以看到刚开始的两个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页的形式存在.但我们都不想在这个陈旧的系统上继续开发.最终的方式就是新启一个应用.使用当时开发效率最高的技术.

那么怎么做到存在主站上的一个tab呢?答案是使用nginx集成.为了不暴漏客户信息,下面我们会用一些加的信息.这个应用的所有url都在/new_app/下.在主站的nginx配置中加上一条转发的规则,把/new_app/*这样的url,都转发到新部署的应用上.

Q1：使用Docker部署微服务持续交付时,应该注意什么?你们的Docker使用情况是怎样的?

A1：我现在做的是一款持续交付产品,本身会有一个构架集群,执行任务使用的是Docker,但集群软件本身并没有使用Docker来不熟.不然就是在Docker中运行Docker了,性能会有些影响.

前端的portal正在做Docker化,还没有应用到生产环境中.一个可以分享的就是,要把自己的应用的相关配置都环境变量化,这样对于Docker化比较友好.

我们还有一个产品是code.aliyun.com.这个产品也没有Docker化,或者说『不可变服务器化』,原因就是因为要在本地磁盘写代码库.

所以上面提到对本地读写要求比较高的应用做『不可变服务器』还是有些困难的.

Q2：你们目前关注的持续集成的量化指标有哪些?比如项目单元测试/接口测试/静态检查等方面的内容.整个持续集成有效运转的效率如何?失败了怎么办?怎么保证交付系统的稳定性?

（编辑：青岛站长网）

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