计算机
eclipse软件
网络中数据都将会被转化为字节进行传送，在代码层面上，一个RPC框架需要实现特定格式的数据与字节数组之间的相互转化。如Java已经提供了默认的序列化方式，但是是在高并发的场景下，使用Java原生的序列化方式可能会遇到性能瓶颈。于是，出现了许多开源的、高效的序列化框架：如Kryo、fastjson和Protobuf等。buddha目前支持Kryo和fastjson两种序列化框架。
TCP关心的是字节流，它不知道上层的数据格式是什么。假如客户端应用层一次要发送的数据过大时，TCP会将该数据进行分解传送，因此在服务端需要进行粘包处理（由TCP来保证数据的有序性），但是如果客户端一次要发送的数据量很小时，TCP并不会马上把数据发送出去，而是将其存储在缓冲区，当达到某个阈值的时候再发送出去，这就需要在服务端进行拆包的工作。
解决这类问题在于向数据包添加边界信息，发送端给每个数据包添加包首部，首部中至少包含数据包的长度，这样在接收端接收到数据时，通过读取首部的长度信息得到该数据包有效数据的长度。发送端将每个数据包封装为固定长度（多余用0填充），这样接收端在接收到数据后根据约定好的固定长度读取每个数据包的数据。使用特殊符号将每个数据包区分开来，接收端也是通过该特殊符号的划分数据包的边界。如buddha采用添加包首部来解决TCP拆包、粘包的问题。
像accept()、read()和write()等函数都是同步阻塞的，这意味着当应用为单线程且进行IO操作时，如果线程阻塞那么该应用必然会进入挂死状态，但是实际上此时CPU是处于空闲状态的。开启多线程，就可以让CPU去为更多的线程服务，提高CPU的利用率。
线程切换带来的开销还是存在。所以在高并发的场景下，传统的BIO是无能为力的。而NIO的重要特点是：读、写、注册和接收函数，在等待就绪阶段都是非阻塞的，可以立即返回，这就允许我们不使用多线程充分利用CPU。如果一个连接不能读写，可以把这个事件记录下来，然后切换到别的就绪的连接进行数据读写。如在buddha中，Netty被用来编写结构更加清晰的NIO程序。
RPC服务的提供者往往需要使用集群来保证服务的稳定性与可靠性。因此需要实现一个服务注册中心，服务提供者将当前可用的服务地址信息注册至注册中心，而客户端在进行远程调用时，先通过服务注册中心获取当前可用的服务列表，然后获取具体的服务提供者的地址信息（该阶段可以进行负载均衡），根据地址信息向服务提供者发起调用。