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

小弟刚开始接触高性能服务框架，老大让我调研一下，但是我最近遇到一个非常大的疑问，想请各位讨论一下，希望大家踊跃啊：
对于我们公司（非大型IT公司）来讲，想要实现一个高性能的服务框架。
我们目前其实没有太实际的需求，主要就是想在高性能服务框架方面有所成就，或者说有所进展，一步步慢慢发展嘛，未来可以结合分布式存储，推出属于自己的一套高性能服务调用以及存储的解决方案。

我的疑问主要是觉得下面两种方案都可以叫做HSF框架吧，那么对于我们来讲大家觉得应该采用哪种方案比较好呢？
1、Hessian等成熟的RPC框架 + Apache + Tomcat负载均衡
2、自己实现RPC框架：在Mina等TCP通信框架 + Hessian、ProtocolBuffer等序列化组件上面进行封装。服务动态注册，客户端随机选择来实现负载均衡

对于方案1来说，其实蛮简单的，估计一天不到就能搞定。但是我觉得肯定有很多不好的地方，不然早就流行，比如不能二次开发等。。。具体我也说不上来。
对于方案2来说就非常难了，类似阿里公司的Dubbo吧，我估计需要好几个人搞几个月。现在好像很多大的公司都有自己的分布式服务框架，优点就不得而知了。

希望大家能够结合自己的实际发表意见，谈谈对这两种方案的看法，谢谢了！

我主要是想知道方案1为什么不好（没有流行，甚至没人提及），方案2为什么好（很多公司自主开发）。谢谢各位

只想告诉你，磨刀不误砍柴工

期待高手回复，为什么大公司没有用现有框架去集成，而是更愿意去开发自己的分布式服务框架

就这样就沉了？

方案1和方案2最大的区别你不是都说了嘛，负载方式不一样，方案1的集中式负载意味着单点，但它的好处在于透明性，客户端不需要知道所有节点的位置。方案2的好处在于没有单点，伸缩性强大，这类方案最初提出来，主要就是为了性能。

至于时间上的考虑，我觉得直接用Dubbo没什么不好，没有必要自己重复去造。

方案1没有任何所谓的透明性的优势吧。
方案2完全可以封装成透明的，我觉得自己开发的分布式服务框架最大的优势除了二次开发之外，关键是可以增加服务治理相关的功能。

至于有没有必要再造。。。呵呵，每个公司有自己的情况，而且Dubbo服务治理不开源，谁知道以后会怎么样。

我说的没错吧？

就事论事，非常感谢你的回答

1、Hessian等成熟的RPC框架 + Apache + Tomcat负载均衡

我们现在就在使用这样的一个设计！
很多优点
但缺陷也很明显：（业务大的情况下）
1.0 服务的监控
2.0 服务的负载
这两点得自己去实现 而且还很繁琐！

求教，什么是：
==============
1.0 服务的监控
2.0 服务的负载
===============

额，是：
（1） 服务的监控
（2） 服务的负载

是么？。。。。