在讨论‘为什么选择Spring Cloud作为微服务架构’这个问题之前，咱们首先来学习一下关于微服务的理论。
微服务是什么？
微服务化的核心就是将传统的单体应用（一体多功能）根据业务拆分成一个一个的服务（一服务一功能），彻底的消除耦合。从技术角度看微服务就是一种小而独立的处理过程，类似进程概念，能够自行单独启动或销毁，拥有自己独立的数据库。
微服务与微服务架构有什么关系？
通俗理解，微服务与微服务架构就是个体与整体之间的关系。比如，学生是微服务，学校是微服务架构；科室是微服务，医院是微服务架构…
微服务的优缺点有哪些？
优点：
- 每个服务足够内聚，足够小，故代码容易理解。
- 能聚焦一个指定的业务功能或业务需求。
- 开发简单、开发效率提高，一个服务就是专心只干一件事。
- 微服务能够被小团队单独开发，小团队开发人员人数2-5人。（浓缩的才是精华）
- 微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。
微服务能使用不同的语言开发。 - 易于和第三方集成，微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如Jenkins, Hudson, bamboo 。
- 微服务允许融合最新技术。
- 微服务只是业务逻辑的代码，不会和HTML、CSS 或其他界面组件混合。
- 每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一数据库。
缺点：
- 分布式系统的复杂性，进而难以管理
- 多服务加大运维难度，随着服务的增加，运维的压力也在增大
- 服务间通信成本增大
- 数据一致性难以保证
- 系统集成测试麻烦
- 分布部署，追踪问题难……
微服务技术栈有哪些？
微服务技术栈：多种技术的集合体
| 项目 | Value |
|---|---|
| 服务开发 | Spring Boot、Spring、Spring MVC |
| 服务配置与管理 | Netflix公司的Archaius、阿里的Diamond等 |
| 服务注册与发现 | Eureka、Consul、Zookeeper等 |
| 服务调用 | Rest、RPC、gRPC |
| 服务熔断器 | Hystrix、Envoy等 |
| 负载均衡 | Ribbon、Nginx等 |
| 服务接口调用(客户端调用服务的简化工具) | Feign等 |
| 消息队列 | Kafka、RabbitMQ、ActiveMQ等 |
| 服务配置中心管理 | Spring Cloud Config、Chef等 |
| 服务路由（API网关） | Zuul等 |
| 服务监控 | Zabbix、Nagios、Metrics、Spectator等 |
| 全链路追踪 | Zipkin，Brave、Dapper等 |
| 服务部署 | Docker、OpenStack、Kubernetes等 |
| 数据流操作开发包 | Spring Cloud Stream（封装与Redis,Rabbit、Kafka等发送接收消息） |
| 事件消息总线 | Spring Cloud Bus |
| … |
最后的重点戏——为什么选择Spring Cloud作为微服务架构？
Spring Cloud提供一整套技术服务（大概21种技术）
SpringCloud，基于Spring Boot提供了一套微服务解决方案，包括服务注册与发现、配置中心、全链路监控、服务网关、负载均衡、熔断器等组件，除了基于NetFlix的开源组件做高度抽象封装之外，还有一些选型中立的开源组件。
Spring Cloud利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，Spring Cloud为开发人员提供了快速构建分布式系统的一些工具，包括配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等,它们都可以用Spring Boot的开发风格做到一键启动和部署。
Spring Cloud并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。
Spring Cloud=分布式微服务架构下的一站式解决方案，是各个微服务架构落地技术的集合体，俗称微服务全家桶
Spring Cloud技术的五大神兽
- 服务发现——Netflix Eureka
- 客服端负载均衡——Netflix Ribbon
- 断路器——Netflix Hystrix
- 服务网关——Netflix Zuul
- 分布式配置——Spring Cloud Config