分布式-微服务

服务发现

服务发现的意义是解耦程序对具体服务位置的依赖。对于分布式应用来说，服务发现是必须的。

组成

一个远程服务的精确坐标是由：全限定名、端口号、服务标识组成。其中“全限定名、端口号”的含义在各种远程服务中都一致，而“服务标识”则与具体的应用层协议相关，比如 HTTP 的远程服务，标识是 URL 地址；RMI 的远程服务，标识是 Stub 类中的方法；SOAP 的远程服务，标识是 WSDL 中的定义，等等。

部署

在分布式系统中，服务注册中心一般会以内部小集群的方式进行部署，提供三个或者五个节点（通常最多七个，一般也不会更多了，否则日志复制的开销太高）来保证高可用性。

服务发现框架

在分布式 K/V 存储框架上自己实现的服务发现

这类的代表是 ZooKeeper、Doozerd、Etcd。这些 K/V 框架提供了分布式环境下读写操作的共识保证，Etcd 采用的是 Raft 算法，ZooKeeper 采用的是 ZAB 算法（一种 Multi Paxos 的派生算法），所以这种方案都是 CP 的。

以基础设施（主要是指 DNS 服务器）来实现服务发现

这类的代表是 SkyDNS、CoreDNS。在 Kubernetes 1.3 之前的版本，是使用 SkyDNS 作为默认的 DNS 服务。在 Kubernetes 1.3 之后，SkyDNS 不再是默认的 DNS 服务器，也不再使用 Etcd 存储记录，而是只将 DNS 记录存储在内存中的 KubeDNS 代替；到了 1.11 版，就更推荐采用扩展性很强的 CoreDNS。

专门用于服务发现的框架和工具

这类的代表是 Eureka、Consul 和 Nacos。这一类框架中，自己决定是 CP 还是 AP 的问题，比如 CP 的 Consul、AP 的 Eureka，还有同时支持 CP 和 AP 的 Nacos。

网关

微服务网关的首要职责就是对外提供一个统一的地址，将外部访问这个地址的流量，根据适当的规则路由到内部正确的服务节点上。因此微服务中的网关，也称为“服务网关”或”API网关“。

还可以提供一些可选的功能：安全、认证、授权、限流、监控、缓存等。

区别

区别于老牌的Nginxt等路由器，Nginx是为了对流量平均的路由，而网关则是为了根据某种特征路由。

性能

网关的性能取决于它们如何代理网络请求的，即采用的哪种网络I/O模型。

网络I/O

网络I/O可以理解为对流的操作。每一次的网络请求，都会经历2个阶段：

1. 从远程主机获取到数据到系统内核缓冲区。

2. 数据从内核缓冲区复制到程序的地址空间。

针对完成这2个阶段的完成方法，可以分为2大类和5种模式。2大类是同步IO和异步IO，5种模式是在同步IO中又分出来：阻塞IO、非阻塞IO、多路复用IO和信号驱动IO。

• 异步IO

数据到达缓冲区后， 不需要调用进程主动复制数据，而是由操作系统复制完后，然后通知到线程。

• 阻塞IO

线程通过休眠来等待数据进入内核缓冲区。缺点是线程的休眠会带来引起用户态和内核态的转换。

• 非阻塞IO

线程每隔一段时间，来检查下数据有没有进入内核缓冲区。这种方式避免了线程的休眠，但是会浪费CPU资源。不常用。

• 多路复用IO

只休眠1个线程，让这个线程代理多个端口的监听。高并发网络主流方式。

• 信号驱动IO