halo-cloud私有云开源啦，构建小型的平民级的云计算平台

lz火气很大，语气很强硬。大家探讨一下而已，不用大动肝火。

首先，对于fanq之后如蜗牛般的网速，面对lz发的googlecode实在是无能为力。其实我问第一个问题的出发点只是想详细了解一下lz的项目。

其次，我想了解一下lz如何实现100台机器的分布式部署的，像前面网友提到的100台机器是独立的么，集群之间相互有通信么，如何合理分配与硬件资源。还有lz提到了解决了WS的数据传输上的性能问题，也简单谈一下你的系统架构被。

下了源码，研究一下看看再评论

何必这么复杂，搞个ESB和很多基础工具服务就OK了，在数据层面上，你又没做处理，项目没意义的，云的主要问题是数据层面，而不是应用层面。

建议楼主去研究下hadoop在去研究云吧，你的理解有些偏轨

KK实际上比较具体的对这个项目做了一个描述“很多小tools组成的suite”。我其实对云不云的没什么兴趣，不过是一个非技术人员容易理解，技术人员也知道怎么回事的名字而已。在这个世界上，99.99%的项目相信都是一堆小功能的组装，按照KK的描述推广下“很多小tools组成的项目”。

假设我们来了一个项目，要由20个小tools组成，其中包含8个其他项目开发过的tools，另外12个业务紧密相关的tools。halo-cloud就是想统一的提供那8个tools。在halo-cloud之前，你做这个项目需要开发20个tools，有了halo-cloud你只需要开发12个tools。具体那8个tools是不是分布式的，是不是云的，要看tools的特性来决定。这个tool可能就是一个类，返回一些东西，像我们拿姓名和身份证号去xx部验证真伪的tool；也可能是一个大的分布式tool，好比写入用户上传的视频文件到分布式存储中，自动压缩转码并分发到全球CDN网络（假设我们是每个节点都跑单独的分布式存储，不是全球连成1个大存储）。

halo-cloud做了什么哪？就是提供一个你着手开始建立自己公共tools的基础项目。我们做了一些tool，并将继续增加。当然在tools内部，如果需要分布式和机器同步，我们也会用zookeeper呀之类的，这个要看具体的tool的需要。现在，在内部，我们主要是用zk做各个机器间的版本控制和同步，当服务需要协同版本的时候。

对于解决WS性能问题，halo-cloud提供的接口是基于长连接的Socket的，并且允许自定义参数和返回结果解析。理论上，你在需要的时候，可以达到网络编程的极限速度，完全的自定义协议和长连接。我们曾经拿IP查询做过测试，只启动1个socket连接，同步调用，性能是phprpc（与hessian类似的rpc框架，官方提供的测试报告性能更高）的15-20倍。资源消耗方面，通过netstat命令，服务器端和客户端只有1个连接，而phprpc一下子能刷出一大堆的连接，甚至还遇到过文件数过多的问题。这应该是正常的，自定义协议并且稳定socket长连接的性能和资源消耗对比HTTP肯定是数量级的差别。

对于长连接，客户端是基于标准socket的连接池，服务器端基于Mina的NIO。

当然也提供有HTTP短连接的。常规RPC协议的调用，在guzz和spring中都有封装，这个项目就没有继续封装。

所以我说你的不是云啊，你的只是处理交互，那就用ESB好了，何必那么复杂，云的重要问题是数据的处理，所以才有了mapreduce .

恩，是ESB的模型。

没看出来了跟esb有什么关系

感觉是个grid不是cloud.


GRID即网格计算，即由多个节点机构成的一个虚拟CPU，分节点计算，结果汇总。

Cloud是更强大的概念，即包括虚拟硬件平台，虚拟OS平台，虚拟数据库平台，虚拟文件存储，而且这四个方面是一起存在的，不可分割的，是用来开发高层次应用的例如企业软件系统的架构。

（以上定义是我个人下的）

这个离云，差得十万八千里，顶多算是个水蒸气而已。


按这个定义来看，那些云杀毒，云输入法，统统是扯淡，就是多个在线存储和在线更新而已。

有时候比较迷惑，云计算到底是一种概念还是一种技术，如果是技术，那么技术的核心是什么，这种技术的理论基础又是什么？