常用微服务框架比较
从功能层面来说，对开发者有感知的功能有：服务实现，服务暴露（注解或配置），服务调用（注解或配置），服务治理等。从选型角度会关注以下几点：易用性（开发易用性和开箱即用）、性能、功能、扩展性等。
- 关键流程：服务暴露，服务注册，服务发现，服务调用，服务治理。
- 关键知识点：序列化，网络通信，服务路由，负载均衡，服务限流，熔断，降级等服务治理。
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
