微服务网关与rpc（微服务网关如何调用服务）

本篇文章给大家谈谈微服务网关与rpc，以及微服务网关如何调用服务对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享微服务网关与rpc的知识，其中也会对微服务网关如何调用服务进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、RPC协议及实现方式(分布式微服务治理的核心)
• 2、微服务基础概念介绍
• 3、开源推荐-C++开发的微服务框架Tars
• 4、如何快速搭建一个微服务架构

RPC协议及实现方式(分布式微服务治理的核心)

分布式微服务治理的核心在于: 微服务和分布式

Remote Procedure Call，翻译过来应该是“远程程序调用”，目前业内通用的翻译是“远程过程调用”，但是“过程”这个词很容易造成误解，翻译成“程序”更好理解RPC的意义。

一般所谓的XX协议就是个文档，类似于我们的需求文档，只说了要做什么，但是具体怎么做是由各大开源大佬做的。 一般情况下都会实现核心功能，不同的开源在细节上实现都会不一样，这个需要注意！

RPC 这个概念术语在上世纪 80 年代由 Bruce Jay Nelson 提出的，在 Nelson 的论文 "Implementing Remote Procedure Calls" 中，他提到了几个 RPC的特点 ：

除此之外，这位大佬还给出了实现RPC框架的 详细架构图 ：

结合上图，Nelson 的论文中指出实现 RPC 的程序包括 5 个部分：

所以这架构图的意思是：当 user 想发起一个远程调用时，它实际是通过本地调用 User-stub。并通过本地的RPCRuntime传输 。远端 RPCRuntime 实例收到请求后交给 Server-stub 进行解码后发起本地端调用，调用结果再返回给 User 端。

看完协议内容，跟着就得实现这个协议啦，这时候你是不是发现了问题的严重性： 自！己！一！点！思！路！都！没！有！

所以我们需要再理解一下RPC协议，根据Nelson的论文知道我们要做的两件事：

上述两点其实是实现RPC协议的两大要素： 序列化协议和传输协议 。

因为RPC本质上是进程间通信，而“本地调用和远程调用的对比”实际上就是“进程内通信和进程间通信的对比”。通过两者的对比，我们才能理解到 序列化协议和传输协议 的作用，如下图：

最基本的RPC框架就是 单点式 的，因为A服务直接调用B服务，不经过第三方，这种是最简单的。但是必须是A和B同时部署一套，A1只能调用B1，A2只能调用B2。

所以需要一台A服务对多台B服务，利用第三方服务(注册中心)找到其他B服务，而不是写死B服务的地址。这种RPC才是 分布式 RPC，也是业内主流。

单点RPC框架只需要：

但是我们要做分布式的啊，所以需要：

实际上在生产环境中，我们需要实时监控服务的调用情况，所以需要一个微服务管理中心，甚至是一个自动化运维的管理中心，所以需要：

在文章的第二节我们看到大佬论文中对RPC的总结，其中一个很重要的一点：“通用”。

所以我们需要：

对的，能实现上述五点的，才是一个合格的RPC框架，但还不是优秀，因为我们还要考虑下性能。

先打个底，目前流行的RPC框架大多都是多管闲事，不单单只是RPC框架，你可以看看Dubbo和SpringCloud中除了RPC还有什么骚功能。

可以看看别人的各种RPC框架总结： http://www.cnblogs.com/moonandstar08/p/6291283.html
在网上找到了个图，但是没有提到SpringCloud，暂且看看先，因为有些不认为是对的：

我们可以看到各个RPC框架使用的序列化协议，注册中心，管理中心，是否跨语言，但是传输协议没有提到。

参考这篇博客： http://blog.csdn.net/jek123456/article/details/70208049
综合来说，在性能上rpcx是首选，但是考虑到框架的生态，其实还是推荐Dubbo或者SpringCloud的，因为除了性能，成本也是很重要的，无论是学习成本还是研发成本。

微服务基础概念介绍

微服务经历了单体应用-rpc-微服务等发展阶段微服务网关与rpc，每个阶段都解决了不同的问题微服务网关与rpc，简单描述如下：
● 单体应用-rpc
解决了单体应用复杂性的问题。每个服务可以独立扩展。
● rpc-微服务
强化了服务治理相关功能，如服务发现、服务监控、流量管理、负载均衡、重试熔断等。

springcloud归属于应用层面，以基于springboot的业务应用为基础，多出了服务治理相关内容，其部署运行需要底层的支撑，具体可以是物理机/虚拟机/容器等。下图为以推荐服务/AB测试服务为基础的微服务所涉及的应用节点和资源层依赖：

微服务网关与rpc我们部门承担了研发和运维的职责，在完成应用开发的同时需要兼顾运维功能，因此在进行设计的时候需要考虑功能、服务治理、底层资源的调度支撑等方面的内容。开发框架选择需求具体如下：

完成基于微服务的应用开发，并且兼顾部署运维相关功能，需要将springcloud与k8s融合使用。具体融合示意图如下：

在应用层与运行环境分割线上的组件为需要进行融合的组件。如springcloud官方提供了spring cloud kubernetes方案来实现该融合。腾讯提供了spring-cloud-tencent方案实现springcloud与腾讯k8s云服务的融合。
很多公有云厂商将运行环境与服务治理能力包装起来，提供一站式的微服务接入能力。

目前推荐服务与AB测试服务在k8s上部署结构如下图所展示：

引入springcloud后，推荐服务与AB测试两个节点作为核心业务节点，部署方式不发生变化。新引入的服务发现、监控、限流、路由等非功能节点，这些节点作为k8s中服务节点进行部署，为核心业务节点提供服务治理功能，具体如下：

开源推荐-C++开发的微服务框架Tars

Tars致力于建设微服务技术生态，在底层基础设施、服务框架、上层应用以及DevOps等方面，都做了较为深入的研发。

2020年3月10日，Linux基金会正式宣布旗下的TARS开源项目成立TARS子基金会。这是一个 专注于微服务领域 的开源基金会，致力于帮助企业拥抱微服务体系架构，解决在使用微服务方面可能出现的问题。这是首个 起源于中国开源项目 的国际开源基金会，也是Linux基金会下 唯一聚焦微服务技术生态 的子基金会。

Tars基金会里目前收录了9个项目，分为5部分：工具集（Tars Lab）、服务治理（Service Governance）、微服务开发框架（Development Framwork）、存储（DCache）和基础设施（Infrustructure）。

1、Tars Lab

Tars Lab项目提供了压力测试TarsJMeter，基准测试集TarsBenchmark和一些开发工具包。TarsJavaStart，可以生成服务端和客户端的TarsJava脚手架，快速开始Tars服务的开发。TarsTools，是一款支持多种IDE的JetBrains插件，为实现编辑Jce/Tars文件使用的（支持Intellij IDEA、Android Studio、PhpStorm、WebStorm、GoLand、CLion等）。

2、服务治理

服务治理包含了2个项目：TSeer专注于处理服务注册与发现；TarsGateway是基于Tars框架开发的微服务网关，除具备网关的基础功能外，还可以自动将HTTP转换成Tars-RPC协议。

3、微服务开发框架

这部分只包含Tars一个项目，核心模块由C++开发，提供了多语言开发框架，默认rpc调用，是Tars基金会的核心项目。其他项目都是围绕这个项目研发的。

4、微服务存储

这部分只包含DCache一个项目，它是基于Tars框架开发的 分布式共享内存存储系统 ，支持常用的kv数据结构、支持二级索引、支持在线扩缩容、支持自动持久化到后端db等特性。DCache依赖Tars框架的运行，但也得益于Tars，使得存储服务的运维成本几乎为0。

5、微服务基础设施

这是一个将Tars与K8S融合使用的项目，致力于将Tars融入到K8S生态中。

在这方面还有一个更优秀的项目K8SFramework，致力于将Tars与K8S深度融合，相信未来会纳入到基金会中。

| Tars的前世今生

Tars的前身是腾讯内部的TAF框架，已经经过了10年的验证，稳定运行与1.6w+服务器，100多个业务线中。

据统计， Tars已在超过 120 家公司、 261200 台服务器上稳定运行。

在分布式环境下，所有的微服务（包括DCache的服务）都可以通过框架自带的控制台-TarsWeb进行管理， 可以做到所有服务状态可监控，可以在控制台上进行启停、修改配置、执行运维指令等操作。

在分布式部署的情况下，可以通过Web控制台实现一键升级、回退。

Tars自带配置中心，分级配置，可以统一修改配置，做到“一点修改，全局生效”。

在服务部署时，可以在界面上填写要发布的节点，一键部署、扩容。

框架提供了状态监控的能力，可以监控服务的调用质量，如流量情况，平均耗时、超时率和异常率。

框架状态可以在控制台上一键核查。

Tars提供配套的性能测试工具，这也是Tars基金会的子项目。性能测试工作不再依赖专业的测试人员。

| Tars优势

1、原生RPC调用

Tars使用自研的RPC协议通信，服务之间建立长连接，在通信频繁的场景下具备显著的性能优势。

2、多语言支持

除C++和Java外，Tars还支持NodeJs，PHP，Go等语言，提供了相应的SDK。当团队技术栈多样化时，可以多语言协同开发，无缝对接，开发者可以选择自己熟悉的语言进行开发，提升团队整体效率。

在这方面，Spring Cloud想要支持异构语言，需要借助SideCar构建Service Mesh。 业界现在有一些比较流行的服务网格解决方案，但是 并没有形成统一的标准 ， 可移植性不高 。比较常见的像Istio，由于是代理模式，而且非长连接，会存在 更大的延迟 。另一方面，Istio的部署和运维都非常 复杂 ，需要更多的学习成本和运维成本。

3、内置服务治理功能

Tars框架内嵌了丰富的服务治理功能，包括熔断、限流、负载均衡、认证、加密等。同时，在服务监控、数据采集，以及灰度部署、跨机房部署等方面，都原生支持，集成度高。

Spring Cloud要支持这些功能，要么需要集成其他组件，要么需要设计开发来实现。都需要付出额外的学习成本和研发成本。

4、运维监控

Tars为使用者提供了一体化的运维管理控制台，我们可以在Web上进行一键部署、扩容、升级、回退等运维操作。

Spring Cloud并没有配套的工具。要实现Web管控， 需要借助K8S和容器，同样需要付出额外的成本。

5、国产化

Tars是国内公司主导的开源项目，这一点就不多说什么了。

6、“套装”优势

Tars框架提供了微服务相关的一体化解决方案，常规情况下不需要再去集成其他组件，不存在兼容性问题。这就好比MacBook和兼容机的区别，兼容机你可能需要付出更多的试错成本才能达到想要的效果。

| 劣势

1、项目热度

Tars开源较晚，到目前只有5年多时间，项目热度不如Spring Cloud，应用也没Spring Cloud广泛。

2、Tars的云原生之路

Tars和K8s的深度融合也开源不久（2020年7月，K8SFramework），还有待落地验证。这个项目现在的更新频率较高，不建议在生产中使用。但是从这一点也可以看到社区工作者对Tars与K8S融合的高涨热情，相信未来这个项目一定会大放异彩！

Tars在微服务开发、运维、监控等方面提供了一体化的解决方案，可以帮助我们低成本构建企业级微服务。适用于各种规模的团队，各种规模的系统。

在做技术选型时，如果团队中有C++开发人员，或者有多语言开发的情况，而且团队规模、资源有限的情况下，建议选择Tars。它在运维、监控、测试等方面会为我们节约大量成本。

未来，随着 K8SFramework 项目的日渐成熟，相信Tars生态会被更多的团队熟知和使用。

如何快速搭建一个微服务架构

什么是微服务？

微服务(Microservices Architecture)是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。

微服务的概念源于2014年3月Martin Fowler所写的文章“Microservices” martinfowler.com/articles/mi…

单体架构(Monolithic Architecture )

企业级的应用一般都会面临各种各样的业务需求，而常见的方式是把大量功能堆积到同一个单体架构中去。比如：常见的ERP、CRM等系统都以单体架构的方式运行，同时由于提供了大量的业务功能，随着功能的升级，整个研发、发布、定位问题，扩展，升级这样一个“怪物”系统会变得越来越困难。

这种架构模式就是把应用整体打包部署，具体的样式依赖本身应用采用的语言，如果采用java语言，自然你会打包成war包，部署在Tomcat或者Jetty这样的应用服务器上，如果你使用spring boot还可以打包成jar包部署。其他还有Rails和Node.js应用以目录层次的形式打包

上图：单体架构

大部分企业通过SOA来解决上述问题，SOA的思路是把应用中相近的功能聚合到一起，以服务的形式提供出去。因此基于SOA架构的应用可以理解为一批服务的组合。SOA带来的问题是，引入了大量的服务、消息格式定义和规范。

多数情况下，SOA的服务直接相互独立，但是部署在同一个运行环境中（类似于一个Tomcat实例下，运行了很多web应用）。和单体架构类似，随着业务功能的增多SOA的服务会变得越来越复杂，本质上看没有因为使用SOA而变的更好。图1，是一个包含多种服务的在线零售网站，所有的服务部署在一个运行环境中，是一个典型的单体架构。

单体架构的应用一般有以下特点：

微服务架构（Microservices Architecture）

微服务架构的核心思想是，一个应用是由多个小的、相互独立的、微服务组成，这些服务运行在自己的进程中，开发和发布都没有依赖。不同服务通过一些轻量级交互机制来通信，例如 RPC、HTTP 等，服务可独立扩展伸缩，每个服务定义了明确的边界，不同的服务甚至可以采用不同的编程语言来实现，由独立的团队来维护。简单的来说，一个系统的不同模块转变成不同的服务！而且服务可以使用不同的技术加以实现！

上图：微服务架构

微服务设计

那我们在微服务中应该怎样设计呢。以下是微服务的设计指南：

微服务消息

在单体架构中，不同功能之间通信通过方法调用，或者跨语言通信。SOA降低了这种语言直接的耦合度，采用基于SOAP协议的web服务。这种web服务的功能和消息体定义都十分复杂，微服务需要更轻量的机制。

同步消息 REST

同步消息就是客户端需要保持等待，直到服务器返回应答。REST是微服务中默认的同步消息方式，它提供了基于HTTP协议和资源API风格的简单消息格式，多数微服务都采用这种方式（每个功能代表了一个资源和对应的操作）

异步消息 – AMQP, STOMP, MQTT

异步消息就是客户端不需要一直等待服务应答，有应到后会得到通知。某些微服务需要用到异步消息，一般采用AMQP, STOMP, MQTT 这三种通讯协议

消息格式 – JSON, XML, Thrift, ProtoBuf, Avro

消息格式是微服务中另外一个很重要的因素。SOA的web服务一般采用文本消息，基于复杂的消息格式（SOAP）和消息定义（xsd）。微服务采用简单的文本协议JSON和XML，基于HTTP的资源API风格。如果需要二进制，通过用到Thrift, ProtoBuf, Avro。

服务约定 – 定义接口 – Swagger, RAML, Thrift IDL

如果把功能实现为服务，并发布，需要定义一套约定。单体架构中，SOA采用WSDL，WSDL过于复杂并且和SOAP紧耦合，不适合微服务。

REST设计的微服务，通常采用Swagger和RAML定义约定。

对于不是基于REST设计的微服务，比如Thrift，通常采用IDL（Interface Definition Languages），比如Thrift IDL。

微服务集成 (服务间通信)

大部分微服务基于RPC、HTTP、JSON这样的标准协议，集成不同标准和格式变的不再重要。另外一个选择是采用轻量级的消息总线或者网关，有路由功能，没有复杂的业务逻辑。下面就介绍几种常见的架构方式。

点对点方式

点对点方式中，服务之间直接用。每个微服务都开放REST API，并且调用其它微服务的接口。

上图：通过点对点方式通信

很明显，在比较简单的微服务应用场景下，这种方式还可行，随着应用复杂度的提升，会变得越来越不可维护。这点有些类似SOA的ESB，尽量不采用点对点的集成方式。

API-网关方式

API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能个。通常，网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。

上图：通过API-网关暴露微服务

所有的业务接口通过API网关暴露，是所有客户端接口的唯一入口。微服务之间的通信也通过API网关。\

采用网关方式有如下优势：

目前，API网关方式应该是微服务架构中应用最广泛的设计模式。

消息代理方式

微服务也可以集成在异步的场景下，通过队列和订阅主题，实现消息的发布和订阅。一个微服务可以是消息的发布者，把消息通过异步的方式发送到队列或者订阅主题下。作为消费者的微服务可以从队列或者主题共获取消息。通过消息中间件把服务之间的直接调用解耦。

上图：异步通信方式

通常异步的生产者/消费者模式，通过AMQP, STOMP, MQTT 等异步消息通讯协议规范。

数据的去中心化

单体架构中，不同功能的服务模块都把数据存储在某个中心数据库中。

每个微服务有自己私有的数据库，其它微服务不能直接访问。单体架构，用一个数据库存储所有数据

微服务方式，多个服务之间的设计相互独立，数据也应该相互独立（比如，某个微服务的数据库结构定义方式改变，可能会中断其它服务）。因此，每个微服务都应该有自己的数据库。

每个微服务有自己私有的数据库，其它微服务不能直接访问。每个微服务有自己私有的数据库，其它微服务不能直接访问。

数据去中心话的核心要点：

数据的去中心化，进一步降低了微服务之间的耦合度，不同服务可以采用不同的数据库技术（SQL、NoSQL等）。在复杂的业务场景下，如果包含多个微服务，通常在客户端或者中间层（网关）处理。

微服务架构的优点：

微服务架构的缺点：

微服务的一些想法在实践上是好的，但当整体实现时也会呈现出其复杂性。

关于微服务架构的取舍

关于微服务网关与rpc和微服务网关如何调用服务的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 微服务网关与rpc的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于微服务网关如何调用服务、微服务网关与rpc的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。