【Zookeeper】应用场景：为什么需要注册中心？

我们先来看看单体架构到微服务架构的变化：

电商场景下的单体架构：

电商场景下的微服务架构下会拆分出许多的服务，如订单服务，卡券服务，库存服务等

1.微服务通信手段

常见的服务间通信方式有以下两种：http协议和rpc协议。

手段一：Http（Hyper Text Transfer Protocol：超文本传输协议）

OSI七层模型中的应用层网路协议
Java中提供的http通信的组件：
- Apache 的 HTTP Client
- Square 的 OKHttp
- Netflix 的 Feign（Spring cloud常用，可读性强）
- Spring 的 RestTemplate（SpringBoot常用，易用，是对已有组件再封装）

简单来说，RestTemplate 是 Spring 提供的用来访问 REST 服务的客户端，以前我们使用 Apache HttpClient来进行远程调用时，需要写非常多的代码，还需要考虑各种资源回收的问题。而RestTemplate简化了Http服务的通信，我们只需要提供URL，RestTemplate会帮我们搞定一切。

RestTemplate 需要使用一个实现了 ClientHttpRequestFactory 接口的类为其提供 ClientHttpRequest 实现。而 ClientHttpRequest 则实现封装了组装、发送 HTTP 消息，以及解析响应的的底层细节。目前（5.1.8.RELEASE）的 RestTemplate 主要有四种 ClientHttpRequestFactory 的实现，它们分别是：
基于 JDK HttpURLConnection 的 SimpleClientHttpRequestFactory
基于 Apache HttpComponents Client 的 HttpComponentsClientHttpRequestFactory
基于 OkHttp 2（OkHttp 最新版本为 3，有较大改动，包名有变动，不和老版本兼容）的 OkHttpClientHttpRequestFactory
基于 Netty4 的 Netty4ClientHttpRequestFactory
所以，RestTemplate并没有重复造轮子，而是利用了现有的技术，如 JDK 或 Apache HttpClient 、OkHttp等来实现http远程调用。

下面我们就来看看RestTemplate的使用：

// 订单服务...
public class OrderController {
    @Autowried
    RestestTemplateBuilder restTemplateBulider;
    
    @PostMapping("/order")
    public String sayHello() {
        RestTemplate rt = restTemplateBuilder.build();
        // 发送put请求
        rt.put("http://localhost:8081/repo/{1}", null, 10001);
        return "Success";
    }
}

// 库存服务...
Public class RepoController {
    @PutMaping("/repo/{pid}")
    public vodi serverMsg(@PathVariable("pid") String pid) {
        System.out.Println("扣减库存，商品ID:" + pid);
    }
}

手段二：RPC（Remote Position Call：远程过程调用协议）

类似一种自定义API；可以通过Http协议实现，也可以直接通过tcp实现（常用，高效）
常见的Rpc框架有dubbo

虽然现在服务间的调用越来越多地使用了 RPC 和消息队列，但是 HTTP 依然有适合它的场景。
RPC 的优势在于高效的网络传输模型（常使用 NIO 来实现），以及针对服务调用场景专门设计协议和高效的序列化技术。
HTTP 的优势在于它的成熟稳定、使用实现简单、被广泛支持、兼容性良好、防火墙友好、消息的可读性高。所以http协议在开放 API、跨平台的服务间调用、对性能要求不苛刻的场景中有着广泛的使用。

将所有应用模块拆分成单独的服务在带来性能提升的同时，会带来什么问题呢？