告别“臃肿”，选择微服务（文末福利）-CSDN博客

点击标题下「异步社区」可快速关注

参与文末话题讨论，每周赠送异步图书

——异步小编

一直以来，系统的架构设计是IT领域经久不衰的话题，也是构建每一个系统最核心且重要的部分之一。它决定了系统能否满足业务、技术、组织、灵活、可扩展性等多种要求，同时肩负起了解放程序员生产力的作用。

2016年底，由于业务的不断发展，我所在公司维护的项目也越来越“臃肿”。随着无数个版本的迭代，以及开发人员的不断增加，开发效率越来越低，每次投产的人力成本和时间成本都逐渐增加，我们一直在思索如何能破局。评估了各种方案后，最终微服务进入了我们的视野。

谈到微服务，大家众说纷纭，但却很难有一个清晰的概念来描述。微服务不是“银弹”，我理解的微服务是一种文化，而我们要做的就是将微服务的理念运用到实际开发中。经过一系列的技术选型，最终Spring Cloud凭借其成熟的组件、完善的一站式解决方案，最终成为了我们落地微服务的选择。

Spring Cloud简介

Spring Cloud作为Java语言的微服务框架，它依赖于Spring Boot，有快速开发、持续交付和容易部署等特点。Spring Cloud的组件非常多，涉及微服务的方方面面，并在开源社区Spring和Netflix、Pivotal两大公司的推动下越来越完善。本文主要介绍Spring Cloud，将从以下方面来讲解。

微服务应该具备的功能。

Spring Cloud介绍。

Dubbo介绍。

Kubernetes介绍。

Spring Cloud与Dubbo比较。

Spring Cloud与Kubernetes比较。

1.1　微服务应该具备的功能

微服务，可以拆分为“微”和“服务”二字。“微”即小的意思，那到底多小才算“微”呢？可能不同的团队有不同的答案。从参与微服务的人数来讲，单个微服务从架构设计、代码开发、测试、运维的人数加起来是8~10人才算“微”。那么何为“服务”呢？按照“微服务”概念提出者Martin Fowler给出的定义：“服务”是一个独立运行的单元组件，每个单元组件运行在独立的进程中，组件与组件之间通常使用HTTP这种轻量级的通信机制进行通信。

微服务具有以下的特点。

按照业务来划分服务，单个服务代码量小，业务单一，易于维护。

每个微服务都有自己独立的基础组件，例如数据库、缓存等，且运行在独立的进程中。

微服务之间的通信是通过HTTP协议或者消息组件，且具有容错能力。

微服务有一套服务治理的解决方案，服务之间不耦合，可以随时加入和剔除服务。

单个微服务能够集群化部署，并且有负载均衡的能力。

整个微服务系统应该有一个完整的安全机制，包括用户验证、权限验证、资源保护等。

整个微服务系统有链路追踪的能力。

有一套完整的实时日志系统。

微服务具有以上这些特点，那么微服务需要具备一些什么样的功能呢？微服务的功能主要体现在以下几个方面。

服务的注册和发现。

服务的负载均衡。

服务的容错。

服务网关。

服务配置的统一管理。

链路追踪。

实时日志。

1.1.1　服务的注册与发现

微服务系统由很多个单一职责的服务单元组成，例如Netflix公司的系统是由600多个微服务构成的，而每一个微服务又有众多实例。由于该系统的服务粒度较小，服务数量众多，服务之间的相互依赖成网状，所以该系统需要服务注册中心来统一管理微服务实例，方便查看每一个微服务实例的健康状态。

服务注册是指向服务注册中心注册一个服务实例，服务提供者将自己的服务信息（如服务名、IP地址等）告知服务注册中心。服务发现是指当服务消费者需要消费另外一个服务时，服务注册中心能够告知服务消费者它所要消费服务的实例信息（如服务名、IP地址等）。通常情况下，一个服务既是服务提供者，也是服务消费者。服务消费者一般使用HTTP协议或者消息组件这种轻量级的通信机制来进行服务消费。服务的注册与发现如图1-1所示。

移除

点击此处添加图片说明文字

▲图1-1　服务的治理—服务的注册和发现

服务注册中心会提供服务的健康检查方案，检查被注册的服务是否可用。通常一个服务实例注册后，会定时向服务注册中心提供“心跳”，以表明自己还处于可用的状态。当一个服务实例停止向服务注册中心提供心跳一段时间后，服务注册中心会认为该服务实例不可用，会将该服务实例从服务注册列表中剔除。如果这个被剔除掉的服务实例过一段时间后继续向注册中心提供心跳，那么服务注册中心会将该服务实例重新加入服务注册中心的列表中。另外，微服务的服务注册组件都会提供服务的健康状况查看的UI界面，开发人员或者运维人员只需要登录相关的界面就可以知道服务的健康状态。

1.1.2　服务的负载均衡

在微服务架构中，服务之间的相互调用一般是通过HTTP通信协议来实现的。网络往往具有不可靠性，为了保证服务的高可用（High Availability），服务单元往往是集群化部署。例如将服务提供者进行集群化部署，那么服务消费者该调用哪个服务提供者的实例呢？这就涉及到了服务的负载均衡。

服务的负载均衡一般最流行的做法如图1-2所示，所有的服务都向服务注册中心注册，服务注册中心持有每个服务的应用名和IP地址等信息，同时每个服务也会获取所有服务注册列表信息。服务消费者集成负载均衡组件，该组件会向服务消费者获取服务注册列表信息，并每隔一段时间重新刷新获取该列表。当服务消费者消费服务时，负载均衡组件获取服务提供者所有实例的注册信息，并通过一定的负载均衡策略（开发者可以配置），选择一个服务提供者的实例，向该实例进行服务消费，这样就实现了负载均衡。

移除

点击此处添加图片说明文字

▲图1-2　服务的负载均衡

服务注册中心不但需要定时接收每个服务的心跳（用来检查服务是否可用），而且每个服务会定期获取服务注册列表的信息，当服务实例数量很多时，服务注册中心承担了非常大的负载。由于服务注册中心在微服务系统中起到了至关重要的作用，所以必须实现高可用。一般的做法是将服务注册中心集群化，每个服务注册中心的数据实时同步，如图1-3所示。

移除

点击此处添加图片说明文字

▲图1-3　将服务注册中心高可用

1.1.3　服务的容错

微服务落地到实际项目中，服务的数量往往非常多，服务之间的相互依赖性也是错综复杂的，一个网络请求通常需要调用多个服务才能完成。如果一个服务不可用，例如网络延迟或故障，会影响到依赖于这个不可用的服务的其他服务。如图1-4所示，一个微服务系统有很多个服务，当服务F因某些原因导致了服务的不可用，来自于用户的网络请求需要调用服务F。由于服务F无响应，用户的请求都处于阻塞状态，在高并发的场景下，短时间内会导致服务器的线程资源消耗殆尽。另外，依赖于服务F的其他的服务，例如图中的服务E、服务G、服务J，也会等待服务F的响应，处于阻塞状态，导致这些服务的线程资源消耗殆尽，进而导致它们的不可用，以及依赖于它们的服务的不可用，最后导致整个系统处于瘫痪的状态也就是1.2.1节中提到的雪崩效应。

移除

点击此处添加图片说明文字

▲图1-4　服务的依赖性

为了解决分布式系统的雪崩效应，分布式系统引进了熔断器机制。熔断器（Circuit Breaker）一词来源于物理学中的电路知识，它的作用是当电路中出现故障时迅速切断电路，起到保护电路的作用，熔断器机制如图1-5所示。当一个服务的处理用户请求的失败次数在一定时间内小于设定的阀值时，熔断器处于关闭状态，服务正常；当服务处理用户请求的失败次数大于设定的阀值时，说明服务出现了故障，打开熔断器，这时所有的请求会执行快速失败，不执行业务逻辑。当处于打开状态的熔断器时，一段时间后会处于半打开状态，并执行一定数量的请求，剩余的请求会执行快速失败，若执行的请求失败了，则继续打开熔断器；若成功了，则将熔断器关闭。

移除

点击此处添加图片说明文字

▲图1-5　熔断器机制

这种机制有着非常重要的意义，它不仅能够防止系统的“雪崩”效应，还具有以下作用。

将资源进行隔离，如果某个服务里的某个API接口出现了故障，只会隔离该API接口。不会影响到其他API接口。被隔离的API接口会执行快速失败的逻辑，不会等待，请求不会阻塞。如果不进行这种隔离，请求会一直处于阻塞状态，直到超时。若有大量的请求同时涌入，都处于阻塞的状态，服务器的线程资源，迅速被消耗完。

服务降级的功能。当服务处于正常的状态时，大量的请求在短时间内同时涌入，超过了服务的处理能力，这时熔断器会被打开，将服务降级，以免服务器因负载过高而出现故障。

自我修复能力。当因某个微小的故障，例如网络服务商的问题，导致网络在短时间内不可用，熔断器被打开。如果不能自我监控、自我检测和自我修复，那么需要开发人员手动地去关闭熔断器，无疑会增加开发人员的工作量。

Netflix的Hystrix熔断器开源组件功能非常强大，不仅有熔断器的功能，还有熔断器的状态监测，并提供界面友好的UI，开发人员或者运维人员通过UI界面能够直观地看到熔断器的状态和各种性能指标。

1.1.4　服务网关

微服务系统通过将资源以API接口的形式暴露给外界来提供服务。在微服务系统中，API接口资源通常是由服务网关（也称API网关）统一暴露，内部服务不直接对外提供API资源的暴露。这样做的好处是将内部服务隐藏起来，外界还以为是一个服务在提供服务，在一定程度上保护了微服务系统的安全。API网关通常有请求转发的作用，另外它可能需要负责一定的安全验证，例如判断某个请求是否合法，该请求对某一个资源是否具有操作权限等。通常情况下，网关层以集群的形式存在。在服务网关层之前，有可能需要加上负载均衡层，通常为Nginx双机热备，通过一定的路由策略，将请求转发到网关层。到达网关层后，经过一系列的用户身份验证、权限判断，最终转发到具体的服务。具体的服务经过一系列的逻辑运算和数据操作，最终将结果返回给用户，此时的架构如图1-6所示。

网关层具有很重要的意义，具体体现在以下方面。

网关将所有服务的API接口资源统一聚合，对外统一暴露，外界系统调用的API接口都是网关对外暴露的API接口。外界系统不需要知道微服务架构中各服务相互调用的复杂性，微服务系统也保护了其内部微服务单元的API接口，防止被外界直接调用以及服务的敏感信息对外暴露。

网关可以做一些用户身份认证、权限认证，防止非法请求操作API接口，对内部服务起到保护作用。

网关可以实现监控功能，实时日志输出，对请求进行记录。

网关可以用来做流量监控，在高流量的情况下，对服务进行降级。

API接口从内部服务分离出来，方便做测试。

当然，网关实现这些功能，需要做高可用，否则网关很可能成为架构中的瓶颈。最常用的网关组件有Zuul、Nginx等。

移除

点击此处添加图片说明文字

▲图1-6　服务网关架构图

1.1.5　服务配置的统一管理

在实际开发过程中，每个服务都有大量的配置文件，例如数据库的配置、日志输出级别的配置等，而往往这些配置在不同的环境中也是不一样的。随着服务数量的增加，配置文件的管理也是一件非常复杂的事。

在微服务架构中，需要有统一管理配置文件的组件，例如Spring Cloud 的Spring Cloud Config组件、阿里的Diamond、百度的Disconf、携程的Apollo等。这些配置组件所实现的功能大体相同，但是又有些差别，下面以Spring Cloud Config为例来阐述服务配置的统一管理。

如图1-7所示，大致过程如下。

首先，Config Server（配置服务）读取配置文件仓库的配置信息，其中配置文件仓库可以存放在配置服务的本地仓库，也可以放在远程的Git仓库（例如GitHub、Coding等）。

配置服务启动后，读取配置文件信息，读取完成的配置信息存放在配置服务的内存中。

当启动服务A、B时，由于服务A、B指定了向配置服务读取配置信息，服务A、B向配置服务读取配置信息。

当服务的配置信息需要修改且修改完成后，向配置服务发送Post请求进行刷新，这时服务A、B会向配置服务重写读取配置文件。

移除

点击此处添加图片说明文字

▲图1-7　服务配置统一管理

对于集群化的服务，可以通过使用消息总线来刷新多个服务实例。如果服务数量较多，对配置中心需要考虑集群化部署，从而使配置中心高可用，做分布式集群。

1.1.6　服务链路追踪

微服务系统是一个分布式架构的系统，微服务系统按业务划分服务单元，一个微服务系统往往有很多个服务单元。由于服务单元数量很多且业务复杂，服务与服务之间的调用有可能非常复杂，一旦出现了异常和错误，就会很难去定位。所以在微服务架构中，必须实现分布式链路追踪，去跟进一个请求到底有哪些服务参与，参与的顺序又是怎样的，从而使每个请求链路清晰可见，出了问题很快就能定位。

举个例子，如图1-8所示，在微服务系统中，一个来自用户的请求先达到前端A（如前端界面），然后通过远程调用，达到系统的中间件B、C（如负载均衡、网关等），最后达到后端服务D、E。后端经过一系列的业务逻辑计算，最后将数据返回给用户。对于这样一个请求，经历了这么多服务，怎么样将它的请求过程的数据记录下来呢？这就需要用到服务链路追踪。

移除

点击此处添加图片说明文字

▲图1-8　请求通过A、B、C、D、E

Google开源了链路追踪组件Dapper，并在2010年发表了论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》，这篇文章是业内实现链路追踪的标杆和理论基础，具有非常高的参考价值。

目前，常见的链路追踪组件有Google的Dapper、Twitter 的Zipkin，以及阿里的Eagleeye （鹰眼）等，都是非常优秀的链路追踪开源组件。

1.2　Spring Cloud

1.2.1　简介

Spring Cloud是基于Spring Boot的。Spring Boot是由Pivotal团队提供的全新Web框架，它主要的特点就是简化了开发和部署的过程，简化了Spring 复杂的配置和依赖管理，通过起步依赖和内置Servlet容器能够使开发者迅速搭起一个Web工程。所以Spring Cloud在开发部署上继承了Spring Boot的一些优点，提高其在开发和部署上的效率。

Spring Cloud的首要目标就是通过提供一系列开发组件和框架，帮助开发者迅速搭建一个分布式的微服务系统。Spring Cloud是通过包装其他技术框架来实现的，例如包装开源的Netflix OSS?组件，实现了一套通过基于注解、Java配置和基于模版开发的微服务框架。Spring Cloud框架来自于Spring Resouces社区，由Pivotal和Netflix两大公司和一些其他的开发者提供技术上的更新迭代。Spring Cloud提供了开发分布式微服务系统的一些常用组件，例如服务注册和发现、配置中心、熔断器、智能路由、微代理、控制总线、全局锁、分布式会话等。

1.2.2　常用组件

（1）服务注册和发现组件Eureka

利用Eureka组件可以很轻松地实现服务的注册和发现的功能。Eureka组件提供了服务的健康监测，以及界面友好的UI。通过Eureka组件提供的UI，Eureka组件可以让开发人员随时了解服务单元的运行情况。另外Spring Cloud也支持Consul和Zookeeper，用于注册和发现服务。

（2）熔断组件Hystrix

Hystrix是一个熔断组件，它除了有一些基本的熔断器功能外，还能够实现服务降级、服务限流的功能。另外Hystrix提供了熔断器的健康监测，以及熔断器健康数据的API接口。Hystrix Dashboard组件提供了单个服务熔断器的健康状态数据的界面展示功能，Hystrix Turbine组件提供了多个服务的熔断器的健康状态数据的界面展示功能。

（3）负载均衡组件Ribbon

Ribbon是一个负载均衡组件，它通常和Eureka、Zuul、RestTemplate、Feign配合使用。Ribbon和Zuul配合，很容易做到负载均衡，将请求根据负载均衡策略分配到不同的服务实例中。Ribbon和RestTemplate、Feign配合，在消费服务时能够做到负载均衡。

（4）路由网关Zuul

路由网关Zuul有智能路由和过滤的功能。内部服务的API接口通过Zuul网关统一对外暴露，内部服务的API接口不直接暴露，防止了内部服务敏感信息对外暴露。在默认的情况下，Zuul和Ribbon相结合，能够做到负载均衡、智能路由。Zuul的过滤功能是通过拦截请求来实现的，可以对一些用户的角色和权限进行判断，起到安全验证的作用，同时也可以用于输出实时的请求日志。

上述的4个组件都来自于Netflix的公司，统一称为Spring Cloud Netflix。

（5）Spring Cloud Config

Spring Cloud Config组件提供了配置文件统一管理的功能。Spring Cloud Config包括Server端和Client端，Server 端读取本地仓库或者远程仓库的配置文件，所有的Client向Server读取配置信息，从而达到配置文件统一管理的目的。通常情况下，Spring Cloud Config和Spring Cloud Bus相互配合刷新指定Client或所有Client的配置文件。

（6）Spring Cloud Security

Spring Cloud Security是对Spring Security组件的封装，Spring Cloud Security向服务单元提供了用户验证和权限认证。一般来说，单独在微服务系统中使用Spring Cloud Security是很少见的，一般它会配合?Spring Security OAuth2?组件一起使用，通过搭建授权服务，验证Token或者JWT这种形式对整个微服务系统进行安全验证。

（7）Spring Cloud Sleuth

Spring Cloud Sleuth是一个分布式链路追踪组件，它封装了Dapper、Zipkin和Kibana等组件，通过它可以知道服务之间的相互依赖关系，并实时观察链路的调用情况。

（8）Spring Cloud Stream

Spring Cloud Stream是Spring Cloud框架的数据流操作包，可以封装RabbitMq、ActiveMq、Kafka、Redis等消息组件，利用Spring Cloud Stream可以实现消息的接收和发送。

上述列举了一些常用的Spring Cloud组件。一个简单的由Spring Cloud构建的微服务系统，通常由服务注册中心Eureka、网关Zuul、配置中心Config和授权服务Auth构成，架构如图1-9所示。

移除

点击此处添加图片说明文字

▲图1-9　一个简单的由Spring Cloud构建的微服务系统

1.2.3　项目一览表

Spring Cloud Config：服务配置中心，将所有的服务的配置文件放到本地仓库或者远程仓库，配置中心负责读取仓库的配置文件，其他服务向配置中心读取配置。Spring Cloud Config使得服务的配置统一管理，并可以在不人为重启服务的情况下进行配置文件的刷新。

Spring Cloud Netflix：它是通过包装了Netflix公司的微服务组件实现的，也是Spring Cloud核心的核心组件，包括Eureka、Hystrix、Zuul、Archaius等。

Eureka：服务注册和发现组件。

Hystrix：熔断器组件。Hystrix通过控制服务的API接口的熔断来转移故障，防止微服务系统发生雪崩效应。另外，Hystrix能够起到服务限流和服务降级的作用。使用Hystrix Dashboard组件监控单个服务的熔断器的状态，使用Turbine组件可以聚合多个服务的熔断器的状态。

Zuul：智能路由网关组件。Netflix Zuul能够起到智能路由和请求过滤的作用，是服务接口统一暴露的关键模块，也是安全验证、权限控制的一道门。

Feign：声明式远程调度组件。

Ribbon：负载均衡组件。

Archaius：配置管理API的组件，一个基于Java的配置管理库，主要用于多配置的动态获取。

Spring Cloud Bus：消息总线组件，常和Spring Cloud Config配合使用，用于动态刷新服务的配置。

Spring Cloud Sleuth：服务链路追踪组件，封装了Dapper、Zipkin、Kibina等组件，可以实时监控服务的链路调用情况。

Spring Cloud Data Flow：大数据操作组件，Spring Cloud Data Flow是Spring XD的替代品，也是一个混合计算的模型，可以通过命令行的方式操作数据流。

Spring Cloud Security：安全模块组件，是对Spring Security的封装，通常配合OAuth2使用来保护微服务系统的安全。

Spring Cloud Consul：该组件是Spring Cloud对Consul的封装，和Eureka类似，它是另一个服务注册和发现组件。

Spring Cloud Zookeeper：该组件是Spring Cloud对Zookeeper的封装，和Eureka、Consul类似，用于服务的注册和发现。

Spring Cloud Stream：数据流操作组件，可以封装Redis、RabbitMQ、Kafka等组件，实现发送和接收消息等。

Spring Cloud CLI：该组件是Spring Cloud对Spring Boot CLI的封装，可以让用户以命令行方式快速运行和搭建容器。

Spring Cloud Task：该组件基于Spring Task，提供了任务调度和任务管理的功能。

Spring Cloud Connectors：用于Paas云平台连接到后端。

1.3　Dubbo简介

Dubbo是阿里巴巴开源的一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务冶理方案。Dubbo广泛用于阿里巴巴的各大站点，有很多互联网公司也在使用这个框架，它包含如下核心内容。

RPC远程调用：封装了长连接NIO框架，如Netty、Mina等，采用的是多线程模式。

集群容错：提供了基于接口方法的远程调用的功能，并实现了负载均衡策略、失败容错等功能。

服务发现：集成了Apache的Zookeeper组件，用于服务的注册和发现。

Dubbo框架的架构图如图1-10所示。

移除

点击此处添加图片说明文字

▲图1-10　Dubbo架构图

Dubbo架构的流程如下。

（1）服务提供者向服务中心注册服务。

（2）服务消费者订阅服务。

（3）服务消费者发现服务。

（4）服务消费者远程调度服务提供者进行服务消费，在调度过程中，使用了负载均衡策略、失败容错的功能。

（5）服务消费者和提供者，在内存中记录服务的调用次数和调用时间，并定时每分钟发送一次统计数据到监控中心。

Dubbo是一个非常优秀的服务治理框架，在国内互联网公司应用广泛。它具有以下特性。

连通性：注册中心负责服务的注册；监控中心负责收集调用次数、调用时间；注册中心、服务提供者、服务消费者为长连接。

健壮性：监控中心宕机不影响其他服务的使用；注册中心集群，任意一个实例宕机自动切换到另一个注册中心实例；服务实例集群，任意一个实例宕机，自动切换到另外一个可用的实例。

伸缩性：可以动态增减注册中心和服务的实例数量。

升级性：服务集群升级，不会对现有架构造成压力。

1.4　Spring Cloud与Dubbo比较

首先从微服务关注点来比较Spring Cloud和Dubbo两大服务框架，如表1-1所示。

表1-1　从微服务关注点比较Spring Cloud和Dubbo

移除

点击此处添加图片说明文字

Spring Cloud拥有很多的项目模块，包含了微服务系统的方方面面。Dubbo是一个非常优秀的服务治理和服务调用框架，但缺少很多功能模块，例如网关、链路追踪等。在项目模块上，Spring Cloud占据着更大的优势。

Spring Cloud的更新速度非常块，Camden.SR5版本发布于2017年2月6日，Camden.SR6版本发布于2017年3月10日，Dalston版本发布于2017年4月12日，基本每个月会发一次版本的迭代。从GitHub的代码仓库来看，Spring Cloud几乎每天都有更新。阿里巴巴于2011年10月开源了Dubbo，开源后的Dubbo发展迅速，大概每2~3个月有一次版本更新。然而，从在2013年3月开始，Dubbo暂停了版本更新，并只在2014年10月发布了一个小版本，修复了一个bug，之后长期处于版本停止更新的状态。直到2017年9月，阿里巴巴中间件部门重新组建了Dubbo团队，把Dubbo列为重点开源项目，并在2017年9～11月期间，一直保持每月一次版本更新的频率。

从学习成本上考虑，Dubbo的版本趋于稳定，文档完善，可以即学即用，没有太大难度。Spring Cloud 基于Spring Boot开发，需要开发者先学会Spring Boot。另外，Spring Cloud版本迭代快，需要快速跟进学习。Spring Cloud文档大多是英文的，要求学习者有一定的英文阅读能力。此外，Spring Cloud文档很多，不容易快速找到相应的文档。

从开发风格上来讲，Dubbo 更倾向于Spring Xml的配置方式，Dubbo官方也推荐这种方式。Spring Cloud基于Spring Boot，Spring Boot采用的是基于注解和JavaBean配置方式的敏捷开发。从开发速度上讲，Spring Cloud具有更高的开发和部署速度。

最后，Spring Cloud 的通信方式大多数是基于HTTP Restful风格的，服务与服务之间完全无关、无耦合。由于采用的是HTTP Rest，因此服务无关乎语言和平台，只需要提供相应API接口，就可以相互调用。Dubbo 的通信方式基于远程调用，对接口、平台和语言有强依赖性。如果需要实现跨平台调用服务，需要写额外的中间件，这也是Dubbo存在的原因。

Dubbo和Spring Cloud拥有各自的优缺点。Dubbo更易上手，并且广泛使用于阿里巴巴的各大站点，经历了“双11”期间高并发、大流量的检验，Dubbo框架非常成熟和稳定。Spring Cloud服务框架严格遵守Martin Fowler 提出的微服务规范，社区异常活跃，它很可能成为微服务架构的标准。

1.5　Kubernetes简介

Kubernetes是一个容器集群管理系统，为容器化的应用程序提供部署运行、维护、扩展、资源调度、服务发现等功能。

Kubernetes是Google运行Borg大规模系统达15年之久的一个经验总结。Kubernetes结合了社区的最佳创意和实践，旨在帮助开发人员将容器打包、动态编排，同时帮助各大公司向微服务方向进行技术演进。

它具有以下特点。

Planet Scale（大容量）：使用Kubernetes的各大公司（包括Google）每周运行了数十亿个容器，这些容器的平台采用同样的设计原则。这些平台在不增加DevOps团队成员的情况下，可以让容器数量增加，节省了人力成本，达到了复用性。

Never Outgrow（永不过时）：无论容器是运行在一个小公司的测试环境中，还是运行在一个全球化企业的大型系统里，Kubernetes都能灵活地满足复杂的需求。同时，无论业务多么复杂，Kubernetes都能稳定地提供服务。

Run Anywhere（随时随地运行）：Kubernetes是开源的，可以自由地利用内部、混合或公共云的基础组件进行部署，让开发者可以将更多的时间和精力投入在业务上，而不是服务部署上。

Kubernetes开源免费，是Google在过去15年时间里部署、管理微服务的经验结晶，所以目前Kubernetes在技术社区也是十分火热。下面来看它提供的功能。

Automatic Binpacking（自动包装）：根据程序自身的资源需求和一些其他方面的需求自动配置容器。Kubernetes能够最大化地利用机器的工作负载，提高资源的利用率。

Self-healing（自我修复）：容器失败自动重启，当节点处于“死机”的状态时，它会被替代并重新编排；当容器达到用户设定的无响应的阀值时，它会被剔除，并且不让其他容器调用它，直到它恢复服务。

Horizontal scaling（横向扩展）：可以根据机器的CPU的使用率来调整容器的数量，只需开发人员在管理界面上输入几个命令即可。

Service discovery and load balancing（服务发现和负载均衡）：在不需要修改现有的应用程序代码的情况下，便可使用服务的发现机制。Kubernetes为容器提供了一个虚拟网络环境，每个容器拥有独立的IP地址和DNS名称，容器之间实现了负载均衡。

Automated rollouts and rollbacks（自动部署或回滚）：Kubernetes支撑滚动更新模式，能逐步替换掉当前环境的应用程序和配置，同时监视应用程序运行状况，以确保不会同时杀死所有实例。如果出现问题，Kubernetes支持回滚更改。

Secret and configuration management（配置管理）：部署和更新应用程序的配置，不需要重新打镜像，并且不需要在堆栈中暴露配置。

Storage orchestration（存储编排）：自动安装所选择的存储系统，无论是本地存储、公共云提供商（如GCP或AWS），还是网络存储系统（如NFS、iSCSI、Gluster、Ceph、Cinder或Flocker）。

Batch execution（批量处理）：除了服务之外，Kubernetes还可以管理批量处理和CI的工作负载，如果需要，可以替换容器，如NFS、iSCSI、Gluster、Ceph、Cinder或Flocker等。

从Kubernetes提供的功能来看，Kubernetes完全可以成为构建和部署微服务的一个工具，它是从服务编排上实现的，而不是代码实现的。目前国外有很多知名的公司在使用Kubernetes，如Google、eBay、Pearson等。由于它的开源免费，Microsoft、VMWare、Red Hat、CoreOS等公司纷纷加入并贡献代码。Kubernetes技术吸引了一大批公司和技术爱好者，它已经成为容器管理的领导者。

1.6　Spring Could与Kubernetes比较

Spring Cloud是一个构建微服务的框架，而Kubernetes是通过对运行的容器的编排来实现构建微服务的。两者从构建微服务的角度和实现方式有很大的不同，但它们提供了构建微服务所需的全部功能。从提供的微服务所需的功能上看，两者不分上下，如表1-2所示。

表1-2　　Spring Cloud与Kubernetes比较

移除

点击此处添加图片说明文字

Spring Cloud通过众多的类库来实现微服务系统所需的各个组件，同时不断集成优秀的组件，所以Spring Cloud组件是非常完善的。Spring Cloud基于Spring Boot框架，有快速开发、快速部署的优点。对于Java开发者来说，学习Spring Cloud的成本不高。

Kubernetes在编排上解决微服务的各个功能，例如服务发现、配置管理、负载均衡、容错等。Kubernetes不局限于Java平台，也不局限于语言，开发者可以自由选择开发语言进行项目开发。

与Kubernetes相比，Spring Cloud具有以下优点。

采用Java语言开发，基于Spring平台，继承了Spring Boot快速开发的优势，是Java程序员实现微服务的最佳实践。

Spring Cloud有大量的类库和资源，基本上能解决所有可能出现的问题。

与Kubernetes比较，Spring Cloud具有以下缺点。

依赖于Java语言，不支持跨语言。

Spring Cloud 需要在代码中关注微服务的功能点，例如服务发现、负载均衡等。Kubernetes则不需要关注这些。

下面介绍Kubernetes的优点和缺点，优点如下。

Kubernetes支持多种语言，并且是一个容器管理平台。Kubernetes使程序容器化，并在容器管理上提供了微服务的功能，例如配置管理、服务发现、负载均衡等。Kubernetes能够被应用于多种场合，例如程序开发、测试环境、创建环境等。

Kubernetes除了提供基本的构建微服务的功能外，还提供了环境、资源限制、管理应用程序的生命周期的功能。Kubernetes更像是一个平台，而Spring Cloud 是一个框架。

Kubernetes的缺点如下。

Kubernetes面向DevOps人员，普通的开发人员需要学习很多这方面的知识，学习成本非常高。

Kubernetes仍然是一个相对较新的平台，发展十分迅速。新特性更新得快，所以需要DevOps人员跟进，不断地学习。

Spring Cloud尝试从Java类库来实现微服务的所有功能，而Kubernetes尝试从容器编排上实现所有的微服务功能，两者的实现角度和方式不一样。个人觉得，两者最终的实现功能和效果上不分胜负，但从实现的方式上来讲，Kubernetes略胜一筹。Kubernetes面向DevOps人员，学习成本高。Spring Cloud有很多的类库，以Spring为基础，继承了Spring Boot快速开发的优点，为Java程序员开发微服务提供了很好的体验，学习成本也较低。所以二者比较，各有优势。没有最好的框架，也没有最好的工具，关键是要适合业务需求和满足业务场景。

1.7　总结

本文首先介绍了微服务应该具备的功能，然后介绍了Spring Cloud和Spring Cloud的基本组件，最后介绍了Spring Cloud与Dubbo、Kubernetes之间的比较，以及它们的优缺点。Spring Cloud作为Java语言的微服务落地框架，有很多的微服务组件。为了循序渐进地学习这些组件，以后章节将介绍构建微服务前的准备工作，这是学习Spring Cloud组件的基本前提。

本文摘自《深入理解Spring Cloud与微服务构建》

移除

点击此处添加图片说明文字

《深入理解Spring Cloud与微服务构建》

方志朋著

点击封面购买纸书

此时的Spring Cloud相关资料在国内还是凤毛麟角，没有完整的中文书籍和教程可以参考，只有官方的英文文档以及网上零零散散的教程可以阅读。就是在这种情况下，本书的作者方志朋在公司技术选型以及后续的微服务落地过程中，逐渐有了自己的积累和理解，同时在博客中连载了“史上最简单的Spring Cloud教程”。此教程一出，就受到广大程序员的欢迎，因此最终整理为此书。

纵览全书，文字清晰明了，通过理论结合实践的方式介绍了Spring Cloud的每一个组件的实践，并解读了部分源代码。图文并茂，语言朴实，不愧为“简单”之名。本书融合了作者实施微服务的一线经