前言
这篇文章作为我学习SpringCloud的第一课，先来扫盲，再来讲解技术
| 注意：本扫盲贴的内容，我写的都要背熟，要很熟悉的说出来，不要看了就忘。 |
什么是微服务？
微服务提倡将单一应用拆分成一组小服务，每个服务在自己独立的进程中运行。
这就是微服务，例如淘宝，商品，订单，付款等等，如果都做在一起，那么一个模块有问题，势必会影响其他的模块，而且耦合度也高，现在使用微服务技术，把淘宝拆分成商品系统，订单系统，付款系统等等，这样一个偌大的淘宝就拆分成了一组小服务，耦合度大大降低。
微服务的优缺点是什么？
微服务的优点：
- 每个服务足够小，聚焦于一个业务功能或需求
- 代码开发简单，效率高，一个服务只专注于一个功能模块
- 微服务可以小团队开发，2~5人的小团队
- 松耦合，每个小服务都有意义，无论是开发阶段还是部署阶段
- 微服务可以使用不同的语言开发
- 易于和第三方服务集成，比如Jenkins，Hudson，Bambook
- 微服务易于被一个开发人员理解，修改，维护，小团队只需要专注于自己的工作
- 微服务允许你使用融合最新技术
- 微服务只是业务逻辑的代码，不会和HTML，CSS或其他界面组件混合
- 每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一的数据库
微服务的缺点：
- 开发人员要处理分布式系统的复杂性
- 微服务数量多，运维难度增加
- 系统部署依赖
- 各个微服务之间通信的成本增加
- 数据的一致性问题
- 系统集成测试
- 性能监控
微服务之间是如何通讯的？
同步：RPC，REST等
异步：消息队列。要考虑消息可靠传输、高性能，以及编程模型的变化等。
SpringCloud和Dubbo有哪些区别？
这个区别只有自己使用过两种服务之后才能真正明白。
我目前所知，SpringCloud很强，而且更新的很快。Dubbo是阿里的，断更了5年，现在虽然重启了更新，但还是更新的慢，所以我打算先学SpringCloud，Dubbo等等再说。
给个表格参考一下
| Dubbo | SpringCloud | |
|---|---|---|
| 服务注册中心 | Zookeeper | SpringCloud Netflix Eureka |
| 服务调用方式 | RPC | Rest API |
| 服务监控 | Dubbo-monitor | SpringBoot Admin |
| 断路器 | 不完善 | SpringCloud Netflix Hystrix |
| 服务网关 | 无 | SpringCloud Netflix Zuul |
| 分布式配置 | 无 | SpringCloud Config |
| 服务跟踪 | 无 | SpringCloud Sleuth |
| 消息总线 | 无 | SpringCloud Bus |
| 数据流 | 无 | SpringCloud Stream |
| 批量任务 | 无 | SpringCloud Task |
SpringCloud和SpringBoot的关系？
- SpringBoot是微观的，只关注于一个服务的实现。而SpringCloud不同，SpringCloud是分布式微服务的一站式解决方案，它关注的是宏观的。
- SpringBoot不依赖于SpringCloud，而SpringCloud依赖于SpringBoot。我举个栗子，SpringBoot就是医院的科室，可以是耳喉鼻科，可以是心脏科，可以是骨科。而SpringCloud就是医院。科室可以不依赖医院，就是小诊所。而医院不能没有科室。这就是二者的关系。
什么是服务熔断？什么是服务降级？
所谓的服务熔断，就是为了保证服务的可用性，对于某个出现故障的服务进行停用。就是把故障服务关闭。
服务降级呢就是你熔断的服务已经不可用了，外部想访问也访问不了，这个时候可以使用fallback回调，返回一个缺省值，意思就是我这个服务熔断了，现在已经关闭，暂时无法访问。
微服务的技术栈有哪些？
| 微服务条目 | 技术 |
|---|---|
| 服务开发 | SpringBoot，Spring，SpringMVC |
| 服务配置与管理 | Archaius，Diamond |
| 服务注册与发现 | Eureka，Consul，Zookeeper |
| 服务调用 | Rest，RPC，gRPC |
| 服务熔断器 | Hystrix，Envoy |
| 负载均衡 | Ribbon，Nginx |
| 服务接口调用 | Feign |
| 消息队列 | Kafka，RabbitMQ，ActiveMQ |
| 服务配置中心管理 | SpringCloudConfig，Chef |
| 服务路由(API网关) | Zuul |
| 服务监控 | Zabbix，Nagios，Metrice，Spectator |
| 全链路追踪 | Zipkin，Brave，Dapper |
| 服务部署 | Docker，OpenStack，Kubernetes |
| 数据流操作开发包 | SpringCloud Stream |
| 时间消息总线 | SpringCloud Bus |
eureka和zookeeper都可以提供服务注册和发现的功能，区别是什么？
讲区别之前，我先讲讲分布式领域的著名定理CAP，所谓的CAP就是
C数据一致性，A服务可用性，P分区容错
这三个指标不可能同时做到，目前的技术，最多只能同时解决两个。
关于CAP，可以看看阮一峰的文章CAP介绍
eureka是AP，Zookeeper是CP
这是第一大区别，eureka保证的是可用性，Zookeeper保证的是一致性。但就这方面来说，访问量很大很频繁的网站，例如淘宝，在双十一期间肯定使用AP，不同的人可能看到的信息不同，不一致，但是必须可用，你不能说我上淘宝结果访问不了信息。
eureka节点平等，Zookeeper需要选举
这是第二大区别，eureka的每个节点都是平等的，例如我有三个eureka服务中心，挂了一个没事，挂了两个也没事，只要有一个eureka服务中心在就可以用，直接切换。
Zookeeper需要选举，leader节点挂了之后，Zookeeper会对剩下的节点进行选举，重新选一个leader节点，这个过程耗时30s~120s，在选举的期间，整个Zookeeper集群都是不可用的，这是灾难。
我举个例子，一栋住宅楼建好了，人们去买房。eureka是这样的，售楼人员帮助你买房，就算这个售楼人员请假了，没事，其他售楼人员也可以接待你。
Zookeeper就牛逼了，售楼人员的leader请假了，他们需要重新选举一个leader售楼人员，你去买房，他告诉你，等我们几个小时，我们正在选举......
所以，很多人都说，eureka比Zookeeper更适合做服务注册。