使用.net构建轻量级分布式框架
TRANSCRIPT
分布式系统所面临的挑战�
• 可靠性�• 伸缩性�• 安全性�• 实时性�• 性能�• 更大的挑战——需要面临各种异构系统之间的相互集成�
现有的一些.Net下的分布式框架�• Remoting
– 基于.Net框架的内置实现，使用非常简单 – 仅限于.Net程序之间的交互，封闭的协议格式，无法跨平台 – 基于远程对象的架构，有时难以控制
• WCF – .Net下各种通讯技术的集大成者 – 基于冗长低效的SOAP协议
• 第三方产品�– ICE
• 开源，跨语言，跨平台 • CORBA的替代品，有很多局限性
用.Net打造自己的轻量级分布式框架�
• 基本的设计原则�– 按需设计——只为看得见的需求做设计�– 各模块之间充分的解耦，可组合可替换�– 跨平台，跨语言，不局限在.Net框架内�– 轻量且可扩展��
• 基于RPC的通讯方式�– 把通讯抽象为远程函数调用，提高了通讯的抽象级别�– 提供两种RPC模型�
• 请求/响应式�• 双向异步式�
– 局限：不适用于大数据量的流传输�
• 基于服务(service) 的分布式架构�– 摒弃分布式对象的概念，避免了远程对象的生存期管理�– 实现简单、效率高�– 一个服务提供一组协议�– 服务端上的客户状态及资源统一保存在每个客户的Session对象中进行管理�
– 可方便的实现断线重连�
协议的设计�• . Net的类型元信息是最佳的协议定义载体�
– .Net提供了非常丰富的类型表达能力�– 协议由一组interface来定义�– 用户可以传输自定义的struct及class类型�– 使用Proxy/Stub模式实现客户与服务之间的通讯��
• 协议的传输格式�– 多种格式的支持——可替换的序列化和反序列化模块�– 二进制格式�
• 自定义格式�• protobuf
– 文本格式�• XML格式，如SOAP • JSON格式�
– 利用.Net的AFribute可定制出任意复杂的序列化格式�
• 使用预处理程序自动生成代码�– 利用.Net的反射机制读取类型元信息�– 自动生成出序列化及Proxy/Stub代码�– 自动生成出其他语言及平台的相关代码�
RPC的设计�• RPC协议�
– RPC由interface来定义�– 一个连接只对应一个interface – 连接的发起方为客户端，接受方为服务端��
• 请求/响应式�– 请求是单向的，服务端不能向客户端发送请求�– 客户端发送一个请求就同步的收到一个应答�– 使用统一的服务异常(ServiceExcepGon)类型返回错误信息�
– 实现简单，有确定的时序，容易控制�
• 双向异步式�– 需要定义两个interface(service interface和callback interface)
– 客户端使用service interface向服务端发送请求�– 服务端使用callback interface向客户端发送消息�– 请求的发送无须等待直接返回�– 优点：低延迟，高吞吐量，适用于需要频繁向客户发送消息的场景�
– 缺点：上层的逻辑实现比较复杂，异步逻辑不易控制�
服务端的设计�• 网络IO处理模型的考量�
– 每连接一个线程�– Select多路IO处理�– 线程池+Select多路IO处理�– 异步IO处理��
• 服务逻辑的处理模型�– 单线程串行化处理�– 线程池并发处理�– 异步处理�
• Session的设计�– 为每个客户连接创建一个Session对象�– 在Session内保存客户状态及相关资源�– Session做为第一个参数传给服务端的请求处理函数�
一些高级特性�
• 通讯的自动化Log – 使用JSON格式Log请求和应答�– 在Stub类里自动化生成Log代码��
• 通讯的录像和回放�– 服务端将每个请求的流数据保存到文件中，下次运行时回放这些请求�
– 对重现错误很有帮助�– 也可用于自动化的回归测试�
• 服务部署和管理工具ServiceManager和ServiceNode – 用以取代系统的服务模块�– 每个物理服务器启动一个ServiceNode，并向一个全局的ServiceManager注册�
– 在ServiceManager上提供Service的启动/停止/监控/更新/Log等功能�
– ServiceManager提供名字服务(向客户端隐藏了ip/port等细节)
一个实例�
实现一个聊天服务器�
总结�
• .Net为构建分布式系统提供了良好的基础设施�• 用.Net快速的构建稳定、高效的分布式系统是完全可行的�
• 期待下一代.Net在异步编程上的新特性�
Q&A