两个service调用事务 微服务调用为啥用RPC框架，http不更简单吗？
微服务调用为啥用RPC框架，http不更简单吗？
简单一点，HTTP是协议，RPC是概念！RPC可以基于HTTP协议（feign）、TCP协议（netty）、RMI协议（soap）和web服务（XML-RPC）框架实现。在传输过程中，由于序列化方法的不同，也出现了一些框架和协议，如Dubbo中的Dubbo协议、grpc protobuf序列化协议等。实际上，它们都是基于远程调用的概念。什么是远程呼叫？
关键是RPC是远程调用。远程调用是客户端通过上述协议向服务器发送接口、参数、参数类型、方法、返回值、返回值类型等（称为方法签名），通知服务器要调用的接口方法。这个过程就是RPC的实现过程！HTTP和RPC是两码事
！在性能方面，HTTP本身是基于TCP协议的，属于应用层协议，所以HTTP协议本身在实现过程中会占用大量的资源（内存、带宽等）。在性能方面，它肯定不如直接通过TCP实现的RPC协议快。不管HTTP有多优化，它绝对没有TCP那么快！另一方面，TCP依赖于字节码。目前常用的是将客户端调用的接口信息以序列化的方式发送到服务器端。序列化框架包括许多内容（Hession、protobuf、kryo等）。Kryo具有最高的序列化性能，protobuf具有序列化后最小的字节码）。序列化后的字节码越小，占用的带宽越小，序列化时间越长，线程IO延迟越短，线程IO延迟越小。因此，在具体的应用层，有很多技术可以讨论。您可以根据自己的硬件能力选择相应的技术
！欢迎热爱科技的人们来探索
Service层和Dao层真的有必要每个类都加上接口吗？
这主要取决于您的项目：
例如，如果项目中使用hibernate，以后可能会切换到mybatis，那么Dao需要使用该接口。这不会影响上层代码的更改。
另一个例子是，项目是一个单一的应用程序。任何代码修改都需要重新编译整个项目，因此不需要接口。如果项目是由模块编译和部署的，那么可以使用接口解耦。假设修改了Dao，只需要重新编译和部署Dao模块，而不影响上层模块。
此外，如果项目团队中有许多新手，简单的代码结构可能更合适。复杂项目结构的学习成本较高。
如果工程进度非常紧迫，我们可以用简单粗暴的方式用经济成本来说明原因。
使用接口的成本是不使用接口的成本（包括后续维护成本）。
如果项目变化很大，部署了模块，项目不急，使用接口的成本比不使用接口的成本低，虽然早期不使用接口似乎更简单；相反，不使用接口的成本低，而且连框架都不能用～
毕竟工具是提高效率的，那你为什么不能和自己相处呢
J2EE中service层的作用，还有action为什么是调用IService，而不直接调用service层的方法，这不多此一举吗？
1. 服务层的功能：一般来说，在MVC中，服务是业务逻辑层，用于处理更详细的业务相关流程（即业务流程、非控制流程）等操作；动作是控制层，用于控制业务处理的方向，并与处理系统的前后连接；Dao是数据连接和数据库处理，可以看作是数据处理和数据库操作的框架中间件。
2. Iservice和服务（DAO）一样：就是因为服务层需要关注业务逻辑，业务逻辑有时复杂有时简单，有时一组逻辑只需要满足一组业务，有时一组逻辑需要同时满足多组业务（meet==conform），因此服务层需要保持可伸缩性和可伸缩性，这就需要松耦合。服务根据当前功能或业务需求定义接口，iservice负责具体实现。它可以是多态的、重载的、扩展的等等。
两个service调用事务 service之间互相调用 service层怎么调用dao层
版权声明：本文内容由互联网用户自发贡献，本站不承担相关法律责任.如有侵权/违法内容,本站将立刻删除。
