1、JavaFx主类继承自“javafx.application.Application”
2、start方法是JavaFx应用程序的主入口。Application类是一个抽象类，运行一个JavaFx程序实例，其流程是：init（）---->start（）---->stop（），其中只有start（）方法是抽象的，因此要运行JavaFx程序必须实现start方法。
文件：url80.ctfile.com/f/25127180-739387590-d6ba17?p=551685 (访问密码: 551685)
3、JavaFx应用程序通过Stage类和Scene定义用户界面容器。其中Stage类是JavaFx中的***容器，Scene类是包含各种JavaFx组件（如按钮、标签、面板等）的容器。
如上图所示，类似于本地调用，A 服务响应调用 B 服务的 helloworld 方法需要怎么做？首先，A 服务的 Client Sub 收到函数调用后，会将调用方法以及参数序列化。Client Sub 通过 socket 将消息发送到服务端。服务端 B 接收到请求后，会按照协议将 request body 进行反序列化，获取将要调用的函数名以及参数。服务端调用该函数并获取到返回结果，Server Stub 将结果进行序列化后通过 socket 发送到 Client Sub，由 Client Sub 按照协议将消息反序列化，得到最终结果。
而实际上 RPC 框架会比以上流程更加复杂，还需考虑服务重试、熔断、 backup、request、路由负载均衡等。
如何利用 MQ 进行 RPC 通信？原理很简单，用 MQ 作为通信管道，模拟全双工通信。
如图所示，客户端 A 想要调用服务端 B 的 helloworld 方法需要怎么做？首先，客户端会将函数名字以及参数进行序列化，发送到 MQ Broker。MQ消费者消费到该消息后，会调用本地函数 helloworld，获取到结果后再将结果发送到 MQ Broker，MQ Broker 按照某种约定将响应结果发送到之前请求的 client 上。
以上流程完全为模拟 TCP 通信流程。RocketMQ 4.6.0分支也开始支持此特性——Request Reply。
上图为 Request Reply 实现原理。
Producer 创建 RequestFutureTable，producer 发起函数调用时，会将函数调用发送到 Broker 同时将该请求记录发送到 RequestFutureTable 中。Consumer 收到消息后，会调用本地函数将结果序列化返回给 Broker，同时返回给 Broker 特定的 request reply topic，附带返回的还有 producer。Broker获取到这些信息后，主动将消息发送到之前请求的 producer 上，producer 收到消息后会从RequestFutureTable中核对是否存在此请求，然后整完成整个 RPC 过程。
MQ虽然能用来模拟RPC的全双工通信，但需要付出一定代价：
使用MQ后，一次 TCP被拆解为四次，耗时增加，RPC 性能降低。
消息从 producer 发送到 Broker 再发送到 consumer，增加了消息传递的复杂性。
MQ 会将消息落盘，进一步降低 RPC 的吞吐能力。
RPC 通信严重依赖 MQ 的运维能力，MQ 容易成为性能瓶颈。
MQ 稳定性的维护成本远比 RPC 复杂。
综合考虑，使用 MQ 进行 RPC 通信不适合对接口耗时非常敏感的场景，但是任何技术都有其合适的应用场景，MQ 进行 RPC 通信也有其独特的妙用。
比如可以让 RPC 运行在类似于消息总线中，便于所有消息在统一入口进行消息的落盘审计。利用 MQ 的重试特性，能够保证所有请求都不会丢失。同时所有请求都运转在RocketMQ 中，消息请求的安全性得到进一步提高。
以上特性使得 MQ RPC 通讯特别适合消息安全性审查严格的场景，比如金融和银行场景，此类场景对接口时延要求不高，但对请求的安全性要求特别高。比如微众银行就利用 RocketMQ 的 request reply 特性构建了整个金融产品的 RPC 框架。
二、Dubbo-go介绍
Dubbo-go 是一款高性能的 go 语言微服务 RPC 框架，目标是打造新一代微服务基础设施，实现 Bridging The Gap Between X And Go，即使得 Dubbo-go 能与任何框架进行通信。
Dubbo-go 的框架的优势有以下几点优势：
开发者可以使用 Dubbo-go 框架轻松构建 RPC 服务
可以体验 Dubbo-go 强大的服务治理能力与运维能力。
Dubbo-go 的生态也在丰富中，比如 pixiu 网关已经可以在生产环境中使用。
Dubbo-go 的社区活跃度非常高，只要提交 issue，马上会有人进行跟进。
Dubbo-go 由四部分组成，分别是registry（注册中心）、consumer（客户端）、provider（服务端）、Monitor(Dubbo-go 的控制面)。客户端发起请求时，会首先从 register 获取客服务端的服务列表，然后通过对应的负载均衡获取到服务端，两者建立起 socket 进行通信。
Dubbo-go生态正在不断快速发展中。目前，Dubbo-go 能与gRPC、Spring Cloud、Dubbo、Java 进行通信，同时沉淀了 Dubbo-go 网关项目等，已经有公司在实际生产中使用。
RocketMQ 社区与Dubbo-go 社区联合推出了新功能，让 Dubbo-go 通过 RocketMQ 进行 RPC 通信来扩展 Dubbo-go 的通信方式。利用 Dubbo-go 丰富的服务治理能力和 RocketMQ 稳定的 RPC 通信能力，两者强强联合，打造 RPC 通信新范式。
Dubbo-go 通过 RocketMQ 进行通信的流程如下：Dubbo-go client 利用 request reply 特性将消息发送的 RocketMQ 的 Broker。Dubboserver 消费到 RocketMQ 的消息后，同样利用 RocketMQ 的 request reply 特性将消息返回到 Broker。Broker 将消息推送到发送消息的 Dubbo client 上。整个流程与 MQ 进行 RPC 通信的一致。
Dubbo-go 服务注册流程如下：首先 RocketMQ Broker 会向 nameserver 注册 Broker、topic、queue等信息。Dubbo-go client 会从 nameserver 中拉取路由信息，Dubbo-go server 订阅 topic 信息。
Dubbo-go 的通信协议目前能够支持 Dubbo、Triple 、gRPC、Rest。由于 Dubbo-go 要利用 RocketMQ 进行通信，我们需要构建新的通信协议，已经基本设计完毕，能够让 RocketMQ 与 Dubbo-go 完美融合。整个序列化协议。
本身 Dubbo-go 能够支持 Python2、JSON、Protobuf 和 MsgPack，Dubbo-go 利用 RocketMQ 进行通信同样能够支持以上四种序列化协议，但主要使用 Protobuf，另外的三种协议基本作为扩充来使用。
