m0_57408211的博客

主流的注册中心 etcd、zookeeper 等功能强大，与这类注册中心的对接代码量是比较大的，需要实现的接口也很多。另外，也要提供 Heartbeat 方法，便于服务启动时定时向注册中心发送心跳（也是通过HTTP），默认周期比注册中心设置的过期时间少 1 min。首先定义 GeeRegistry 结构体，默认超时时间设置为 5 min，也就是说，任何注册的服务超过 5 min，即视为不可用状态。而现在我们实现了注册中心，那这一节的服务发现就可以继承上一节的，并添加与注册中心相关的细节。

一般来说负载均衡器是独立的, 被放置在服务消费者和提供者之间. 代理通常需要保存请求响应副本, 因此有性能消耗也会造成额外延迟. 当请求量大时, lb (load balance)可能会变成瓶颈, 并且此时 lb 单点故障会影响整个服务。LB能力被分散到每一个服务消费者的进程内部，同时服务消费方和服务提供方之间是直接调用，没有额外开销，性能比较好。假设有多个服务实例，而每个实例都提供相同的功能，为了提高整个系统的吞吐量，每个实例部署在不同的机器上。需要负载均衡那就需要有多个提供相同功能的服务实例。

为了解决这个问题，浏览器通过 HTTP 明文形式向代理服务器发送一个 CONNECT 请求告诉代理服务器目标地址和端口，代理服务器接收到这个请求后，会在对应端口与目标站点建立一个 TCP 连接，连接建立成功后返回 HTTP 200 状态码告诉浏览器与该站点的加密通道已经完成。这里是接管 HTTP 连接，其指这里接管了 HTTP 的 TCP 连接，也就是说 Golang 的内置 HTTP 库和 HTTPServer 库将不会管理这个 TCP 连接的生命周期，这个生命周期已经划给 Hijacker 了。

超时处理是 RPC 框架一个比较基本的能力，如果缺少超时处理机制，无论是服务端还是客户端都容易因为网络或其他错误导致挂死，资源耗尽，这些问题的出现大大地降低了服务的可用性。等待服务端处理时，等待处理导致的超时（比如服务端已挂死，迟迟不响应）调用映射服务的方法时，处理报文导致的超时。读取客户端请求报文时，读报文导致的超时。从服务端接收响应时，读报文导致的超时。发送请求到服务端，写报文导致的超时。发送响应报文时，写报文导致的超时。与服务端建立连接，导致的超时。

这一节要熟悉Go中的反射reflet，不然可能比较难理解。在使用到反射的一些函数时候，我也会讲解关于反射的这个函数的用法。到这里，和官方的net/rpc库已经接近了，已实现rpc基础的重要部分。前面的代码例子，总结下主要2步：1.注册服务，并启动rpc服务，2.创建rpc客户端，客户端发起请求Call.注册服务通过newService方法新建服务，通过reflect获取服务的结构体名,类型等等，之后调用(service.) registerMethods方法来获取可以导出的方法，然后存储在服务端。

封装结构体 Call 来承载一次 RPC 调用所需要的信息。Seq uint64请求的服务以及方法名请求参数和请求的回复请求出错时返回的错误信息为了支持异步调用，Call 结构体中添加了一个字段 Done，Done 的类型是chan *Call，当调用结束时，会调用通知调用方。

一般来说，涉及协议协商的这部分信息，需要设计固定的字节来传输的。但是为了实现上简单点，GeeRPC 客户端固定采用 JSON 编码 Option，后续的 header 和 body 的编码方式由 Option 中的 CodeType 指定，服务端首先使用 JSON 解码 Option，然后通过 Option 的 CodeType 解码剩余的内容。但要注意的是：在一次连接中，Option 固定在报文的最开始，Header 和 Body 可以有多个，即报文可能是这样的。服务端中肯定会有进行监听的。

比如我们想统计一下下游每个接口调用的耗时、超时、异常情况，这个时候就使用rpc框架非常方便了，因为大多数的rpc框架都会提供一个事件或者钩子给我们，我们就能很方便的做这些事情。而现在大部分的系统都是给浏览器使用的，因此HTTP协议必不可少，一些小公司用HTTP也容易搭建自己的架构，成本也低，也好维护。一般而言，RPC 是微服务框架的一个子集，微服务框架可以自己实现 RPC 部分，当然，也可以选择不同的 RPC 框架作为通信基座。一般来说，RPC的性能比HTTP会更强，大多数RPC框架也提供了很多功能，