常用微服务框架比较

从功能层面来说，对开发者有感知的功能有：服务实现，服务暴露（注解或配置），服务调用（注解或配置），服务治理等。从选型角度会关注以下几点：易用性（开发易用性和开箱即用）、性能、功能、扩展性等。

• 关键流程：服务暴露，服务注册，服务发现，服务调用，服务治理。
• 关键知识点：序列化，网络通信，服务路由，负载均衡，服务限流，熔断，降级等服务治理。

Dubbo/HSF

Dubbo 提供了面向接口的远程方法调用。应用开发者定义接口，编写服务并暴露。Client 端通过接口进行调用。Dubbo 注册服务的维度是接口维度，每个接口会在注册中心写入一条数据。Dubbo 支持条件路由，脚本路由，Tag 路由等。这些路由规则都是强依赖于 IP 地址。

Spring Cloud

Spring Cloud 通过 Rest 形式进行网络调用。应用开发者可以自己编写暴露 Rest 服务，如 Spring MVC。Spring Cloud 里的服务注册是应用维度（Eureka），Client 端和 Server 端通过约定的方式进行通信。

Spring Cloud 提供了一套标准 API，而其中 Netflix 是其中的佼佼者，对这套 API 进行了实现，对大部分开发者来说，可以回直接依赖和使用 Netflix，所以可以说是 Netflix 提供成了 Spring Cloud 的核心。但是作为商业公司对开源投入往往会多变，如 Eureka 已经体制维护。

gRPC

gRPC 是一个基于 HTTP/2 协议设计的 RPC 框架，它采用了 Protobuf 作为 IDL。gRPC 作为端到端的通信方案，可以解决现在的多语言问题。gRPC 本身不提供服务注册，服务治理的功能。但现在可以看到 gRpc 有趋势往这方面扩展的野心。

Kubernetes

Kubernetes 体系里暂时没有公允的通信框架，一般推荐 gRPC 作为 RPC 框架。Kubernetes 体系下，默认情况下，Pod 的 IP 是变化的，所以 Pod 和 Pod 之间需要通信的话，有几种方式：

• Service + DNS：新建一个 Service，可以通过标签选择到一组 pod 列表，这个 service 对应一个不变的集群 IP；Client 端通过 DNS 方式或者直接访问集群 IP。这个集群 IP，约等于实现了负载均衡（iptable 方式）。

• Headless Service：Headless Service 和上面的 Service 的区别是，它不提供集群 IP，通过主机名的形式获取一组 IP 列表，Client 端自己决定访问哪个 Pod。

Istio + Envoy

Istio 的控制层会向 Kubernetes 的 Api Server 请求并监听 Pod 信息，Service 信息等信息。这样 Istio 中就有了完整的 Kubernetes 集群中的 Pod，Service 等的完整信息。如果 Kubernetes 集群中有信息变更，Istio 中也可以得到通知并更新对应的信息。

Envoy 作为 Proxy 一个最常见的实现，以 Envoy 作为例子简单介绍。Envoy 通过查询文件或管理服务器来动态发现资源。对应的发现服务及其相应的 Api 被称作 xDS。协议内容包括 LDS、RDS、CDS 等等。

Dubbo 与 Spring Cloud

• 服务发现统一：Dubbo 改造成应用维度的服务注册。

• 打通调用：Dubbo 实现中，支持将以 Rest 协议进行暴露，并且让 Spring Cloud 识别。