分布式服务框架

最新推荐文章于 2024-01-21 03:37:15 发布

weixin_33946605

最新推荐文章于 2024-01-21 03:37:15 发布

阅读量115

点赞数

文章标签： java netty python

原文链接：https://my.oschina.net/weiweiblog/blog/643553

版权

2019独角兽企业重金招聘Python工程师标准>>>

转公司wiki博客.

分布式服务框架是面向服务架构的基石，是解耦子系统的利刃。核心实现是RPC（远程过程调用），但又不仅限于RPC，因为一个系统的高效、稳定、可靠的运行还需要依赖于服务管理发现、服务部署运行监控跟踪等辅助系统的支撑。在一个大型系统中，服务化之后服务的可维护、可管理、可监控以及高可用、负载均衡等因素同服务本身同样重要，这一点业内已经形成了共识。

目前公司内部主要使用的是Thriftpool以及Hedwig，除此之外，业内知名的几个服务框架还包括：

Finagle -- Twitter开发并开源，专为JVM设计的一个可扩展的RPC系统，其核心的组件包括Future、Service以及Filter；
Dubbo -- 阿里开发贡献的一个开源项目，是一个高性能分布式服务框架，它主要由三个核心部分组成：Remoting：提供远程调用的网络通信框架；集群：抽象出具有负载均衡、故障转移等集群能力；注册中心：一个服务注册框架，提供服务事件的发布订阅
Sofa-PBRPC -- 是一个轻量级的，基于Protobuf实现的一个RPC框架，由百度开发并开源，仅支持C++
Motan -- 新浪微博的RPC框架，序列化接口可扩展、具有集群方案，不开源
Poppy -- 腾讯基于Protocol Buffer的网络通信解决方案，除了RPC方式的编程接口之外，也具有集群方案，支持服务监控、调试、在线profiling等辅助功能，不开源

新浪的Motan和腾讯的Poppy均不开源，其功能特性只能从相关简介中略知一二，所以本文不打算进行深入分析。其他三个均为开源框架，下面就从RPC核心实现、服务管理、部署运行几个方面对比下这五个系统的实现。

服务调用RPC

通信（Transport）

Thriftpool通信层使用原始的Thrift Transport，就Java的实现来说就是使用NIO；
Hedwig、Finagle借助于Netty实现底层的通信，其中Finagle是Transport是可扩展的；
Dubbo定义了一个抽象的Transport接口，同时也提供了基于Mina、Netty等的实现；
Sofa-PBRPC使用的boost ASIO库实现的通信；

协议（Protocol）

Thriftpool：Thrift
Hedwig：Thrift、Protobuf...
Dubbo：Dubbo协议、Hessian等，可扩展
Finagle：Thrift等，很容易扩展实现
Sofa-PBRPC：Protobuf

服务（Service）

同步/异步：支持同步是每个框架的基本功能，这里主要是指异步的支持
- Thriftpool借助于Thrift的实现支持异步
- Hedwig：依赖于协议的实现，Thrif协议支持，Protobuf不支持
- Dubbo：
- Finagle天生异步（其最关键的一个组件就是Future）
- Sofa-PBRPC支持异步
跨语言支持
- Thriftpool：支持Thrift支持的语言，但只有Java有连接池容错支持
- Hedwig：
- Dubbo：仅支持Java
- Finagle：支持Scala、Java等JVM语言
- Sofa-PBRPC：C++

服务集群管理

Sofa-PBRPC仅仅是个RPC框架，基本上没有太多的服务管理功能，所以本节不对其进行比较。

注册与服务发现
- Thriftpool、Hedwig、Dubbo、Finagle都支持服务的注册及客户端的服务自动发现，基本上都是基于Zookeeper作为主要实现方式，有些还提供其他的服务发现方式比如Dubbo通过广播的方式等
故障转移、负载均衡
- Thriftpool、Hedwig、Dubbo、Finagle这些框架都具有服务集中注册的功能，所以也很自然地实现负载均衡与故障转移的功能，而且实现都是可以扩展的。
监控
- Finagle通过zipin
服务依赖关系管理
- 只有Dubbo的用户文档中特意强调了服务的依赖关系管理，其他的框架均未提到这一点，
服务配置部署与运行
- 支持Spring配置使用
- 资源隔离（Docker），弹性伸缩：均未有实现