浅谈微服务的CI/CD
近几年微服务架构与容器化技术飞速发展，随之而来的是持续集成与持续交付的概念又重新不断被提及，越来越多的公司开始使用持续集成系统来解决频繁发布带来的质量问题，使用持续交付工具实现代码的自动部署。持续交付
持续交付（Continuous Delivery，CD）是一种软件工程方法，开发团队以快速、自动化和可重复的方式从源代码生成软件发布版本，确保软件可以随时可靠地发布，它更加注重给最终用户提供应用的能力。 随着微服务和云原生架构的广泛采用，对持续交付工具和实践的需求越来越大。微服务带来了许多优点，比如通过把复杂的业务拆分为若干小业务，每个业务写成一个服务，服务足够内聚、足够小，服务的边界也明确，代码会容易理解、开发效率得以提高；每个微服务可以独立部署，让持续部署成为可能；可以提高系统的容错性，不会因为某一个服务的错误导致整个系统瘫痪…… 但是系统中微服务不断增多，需要大量的协调工作才能同步地集成和部署一组微服务，这使得持续交付也变得复杂起来，而脱胎于微服务架构思想的容器技术正是解决这一问题的良药。
简单来说，通过将一个微服务封装在一个容器中，开发者可以在这样一个独立的环境中进行开发，随后测试与运维人员可以直接使用这个容器进行部署并测试与发布，大大简化了软件交付过程。
持续集成
说到持续交付就离不开持续集成，持续集成也就是 Continuous Integration，CI，它与持续交付是什么关系呢？ 持续交付是在持续集成的基础上，将集成后的代码进行发布，供用户使用，它强调的是“给最终用户一个交待”；而持续集成是指开发团队成员经常集成他们的工作，每次集成都通过自动化的构建来验证，包括编译、发布与自动化测试等过程，从而尽快发现集成错误。 持续集成的基本思想是使用一个自动化过程监测源码仓库是否有变更，当变更被推送到仓库时，它会监测到更改、下载副本、构建、部署、运行相关单元测试并发布。 随着公司业务流量、用户数不断增长，无论传统的测试团队如何增加人力，也无法解决软件重构、系统增加新功能等测试需求，持续集成变得困难重重。前边说到微服务架构使得持续交付变复杂，其实这样的复杂性也体现在持续集成中，比如它会带来一些问题：
[*]服务交付周期变短，自动化测试开发速度跟不上交付的速度
[*]多个服务同时开发，联调耗时日益增长
[*]自测时需要部署和维护多个依赖方服务
[*]由于服务数量增多，链路变长，调用依赖增多，整个环境的搭建会十分吃力
[*]多人共用一套环境，互相影响，容易影响测试结果
[*]一次提测服务增多，提测了多个仓库，使得 CI 工作爆炸性增加
[*] ……
然而团队可以基于微服务框架与持续集成系统，打造自动化和流程标准化的持续集成平台，反过来让持续集成为微服务架构强有力的基础设施支持，充分利用微服务的优势。 但是具体怎样去落地呢？当前业内已经有不少团队分享过他们打造微服务持续集成工具链的实践方案，一般情况下，根据不同业务性质与团队特性，每家都有自己面临的问题，并且基于具体问题设计出不同的持续集成方案。 虽然方案不同，但是在传播通用经验方面还是起了不小的作用。在本周末开源中国源创会上，来自阅文集团的后台开发专家与用户中心架构负责人俞慧涛也将为大家分享如何利用微服务框架 Tars 结合 CI/CD 系统 Jenkins 打造持续集成开发测试环境。
页:
[1]