什么是微服务架构
微服务是系统架构上的一种设计风格， 它的主旨是将一个原本独立的系统拆分成多个小型服务，这些小型服务都在各自独立的进程中运行，服务之间通过基于HTTP的RESTful API进行通信协作。 被拆分成的每一个小型服务都围绕着系统中的某一项或一些耦合度较高的业务功能进行构建， 并且每个服务都维护着自身的数据存储、 业务开发、自动化测试案例以及独立部署机制。 由千有了轻量级的通信协作基础， 所以这些微服务可以使用不同的语言来编写。
微服务与单体系统的区别
在传统的项目中我们通常将需求分为三个主要部分： 数据库、 服务端处理、 前端展现。 在业务发展初期， 由于所有的业务逻辑在一个应用中， 开发、 测试、 部署都还比较容易且方便。 但是， 随着企业的发展， 系统为了应对不同的业务需求会不断为该单体项目增加不同的业务模块； 同时随着移动端设备的进步， 前端展现模块已经不仅仅局限于Web的形式， 这对千系统后端向前端的支持需要更多的接口模块。 单体应用由千面对的业务需求更为宽泛， 不断扩大的需求会使得单体应用变得越来越臃肿。 单体应用的问题就逐渐凸显出来， 由于单体系统部署在一个进程内， 往往我们修改了一个很小的功能， 为了部署上线会影响其他功能的运行。 并且， 单体应用中的这些功能模块的使用场景、 并发量、 消耗的资源类型都各有不同， 对于资源的利用又互相影响， 这样使得我们对各个业务模块的系统容量很难给出较为准确的评估。 所以， 单体系统在初期虽然可以非常方便地进行开发和使用，但是随着系统的发展， 维护成本会变得越来越大， 且难以控制。
为了解决单体系统变得庞大脯肿之后产生的难以维护的问题， 微服务架构诞生了并被大家所关注。 我们将系统中的不同功能模块拆分成多个不同的服务， 这些服务都能够独立部署和扩展。 由于每个服务都运行在自己的进程内， 在部署上有稳固的边界， 这样每个服务的更新都不会影响其他服务的运行。 同时， 由千是独立部署的， 我们可以更准确地为每个服务评估性能容量， 通过配合服务间的协作流程也可以更容易地发现系统的瓶颈位置，以及给出较为准确的系统级性能容量评估。
为什么选择Spring Cloud
简单来说，服务化的核心就是将传统的一站式应用根据业务拆分成一个一个的服务，而微服务在这个基础上要更彻底地去耦合（不再共享DB、KV，去掉重量级ESB），并且强调DevOps和快速演化。这就要求我们必须采用与一站式时代、泛SOA时代不同的技术栈，而Spring Cloud就是其中的佼佼者。
DevOps是英文Development和Operations的合体，他要求开发、测试、运维进行一体化的合作，进行更小、更频繁、更自动化的应用发布，以及围绕应用架构来构建基础设施的架构。这就要求应用充分的内聚，也方便运维和管理。这个理念与微服务理念不谋而合。
接下来我们从服务化架构演进的角度来看看为什么Spring Cloud更适应微服务架构。点击这里查看Spring系列教程集合。
从使用nginx说起
最初的服务化解决方案是给提供相同服务提供一个统一的域名，然后服务调用者向这个域名发送HTTP请求，由Nginx负责请求的分发和跳转。
这种架构存在很多问题：
Nginx作为中间层，在配置文件中耦合了服务调用的逻辑，这削弱了微服务的完整性，也使得Nginx在一定程度上变成了一个重量级的ESB。
服务的信息分散在各个系统，无法统一管理和维护。每一次的服务调用都是一次尝试，服务消费者并不知道有哪些实例在给他们提供服务。这不符合DevOps的理念。
无法直观的看到服务提供者和服务消费者当前的运行状况和通信频率。这也不符合DevOps的理念。
消费者的失败重发，负载均衡等都没有统一策略，这加大了开发每个服务的难度，不利于快速演化。
为了解决上面的问题，我们需要一个现成的中心组件对服务进行整合，将每个服务的信息汇总，包括服务的组件名称、地址、数量等。服务的调用方在请求某项服务时首先通过中心组件获取提供这项服务的实例的信息（IP、端口等），再通过默认或自定义的策略选择该服务的某一提供者直接进行访问。所以，我们引入了Dubbo。
基于Dubbo实现微服务
Dubbo是阿里开源的一个SOA服务治理解决方案，文档丰富，在国内的使用度非常高。
使用Dubbo构建的微服务，已经可以比较好地解决上面提到的问题
- 调用中间层变成了可选组件，消费者可以直接访问服务提供者。
- 服务信息被集中到Registry中，形成了服务治理的中心组件。
- 通过Monitor监控系统，可以直观地展示服务调用的统计信息。
- Consumer可以进行负载均衡、服务降级的选择。
但是对于微服务架构而言，Dubbo也并不是十全十美的：
Registry严重依赖第三方组件（zookeeper或者redis），当这些组件出现问题时，服务调用很快就会中断。
Dubbo只支持RPC调用。使得服务提供方与调用方在代码上产生了强依赖，服务提供者需要不断将包含公共代码的jar包打包出来供消费者使用。一旦打包出现问题，就会导致服务调用出错。
最为重要的是，Dubbo现在已经重新维护了，对于技术发展的新需求，需要由开发者自行拓展升级。这对于很多想要采用微服务架构的中小软件组织，显然是相当合适的。
Github社区上有一个DUBBO的升级版，叫DUBBOX，提供了更高效的RPC序列化方式和REST调用方式。但是该项目也基本停止维护了。
新的选择 Spring Cloud
作为新一代的服务框架，Spring Cloud提出的口号是开发“面向云环境的应用程序”，它为微服务架构提供了更加全面的技术支持。
Spring Cloud与DUBBO对比：
微服务需要的功能 | Dubbo | Spring Cloud |
|---|---|---|
服务注册和发现 | Zookeeper | Eureka |
服务调用方式 | RPC | Restful Api |
断路器 | 有 | 有 |
负载均衡 | 有 | 有 |
服务路由和过滤 | 有 | 有 |
分布式配置 | 无 | 有 |
分布式锁 | 无 | 计划开发 |
集群选主 | 无 | 有 |
分布式消息 | 无 | 有 |
Spring Cloud抛弃了Dubbo的RPC通信，采用的是基于HTTP的REST方式。严格来说，这两种方式各有优劣。虽然从一定程度上来说，后者牺牲了服务调用的性能，但也避免了上面提到的原生RPC带来的问题。而且REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖，这在强调快速演化的微服务环境下，显得更加合适。
Eureka相比于zookeeper，更加适合于服务发现的场景。
很明显，Spring Cloud的功能比Dubbo更加强大，涵盖面更广，而且作为Spring的拳头项目，它也能够与Spring Framework、Spring Boot、Spring Data、Spring Batch等其他Spring项目完美融合，这些对于微服务而言是至关重要的。前面提到，微服务背后一个重要的理念就是持续集成、快速交付，而在服务内部使用一个统一的技术框架，显然比把分散的技术组合到一起更有效率。更重要的是，相比于Dubbo，它是一个正在持续维护的、社区更加火热的开源项目，这就保证使用它构建的系统，可以持续地得到开源力量的支持。
Spring Cloud简介
Spring Cloud是一个基千Spring Boot实现的微服务架构开发 工具。 它为微服务架构中涉及的 配置管理、 服务治理、 断路器、 智能路由、 微代理、 控制总线、 全局锁、 决策竞选、分布式会话和集群状态管理等操作提供了一种简单的开发方式。 Spring Cloud包含了多个子项目（针对分布式系统中涉及的多个不同开源产品，还可能会新增）， 如下所述。 Spring Cloud Config: 配置管理工具， 支持使用Git存储 配置内容， 可以使用它实现应用配置的外部化存储， 并支持客户端配置信息刷新、 加密／解密配置内容 等。
- Spring Cloud Netflix: 核心 组件， 对多个Netflix OSS开源套件进行整合。
- Eureka: 服务治理组件， 包含服务注册中心、 服务注册与发现机制的实现。
- Hystrix: 容错管理组件，实现断路器模式， 帮助服务依赖中出现的延迟和为故障提供强大的容错能力。
- Ribbon: 客户端负载均衡的服务调用组件。
- Feign: 基于伈bbon 和 Hystrix 的声明式服务调用组件。
- Zuul: 网关组件， 提供智能路由、 访问过滤等功能。
- Archaius: 外部化配置组件。
- Spring Cloud Bus: 事件、 消息总线， 用于传播集群中的状态变化或事件， 以触发后续的处理， 比如用来动态刷新配置等。
- Spring Cloud Cluster: 针对 ZooKeeper、 Redis、 Hazelcast、 Consul 的选举算法和通用状态模式的实现。
- Spring Cloud Cloudfoundry: 与 Pivotal Cloudfoundry 的整合支持。
- Spring Cloud Consul: 服务发现与配置管理工具。
- Spring Cloud Stream: 通过 Redis、 Rabbit 或者 Kafka 实现的消费微服务， 可以通过简单的声明式模型来发送和接收消息。 Spring Cloud AWS: 用千简化整合 Amazon Web Service 的组件。
- Spring Cloud Security: 安全工具包， 提供在 Zuul 代理中对 0Auth2 客户端请求的中继器。
- Spring Cloud Sleuth: Spring Cloud 应用的分布式跟踪实现， 可以完美整合 Zip虹n。
- Spring Cloud ZooKeeper: 基于 ZooKeeper 的服务发现与配置管理组件。
- Spring Cloud Starters: Spring Cloud 的基础组件， 它是基于 Spring Boot 风格项目的基础依赖模块。
- Spring Cloud CLI: 用于在 Groovy 中快速创建 Spring Cloud 应用的 Spring Boot CLI插件。
- ......
