RPC

  • 这是分布是系统领域很重要的一篇文章，主要论述在消息传递中"最多一次"、"最少一次"和"正好一次"三者中正好一次传递是不可能的，也就是通过网络两个服务器之间的调用恰好通过一次就完成正确通讯是不可能的。至少一次意思是一个消息至少传递一次以上，当然会造成消息内容重复冗余，但是可靠性提高了；而至多一次是服务
  • 本文主要谈论了微服务系统之间通讯RPC同步和异步队列的不同，RPC同步速度快但不可靠；异步队列速度慢一点但可靠。本文也解释了其背后原因，比如缺乏统一时钟，也就是著名的拜占庭将军问题，认识这点后，会更加意识到从单体巨石系统monolith迁移到微服务最困难的是缺乏事务机制。如果有一些与钱有关的系统比如
  • 建设一个高扩展性 松耦合系统是非常艰难的，随着移动和物联网设备增加扩展，不断增长的数据量和越来越高的客户期望，能够高效，可靠地在互联网规模的开发和运行系统变得非常关键。 在这样的互联网环境中，开发者总是会和不同语言 框架和技术打交道，各种微服务互动，这就使 icon
  • 与几十年前相比，网络相当可靠，随着我们继续构建更大，更全球分布的系统，我们使自己容易受到可能发生的所有不良事件的影响。为了解决这个问题，我们将不得不放弃同步请求/响应类型编程。调用方法（称为远程过程调用或RPC）的面向对象模型倾向于分解为网络不可靠时的条件，将我们的系统置于非确定性状 icon
  • 有时开发人员只关心速度。忽略消息传递的所有其他优势，他们会问我们以下问题：RPC 不是比消息传递更快吗？RPC可能会有其他不同的术语或技术，如 REST、微服务、gRPC、WCF、Java RMI 等。但是，无论使用哪个特定词，其含义都是相同的：通过 HTTP 进行远程方法调用。所以 icon
  • Loom的Fiber类似Scala和Kotlin的纤程，可以解决我们的并发问题，它与Java JDK的Futures 相比，解决了控制流丢失，上下文和virality丢失的问题。可悲的是，编写并发程序还不止这些！Fiber仍然是一个类似线程的构造，这意味着，如果我们要同时运行多个纤程 icon
  • API是现代应用的主要技术。API能够增强web客户端与移动客户端和后端的交互通讯，无需顾及他们的技术和平台的不同。当你构建基于web的api时，你通常选择rest风格的api。使用JSON作为应用程序之间交换数据的标准。 现在我们构建云时代的云原生应用时 icon
  • 结构化RPC比面向URL的REST API更容易设计和维护，因为他们让你专注于业务逻辑，而不是路由方案。更改API包括添加新字段或方法更容易，并且可以隐藏序列化的特性（例如，JSON缺少64位数字）。 gRPC实现了结构化RPC，但人们发现其复杂性 icon
  • 请问高手们 有在用rcp (eclipse rcp or netbeans platform) 开发系统的吗。 rcp应该如何与中间层通信。 HTTP？ WEBSERVICE？ icon
  • 这是为 gRPC 生态系统和现代 Java 构建的 Spring Boot 启动器。点击标题 项目背景：大约两年前，我的公司决定全面采用 gRPC 和现代 Java (17)。我们希望使用 Spring 和 gRPC 为我们的 Java 服务构建坚 icon
  • 我们已经拥有众多 API 架构风格，例如 REST、RPC和 SOAP 等，将 icon