RPC服务RPC是一种远程过程调用（RemoteProcedureCall）。通过RPC，我们可以像调用本地方法一样调用其他机器上的方法。用户不会感觉到服务器与服务器之间的连接。沟通。RPC在微服务中起着相当大的作用。当然，RPC并不是微服务必须的方法。还有其他方法可以实现这种远程调用，比如RESTfulAPI。如果你用过SOAP，那么你在使用RPC时会有很相似的感觉，可以直接调用其他机器上的方法。随着业务的发展，我们的项目也逐渐从简单的单体结构演变为微服务结构。为什么要拆分成微服务？那我们就来说说微服务和单体架构的优缺点。我们来看一下单体架构图。单体架构单体架构的优点是部署方便，比如用php写的项目，只要复制一个文件夹到支持php的环境即可，而java只需要一个jar包即可。测试起来很容易，我们整个项目只需要改动一个地方，马上就可以了测试的结果可以通过负载均衡来解决。快速部署多个运行在不同机器上的相同项目来拆分单一架构的缺点的问题对于PHP来说是好的，但是对于Java项目来说，我们需要很长时间来重新打包整个项目和代码维护。由于所有的代码都写在一个项目中，如果要修改某个功能点，需要对项目的整体逻辑和设计有深刻的理解，否则严重的代码耦合导致维护困难。尤其是对于新员工来说，这会是最容易出问题的。开发效率低。随着项目需求的不断变化和新功能的加入，旧代码不敢随意删除，会导致整个项目变得繁琐，增加你阅读代码的时间扩展性。在高并发的情况下，我们往往在高流量、高请求的情况下，并没有把整个项目的每一个功能都具备。许多有时某个功能模块被大量的人使用。在单体结构下，我们没有办法实现单一功能的分布式扩展。我们必须一起部署整个项目。微服务架构是2014年提出来的，现在国内很多公司都在用。微服务是一种架构设计，而不是框架或替代品。微服务做的就是把服务按照项目的粒度进行拆分，把模块单独拿出来，做成一个个单独的小项目。微服务的主要特点是：每个功能模块都是一个小项目，独立运行在不同的进程或机器上，不同的功能可以由不同的人员独立开发，没有松耦合，独立部署可以启动单个项目，不依赖于整个项目的服务，分布式管理。每个服务只需要做好自己的事情即可。在设计微服务的时候，还需要考虑数据库的问题。是所有微服务都使用一个公共数据库，还是每个服务都有一个数据库？实现相互叠加的数据隔离技术栈。每个服务都可以由不同的团队或开发人员开发。外部调用者无需担心如何实现它。他们只需要按照服务提供者提供的参数调用自己的方法或接口即可。传递可以独立部署。每个服务都是独立部署的。部署服务不会影响整个项目。如果部署失败，最多就是少了这个服务的功能，不影响其他功能的使用。按需部署。可以针对不同的需求，为服务自由扩展服务器，根据服务的规模部署本地修改以满足实例的需求。当一个服务有新的需求或其他修改时，不需要修改整个项目，只要管理好自己的服务即可。由于业务拆分成小块，可能会部署在不同的机器上。所以对于运维人员的管理来说，这部分成本会增加接口调整，微服务之间通过接口进行通信。如果修改了一个微服务的API，所有使用该接口的微服务可能都需要调整；重复工作，许多服务可能使用相同的功能。但是这个功能还没有达到分解成微服务的程度。这时候每个服务都可能开发这个功能，造成代码重复。分布式，由于不同的服务会部署在不同的机器上，对这些服务调用、容错、网络延迟、分布式事务等都是一个很大的挑战。当然，并不是所有的微服务都部署在不同的机器上。服务器上的服务调用如上图所示。RPC用于调用者和服务之间的通信。RPC协议可以基于TCP、UDP或HTTP实现，但更推荐使用TCP。比如调用者需要调用商品的服务，可以通过RPC或者RESTfulAPI来调用，那么RPC调用和RESTfulAPI有什么区别呢？TCP的支持保持连接，调用服务时不需要每次都进行三次握手。RPC在性能和网络消耗方面有很大的优势。RESTfulAPI是基于HTTP的，也就是说，每次调用一个服务，都需要三次握手建立通信，才能实现调用。当我们的并发量很高的时候，这样会浪费很多带宽资源。如果服务是外部的，使用RESTfulAPI会比RPC更有优势，所以要看你团队的服务是内部的还是外部的。RPC的主要作用是调用进程。RPC用于服务调用。本文是RPC使用场景的开篇。它描述了单体架构和微服务。这是RPC的一个使用场景，也是最常用的使用场景。只有了解了RPC在什么情况下使用，在什么场景下才能更好的使用它。Swoft为我们提供了RPC的底层服务，我们不需要关心底层通信和调用过程的细节。Swoft定义接口，实现接口，启动RPCServer提供接口服务。我们只需要简单的写几个类就可以实现一个简单的RPC模块。关注微信公众号：IT不踢
