将应用程序部署到 Kubernetes 时，有很多选择。像 Helm 和 Ksonnet 这样的工具使得打包应用程序并将其部署到多个 Kubernetes 环境变得非常简单。但是，这些工具只能解决部分问题。部署到生产很少像 helm install my-chart 一样如此简单。他们可以涉及多个步骤，并保证所涉及的应用程序正常运行。我从 Kubernetes 用户那里听到的一个最常见的问题是“如何部署我的数据库变更？”。这是我一遍又一遍地问自己的问题。在 Skuid ，我们花了很多时间试图找出最安全和高可用的方式来执行这些数据库迁移，作为我们部署 Pipeline 的一部分。我们写的代码来做到这一小步在我们的 Pipeline 步骤是很复杂的。
Spinnaker 是 Netflix 开源出来的持续交付工具，目的是为研发团队提供灵活的持续交付流水线，并且支持部署到测试/生产环境。Netflix 目前通过 Spinnaker 实现每天4000次的发布。它的优势在于：
断断续续看Ribbon的源码差不多也有7-8天了，总算告一段落。本文记录了这些天对源码的阅读过程与一些分析理解，如有不对还请指出。
在之前介绍使用Ribbon进行服务消费的时候，我们用到了RestTemplate，但是熟悉Spring的同学们是否产生过这样的疑问：RestTemplate不是Spring自己就有的吗？跟Ribbon的客户端负载均衡又有什么关系呢？下面在本文，我们来看RestTemplate和Ribbon是如何联系起来并实现客户端负载均衡的。
看过之前文章的朋友们，相信已经对Eureka的运行机制已经有了一定的了解。为了更深入的理解它的运作和配置，下面我们结合源码来分别看看服务端和客户端的通信行为是如何实现的。另外写这篇文章，还有一个目的，还是希望鼓励大家能够学会学习和研究的方法，由于目前Spring Cloud的中文资料并不多，并不是大部分的问题都能找到现成的答案，所以其实很多问题给出一个科学而慎重的解答也都是花费研究者不少精力的。
在看具体源码前，我们先回顾一下之前我们所实现的内容，从而找一个合适的切入口去分析。首先，服务注册中心、服务提供者、服务消费者这三个主要元素来说，后两者（也就是Eureka客户端）在整个运行机制中是大部分通信行为的主动发起者，而注册中心主要是处理请求的接收者。所以，我们可以从Eureka的客户端作为入口看看它是如何完成这些主动通信行为的。
在上一篇《Spring Cloud构建微服务架构（一）服务注册与发现》中，我们已经成功创建了“服务注册中心”，实现并注册了一个“服务提供者：COMPUTE-SERVICE”。那么我们要如何去消费服务提供者的接口内容呢？
Ribbon是一个基于HTTP和TCP客户端的负载均衡器。Feign中也使用Ribbon，后续会介绍Feign的使用。
Ribbon可以在通过客户端中配置的ribbonServerList服务端列表去轮询访问以达到均衡负载的作用。
Spring Cloud是一个基于Spring Boot实现的云应用开发工具，它为基于JVM的云应用开发中的配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等操作提供了一种简单的开发方式。
Spring Cloud包含了多个子项目（针对分布式系统中涉及的多个不同开源产品），比如：Spring Cloud Config、Spring Cloud Netflix、Spring Cloud CloudFoundry、Spring Cloud AWS、Spring Cloud Security、Spring Cloud Commons、Spring Cloud Zookeeper、Spring Cloud CLI等项目。
