高性能服务框架设计方案讨论

两种都是可以用，而且两个都挺流行的，当然ICE更加流行一些（因为会考虑跨语言需求），主要还是看开发效率和是否有跨语言调用的需求了

dubbo

    我对阿里巴巴的两个分布式服务框架（HSF和dubbo）都比较了解（源码详细分析过），我自己也做过类似的分布式服务框架，我觉得这要看你公司的业务规模，你们到底是要一个分布式服务框架，还是只是一个rpc的功能，这两个是有区别的。
    其实最开始阿里内部的服务调用是五花八门的，很多用hessian，有的直接自己搞的http url，调用方式，数据输出五花八门，那个时候，网站的系统结构是比较集中的，随着网站的规模变得越来越大，这种方式暴露了很多的弊端，因为大型网站最终的结构大概是三层：
1 分布式的业务层 （比如登陆服务器是一个集群，商品详情是一个集群，订单是一个集群）
2 分布式的服务层  （比如基础的商品，订单，物流，库存，会员，基于这些基础的服务，上面可以做很多的业务）
3 分布式数据层 （tddl，cobal+关系数据库，分布式kv，hbase等等）
    
    这个时候，仅仅只是rpc功能，已经无法满足分布式服务层的要求了，因为已经不仅仅是简单的远程调用了，分布式服务层承上启下，非常的核心，这不但要求它足够的健壮，还要有足够的“弹性”，比如我可以随时给某个服务加入几台机器，随时减少几台机器，外界却丝毫察觉不到；比如我可以随时给某个服务“降级”，限制某个消费端对某个服务端的调用次数或者并发数，保证核心业务的可用，还可以对某个服务进行限流；能监控某个服务集群的压力，方法的调用量，能监控某个服务被哪些机器调用，还可以随时将某些消费机器踢出；等等。。。。
rpc只是一个分布式服务框架的基础而已，分布式服务至少必须有以下特性：
1 高性能  
2 高可用 （集群）
3 服务治理 （监控，降级，流控，报警等等）
4 服务注册与发现 （一般用zookeeper做，直白点就是加减机器对外界是透明的，有良好的伸缩性）
5 故障转移 （当期服务器挂了或者网络不通，则自动调用集群中另外一台机器）
6 多版本 （一个服务，多个版本）
    
    其实自己做一个rpc没有想象的那么难，一个rpc框架最核心的是3点：
1 高性能的通信，这个不用自己写，mina，netty等都是现成的
2 透明的远程调用 一般都是用代理实现的
3 可扩展的序列化 比如java，hessian，json等等
但是做一个高性能分布式服务框架，则要考虑很多东西，你不能只简单考虑一个服务调用的功能，你眼里必须都是集群，容错，分布式等等。。。。

    所以，因地适宜，顺势而为，选择适合你的那把刀，不要用牛刀去杀鸡，当你系统的整体规模和架构没有达到需要那么多而且有规划的服务时，当你系统只是简单的几个接口调来调去且不需要考虑那么多时，hessian就了。

分步式框架，很流行呀，潜水学习中.......

分步式框架，很流行呀，潜水学习中....

非常感谢大家的回答，其实我已经自己在mina上面封装了同步调用，我也感觉基于TCP自己封装一个RPC其实不是很难，重点还是在于负载均衡，流量监控，服务动态注册于发现，服务降级等服务治理方面的工作。

但是我们老大的意思是一步步来，从简单开始，先基于一个现有的RPC框架，比如hessian或者ICE，在这上面来做服务治理，负载均衡等。

我感觉可能会需要花费比自己开发RPC框架那条路更多的精力。。。仅仅是直觉。

目前你们公司这一块的需求不明，公司规模也较小，我建议你们先考虑一些简单有效的方案，在项目应用的过程中逐渐迭代的完善这个框架，也许在这个迭代的过程中你们会发现业务需求中并不真正需要应用到什么高性能的服务框架，类似这种想法很多其实都是某位大领导头脑发热的结果，远程服务调用本身就是相对低效的，也会给软件架构设计上带来不可避免的复杂性，技术实现细节和测试等步骤均会受到较大的影响，能不用远程调用就坚决不用。所以我倾向于第1种方案，当然具体的选型还是再斟酌斟酌。

先给出应用场景，没有场景的高性能都是耍流氓

这兄弟说的靠谱

这位兄弟说的非常靠谱，服务治理和RPC一定要是松耦合的，RPC组件是应该要可替换的。
但是我有点担心，各种RPC框架的运行方式，或者说寄宿形式（有的是跑在web服务器，有的是windows服务，有的是linux上的精灵进程）差别很大，要做到RPC框架可替换估计有一定的难度。