1、RPC（远程调用）
两个核心的模块：1. 通讯 2. 序列化（数据传输的转换）
2、Dubbo (RPC通信框架)
说白了就是个远程服务调用的分布式框架（告别Web Service模式中的WSdl，以服务者与消费者的方式在dubbo上注册）
2.1 Dubbo内置了哪几种服务容器？
Spring Container
Jetty Container
Log4j Container
2.2 Dubbo提供了三大核心能力
面向接口的远程方法的调用
智能容错和负载均衡
服务自动注册和发现
2.3、zookeeper注册中心
3、具体的实现步骤
前提：zookeeper的服务已经开启
提供者
- 导入依赖
- 配置注册中心的地址，以及服务发现名，和要扫描的包 （注册中心的地址，可以在任何一个电脑上！）
- 在想要的被注册的服务上面 增加一个注解service
消费者
- 导入依赖
- 配置注册中心的地址，以及服务发现名，和要扫描的包
- 从远程拿到对应的服务 @Reference
4、未来微服务的学习方向
微服务的架构：新架构
模块化，功能化
用户、签到、娱乐。。等模块进行分离来
一台服务器解决不了，增加服务器，进行横向扩展
假设A服务器占用了98%的资源，B服务器只占用了10% --负载均衡
将原来的整体项目，分成模块化，用户就是一个单独的项目，签到也是一个单独的项目，项目和项目之前需要通信，如何通信？
用户非常多，而签到的非常少！ 给用户多一点服务器，给签到少一点服务器（模块之间的调整）\
因此微服务架构将会遇到四个核心问题（服务就是一个个模块）？
- 1.这么多服务。客户端如何去访问？
- 2.这么多服务，服务之间如何进行通信？
- 3.这么多服务，如何治理呢？
- 4.这么多服务，服务挂了，怎么办
SpringCloud是一套生态，来解决以上分布式架构的四个问题
首先是 SpringCloud NetFlix，除了一套解决的方案
- 客户端的访问需要API网关，zuul组件
- Feign httoClient->基于http的通信方式
- 服务注册与发现 Eureka
- 熔断机制 hystrix
后来是Apache Dubbo zookeper,第二套的解决方案
- 针对于这么多服务，客户端如何去访问？ 无实现，调用第三方的网关
- 服务之间通过高性能RPC的Dubbo框架进行通信（java） 底层是Netty
- 服务注册与发现，使用zookeeper (可管理的hadoop,hive)
- 熔断机制 借用hystrix来解决服务挂了，进行熔断降级
再后来，使用SpringCloud Alibaba一站式解决方案
总结：四个方向的实现
- API网关，服务路由
- HTTP，RPC框架，异步调用
- 服务注册与发现 zookeeper,实现高可用
- 熔断机制，服务降级
