RPC介绍与分析
随着微服务的普及，应用之间的通信有了足够多的成熟方案。Dubbo在2011年开源之后，被大量的中小型公司采用；在Spring Boot推出之后，Spring逐渐焕发出第二春，随即Spring Cloud面世，逐渐占领市场，在中国市场中，和Dubbo分庭抗争；gRpc是google推出的基于Http2的端到端的通信工具，逐渐地在k8s市场上占据统治地位，如etcd，istio等都采用gRpc作为通信工具；Service Mesh这几年逐渐成熟，Istio+Envoy(其他sidecar)逐渐开始走上舞台。
业务开发视角
功能层面：服务发现，服务暴露（通过注解或配置），服务调用（注解或配置），服务治理等。
选型角度：易用性（开发/开箱即用），性能，功能，扩展性等。
框架开发视角
关键流程：服务暴露，服务注册，服务发现，服务调用。
关键知识：序列化、网络通信、服务路由、负载均衡、服务限流、熔断、降级等服务治理
RPC主流技术实现
Dubbo架构
SpringCloud
Spring Cloud通过Rest形式进行网络调用。应用开发者可以自己编写暴露Rest服务，如springmvc。
Spring Cloud里的服务注册是应用维度(Eureka)，Client端和Server端通过约定的方式进行通信。
gRPC
gRPC 是一个 基于 HTTP/2 协议设计的 RPC 框架，它采用了 Protobuf 作为 IDL。gRPC作为端到端的通信方案。
gRPC本身不提供服务注册，服务治理的功能。
k8s
k8s体系里暂时没有公允的通信框架，一般推荐gRPC作为RPC框架。
k8s体系下，默认情况下，pod的ip是变化的，所以pod和pod之间需要通信的话，有几种方式:
Service+DNS：新建一个Service，可以通过标签选择到一组pod列表，这个service对应一个不变的集群ip；Client端通过DNS方式或者直接访问集群ip。这个集群ip，约等于实现了负载均衡 (iptable方式)。
headless service：headless service和上面的service的区别是，它不提供集群ip，通过主机名的形式获取一组ip列表，client端自己决定访问哪个pod。
网友评论