微服务入门-1、RPC、APIgateway

最新推荐文章于 2024-02-13 21:17:04 发布

qililong88

最新推荐文章于 2024-02-13 21:17:04 发布

阅读量1.1k

点赞数 1

分类专栏：网络编程文章标签： java 分布式

原文链接：https://www.jianshu.com/p/ec72df73568c

版权

网络编程专栏收录该内容

16 篇文章 0 订阅

订阅专栏

微服务 (Microservices) 是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模组化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通讯。

微服务的优势：

独立性
每个微服务的构建、部署、扩容、缩容、数据库都是独立的。数据库表修改时，互补影响。
敏捷性
功能单一、可快速添加新需求
技术栈灵活
可以发挥不同语言的优势，例如：用 python 来爬数据，nodejs 来处理 io 流
高效团队
可以分发给不同的团队进行开发

微服务的不足

额外的工作；
数据一致性；
沟通成本；
需要额外工作，例如：服务的拆分（即如何拆分微服务，哪些服务应该拆到一起）、服务注册、服务发现、微服务间的通信。每个微服务都持有独立的数据库，无法做到数据强一致性，只能做到最终结果一致性。做微服务也会增加团队的沟通成本。

微服务通信方式

微服务可以使用两种基本消息传递模式 -- 同步与异步消息传递，来与其他微服务通信。

同步通信。在此模式下，一个服务使用 HTTP 或 RPC（Remote Procedure Call，翻译过来为“远程过程调用”）框架等协议调用另一个服务公开的 API。此选项之所以称作同步消息传递模式，是因为调用方需要等待接收方返回的响应。比较通用的 RPC 框架有：gRPC（Google）、Thrift（Apache）
异步消息传递。在此模式下，服务可以在不等待回应的情况下发送消息，然后一个或多个服务以异步方式处理该消息。比较流行的消息队列有：RabbitMQ、ZeroMQ、Kafka、ActiveMQ

我们是否需要用微服务？
以我们公司为例，部门内部多个项目之间没有微服务的必要了，因为几个项目之间关联度不大，没有相互的调用，落地页生成的URL是通过用户手动整理进行投放的，所以没有必要，但是部门之间的通信是多种多样的，比如对数据中心的请求，对天网部门的请求都有不同的格式，这就可以发挥微服务的优势了，所以公司层面做了微服务的架构，包括服务注册，服务发现，服务通信都有相应的系统进行配置，各个部门之间使用API gateway方式进行通信，简洁方便。

微服务中是怎么通信的：

什么是 RPC

Remote Procedure Call，即为 -- 远程过程调用。通俗地解释一下：你有 A、B 两台电脑，A 电脑用 python 实现了一个加法运算，此时此刻 B 电脑有一个用 Java 实现的程序，想调用 A 电脑的加法运算程序。然而，内存空间不在同一台电脑，且编程语言也不相同，如何调用呢？此时此刻就用网络来表达调用的语义与调用参数。当然，现在我们不用自己去实现这些东西，当下有很多成熟的 RPC 框架供我们选择。

RPC 原理

什么都别说，先上图。

RPC原理

在往下看之前，我们先来了解一下：stub
stub 规定了 server 能够提供什么服务，这在 server 和 client 上是一致的。
RPC 调用链文字描述：
(1）client 以本地调用方式调用服务；
(2）client stub 接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体；
(3）client stub 找到服务地址，并将消息发送到服务端；
(4）server stub 收到消息后进行解码；
(5）server stub 根据解码结果调用本地的服务；
(6）server 执行方法并将结果返回给 server stub；
(7）server stub 将返回结果打包成消息并发送至 client；
(8）client stub 接收到消息，并进行解码；
(9）client 得到最终结果。

RPC 调用链：
(1)client 发起请求：rpc call --> send --> network
(2)server 接受请求：network --> receive --> local call
(3)server 返回结果：local return --> send --> network
(4)client 接收结果：network --> receive --> rpc return

以上就是 RPC 的原理，需要说明的是，它是同步调用的。

常用 RPC 框架对比

RPC 种类	dubbon	rpcx	grpc	thrift
开发语言	Java	go	跨语言	跨语言
服务治理	√	√	×	×
多序列化框架支持	√	√	×	×
多种注册中心	√	√	×	×
管理中心	√	√	×	×
跨语言	×	×	√	√

一下文字为引用（https://colobu.com/2016/09/05/benchmarks-of-popular-rpc-frameworks/）文章的描述：

Dubbo 是阿里巴巴公司开源的一个 Java 高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和 Spring框架无缝集成。不过，略有遗憾的是，据说在淘宝内部，dubbo 由于跟淘宝另一个类似的框架 HSF（非开源）有竞争关系，导致 dubbo 团队已经解散（参见http://www.oschina.net/news/55059/druid-1-0-9 中的评论），反到是当当网的扩展版本仍在持续发展，墙内开花墙外香。其它的一些知名电商如当当、京东、国美维护了自己的分支或者在 dubbo 的基础开发，但是官方的库缺乏维护，相关的依赖类比如 Spring，Netty 还是很老的版本(Spring 3.2.16.RELEASE, netty 3.2.5.Final),倒是有些网友写了升级 Spring 和 Netty 的插件。

rpcx 是Go语言生态圈的 Dubbo，比 Dubbo 更轻量，实现了 Dubbo 的许多特性，借助于Go语言优秀的并发特性和简洁语法，可以使用较少的代码实现分布式的 RPC 服务。

gRPC 是 Google 开发的高性能、通用的开源 RPC 框架，其由 Google 主要面向移动应用开发并基于 HTTP/2 协议标准而设计，基于 ProtoBuf(Protocol Buffers) 序列化协议开发，且支持众多开发语言。本身它不是分布式的，所以要实现上面的框架的功能需要进一步的开发。

thrift 是 Apache 的一个跨语言的高性能的服务框架，基于 thrift 进行序列化。也得到了广泛的应用。

其中比较受关注的是：grpc 与 thrift 。
grpc 支持的语言：C++,C#,Dart,Go,Java,Node.js,Objective-C,PHP,Python,Ruby,
thrift 支持的语言：C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, OCaml and Delphi 等

作者：zone7_
链接：https://www.jianshu.com/p/6e5f6f1280b9
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。