springcloud_01微服务概念

2 微服务的实现:
    2.1 RPC和HTTP:
    RPC: 远程过程调用,类似的还有RMI.自定义数据格式,基于原生的TCP通信,早期的webservice,现在热门的dubbo,都是RPC的典型代表
    HTTP: 基于TCP,规定了数据传输格式,也可以用来远程服务调用,缺点是封装臃肿,优势是对服务的提供和调用方法没有任何限定,自由灵活,更符合微服务的概念
          现在热门的Rest风格,就可以通过http协议来实现
    如果你们公司全部采用Java技术栈,那么使用dubbo作为微服务架构是不错的选择
    相反,如果技术栈多样化,而且你更青睐于Spring家族, 那么使用SpringCloud搭建微服务是不二之选,使用HTTP方式实现服务之间的调用

3 HTTP客户端工具
    既然微服务选择了HTTP,那么我们就需要考虑自己来实现对请求和响应的处理,不过开源世界已经有很多http的客户端工具,能够帮我们做这些事情
    如: HttpClient(阿帕奇), OKHttp, HttpUrlConnection(JDK原生)
    不过这些不同的客户端, API各不相同, 那么我们学习Spring的RestTemplate

4 Spring的RestTemplate:
    RestTemplate对基于HTTP的客户端进行了封装,并且实现了对象与json的序列化和反序列化,非常方便,RestTemplate并没有限定Http的
    客户端类型,而是进行了抽象,目前常用的3种都有支持
    HttpClient, OkHttp, JDK原生的HttpUrlConnecion(默认的)


5 SpringCloud是Spring旗下的项目之一:
    Netflix:
        Eureka: 注册中心
        Zuul: 服务网关
        Ribbon: 负载均衡
        Feign: 服务调用
        Hystix: 熔断器

实现两台服务器, 一台服务器访问另外一台服务器的服务, 实现RestTemplate的HTTP请求方式

github: https://github.com/2402zmybie/cloud01
其中user-service对外提供了查询用户的接口; consumer通过RestTemplate访问接口,查询用户数据. 但存在问题: 

1 在consumer中, 我们把url地址硬编码到了代码中, 不方便后期维护

2 consumer需要记忆user-service的地址, 如果出现变更,可能得不到通知,地址将失效

3 consumer不清楚user-service的状态, 服务器挂掉也不知道

4 user-service只有1台服务,不具备高可用性

5 即使user-service形成集群, consumer还需自己实现负载均衡(请求的平均分发)

 

以上的问题, 我们都将在SpringCloud中得到答案 

Eureka注册中心:

Eureka : 就是服务注册中心(本身就是一个服务, 可以是一个集群), 对外暴露自己的地址

提供者:启动后向Eureka注册自己的信息(地址, 提供什么服务)

消费者: 向Eureka订阅服务, Eureka会将对应服务的所有提供者地址列表发给消费者,并且定期更新

心跳(续约): 提供者定期通过http方式向Eureka刷新自己的状态