主题：【原创】云里雾里的云计算 [1] -- 邓侃
家园 云计算就是中间用互联网连接的主机、终端。 家园 P2P VS 云计算 这个主意很不错，有点持久战对闪电战的味道。如果是P2P,OS（Windows）还可以唱个主角，否则今夕是何夕？！
俺倒是有个主意。全世界的无线路由器(就家里用的那种)也用P2P的方式连为一体，不走有线路径。是不是也可以组个2.99G（3G - 0.01）的网络？想法提出来了，希望做出来后信息部，国安部还有中宣部不要找俺的麻烦。专利费俺就不收了.
家园 你的想法现在正在变成事实，就是Ad-Hoc-MANET 如果大家注意vista下的无线网卡配置，里面就有Ad-Hoc-MANET的选项。
大体上说，就是利用每个移动节点的无线路由，在link-layer利用泛洪动态组网。
但是现在只是大体上能够实现低、中速移动节点的动态组网。高速移动设备的动态组网由于网络拓扑结构的高度不确定性及不稳定性，现在好像还没有很好的办法。
家园 FON 公司介绍：FON是一家西班牙公司，一直致力于推动社区居民通过共享Wi-Fi无线网络接入互联网。用户只要同意共享一小部分家庭宽带连接，就可以加入一个庞大的全球Wi-Fi社区，免费接入到其他用户提供的FON无线热点。到目前为止，FON已经同时代华纳有线、英国电信、以及Neuf等多家重量级公司建立了合作关系。创始人：马丁·瓦萨维斯基(Martin Varsavsky)
融资情况：3500万美元，来自于Skype、谷歌、Index Ventures、红杉资本、Excite、Digital Garage、以及英国电信
员工人数：约90人
家园 我去年初的时候就有个P2P的RFID设备网络的想法 让每个手机用户都有一块rfid芯片，每个手机都可以relay其他手机的信号。当用户多起来，就组建成一个巨大无比的网络。
扩展开来，每件衣服都内置一块可以relay信号的芯片，世界就被连接起来了。
家园 这个东西中移动已经领衔主研了 已经在 ITU 立项
http://www.itu.int/net/ITU-T/lists/questions.aspx?Group=13&Period=14
Q 19/13 Distributed services networking (DSN)DSN主要用于应对目前电信网和Internet在业务和运营上所面临的一些挑战，吸取电信网可运营、可管理的特性和Internet在业务提供上的快速、灵活、低成本、可扩展的特性。它通过采用新的技术，如P2P等分布式技术来驱动对网络架构的发展的研究。http://labs.chinamobile.com/focus/20081129/
家园 P2P无线网？这个有创意，赞一个 不过兄弟保重，想砍你的恐怕不只是信息部，国安部还有中宣部，头一个大概就是中国电信。
家园 用云计算平台支撑网游 用云计算平台，来支撑网游，肯定是将来云计算的一个killer application。
网游不仅仅需要云存储，而且需要云计算，可以全面体现云计算的优势。
但是老问题依然存在。网游是内容导向的产品，搞不好会得罪人，而且怎么得罪的，预先甚至不知道，防不胜防。
从Google之类云计算提供商角度出发，最好是专注于技术支撑，而不去涉足网游的设计。
但是如果让第三方设计网游，1. 如何控制它对云计算资源的调度，2. 如何防范它的越轨行为。
这两个老问题，还是绕不过去。
家园 这个容易。google只提供云端支持，由下游提供应用 我只是用MUD对比说明云计算的使用。
google除了企业计算，不必关心内容。至于网游之类的应用，可以由google提供云计算平台和存储能力，由下游ASP提供自主开发的应用(经google认证安全可靠高效)，利用google的云端运行后分发给用户。这样的模式，google基本上可以躲开内容供应商的帽子了。
控制第三方对资源的调度，可以通过控制存储的quota，计算能力的MIPS或者优先级来实现。当然，这完全取决于google云端的设计。我们这儿只能说说自己的想法而已。
防止越轨比较简单。存储上的安全控制，线程上的防止内存溢出之类的都是技术手段。应该难不倒google。
家园 不是不能做，而是还没有做 控制第三方对资源的调度，可以通过控制存储的quota，计算能力的MIPS或者优先级来实现。当然，这完全取决于google云端的设计。我们这儿只能说说自己的想法而已。防止越轨比较简单。存储上的安全控制，线程上的防止内存溢出之类的都是技术手段。应该难不倒google。
完全同意。
只是Google好像还没有做，至少还没有announce。
家园 【原创】云里雾里的云计算 [4] 【5】是云计算，还是云存储？
Gadgets的目标是方便大家建网站。但是单靠gadgets，建网站的工作还是不够方便。
通常网站有三个组成部分，1. 网页，2. 业务逻辑， 3. 数据存储。如果说网页相当于商店，那么业务逻辑相当于车间，而数据存储相当于仓库。商店，车间和仓库三者中，技术含量最高的，当属车间。
外链图片需谨慎，可能会被源头改Manufacture in old time
Courtesy http://www.atlantic-cable.com/Cables/1857-58Atlantic/Cable-Manufacture.jpg
车间管理可以大致概括为两件事，1. 工艺流程，2. 资源调度。工艺流程关心的是，先做什么，后做什么，才能生产一个完整的产品。资源调度的问题是，哪个工人，用哪台机器，在哪个时间，做什么。
网站的业务逻辑处理，大致来说也分业务流程和资源调度两部分。
流程的设计，每个网站不尽相同。譬如有两个网站，一个招聘人才，另一个销售图书，它们的业务流程非常不一样。但是销售图书的网站，与销售电器的网站，它们两者的业务流程相对比较接近。
流程设计千变万化，而资源调度却有章可循。所谓计算机资源，无非是这五种东西，1. CPU，2. RAM，3. Disk，4. RAM-Disk IO，5. Network。资源调度，无非是优化使用这五种资源，使之在最短的时间内，完成分配来的工作。
优化使用这五种资源，目标挺明确，实施起来却相当不容易。一日偶遇一仙人，谈到计算资源调度优化的问题，仙人说，他有一套五行八卦的优化办法，用中国古代智慧，解决当今科技难题。我把仙人的办法概括为以下几个要点，
1. 五行相生相克，系统优化不能偏执单一资源的优化。
2. 系统的总体效率需要一个测度，这个测度被称为“阴阳度”。
3. 阴阳度不是五种资源的简单加权和。阴阳度与五行的关系是非线性的，这种非线性关系可以参照河图洛书来确定，譬如规定五行中土的阴阳度为0，河图数零点的阴阳度为-5，洛书数零点的阴阳度为-10。
4. 时刻监控系统总体的阴阳度，阴阳度变化的正常模式可以分为太极，太虚以及太一三种。
5. 当阴阳度的变化偏离了正常的模式，就需要对系统进行调整。调整的办法参见“说卦”中的六种范式，即洛书逆式，先天八卦，后天八卦，神也者，洛书顺式，和乾坤六子。
仙人的办法听上去很有美感，但是操作起来却有难度。正在困惑之时，听到Google宣布，“我有办法解决资源调度问题，你们只须专注于业务流程”，确实为之感召。
Google的解决办法，是AppEngine。
外链图片需谨慎，可能会被源头改Google AppEngine logo
Courtesy http://img.genbeta.com/2008/04/google-app-engine.png
问题是，Google AppEngine真得能够优化任何业务流程的资源调度吗？
譬如有人想建一个人才招聘网站，招聘的业务流程如下图所示。Google打算劝说这个人把网站建在Google云计算平台上，做为技术支持，AppEngine应该提供哪些功能？
外链图片需谨慎，可能会被源头改Recruiting process business logic
Courtesy http://www.infoq.com/resource/articles/seven-fallacies-of-bpm/en/resources/job_application_process.jpg
猛一看，觉得很容易，流程清楚，算法简单。只需要把流程中诸多环节，归并成几个模块，即大功告成。
再看看，事情没那么简单。整个流程不是从头到尾一次走完，譬如interview会有好几次，然后过几天才会发offer。所以，应当把整个流程的每个模块独立出来，封装成服务，每个服务能够独立运行。召之即来，来之能战。平时不用，不占资源。
SOA（Service Oriented Architecture）还有一个好处，是便于重组业务流程。譬如系统上线以后，发现在面试（interview）以前，还需要添加一个电话约谈（phone screen）的环节。如果流程中每个服务都能独立运行，添加新的服务就很容易，不至于造成牵一发动全身的局面。
SOA的结构设计，有很多优点，但是仍然有遗留问题。如果同时有很多人使用这个招聘网，系统的吞吐量需要随之加大，怎么办？增加系统吞吐量的办法，有两条思路。
第一种办法是购置多台机器，每台机器上安装所有服务。当很多人同时使用招聘网的时候，把他们的需求均匀转发到各个机器上去，这样每台机器的负载都不大，但是整个系统的吞吐量增加。
第二种办法的效率更高，它可以用少数机器，达到和第一种办法相同的吞吐量。或者，用相同数量的机器，在更短的时间内完成所有任务。这种办法首先分析每个服务耗费的资源，譬如CPU时间和RAM空间等等。然后给资源耗费量大的服务多分配几台机器，以免它们成为整个业务流程的瓶颈。
第二种办法虽然有很多好处，但是实现起来有些难处。首先是如何监控和分析每个服务的资源消耗，其次是如何自动把服务从一台机器转移到另一台机器去运行。
或许有人会问，为什么不提多线程的办法呢？所谓多线程是把多个任务交给多个线程去完成，这些线程交叉使用CPU，IO，Disk等等资源，减少使用这些资源前的排队时间。多线程的办法，关注的是每个服务的实现细节。而我们刚才讨论的，是服务与服务之间怎么整合的问题，所以，是不同层面的问题。
又有人问，为什么不提MapReduce之类并行处理的办法？与多线程一样，MapReduce关注的是每个服务的实现细节，是不同层面的问题。
回到前面的问题，如果Google打算劝说大家把网站建在Google云计算平台上，做为技术支持，AppEngine应该提供哪些功能？
1. 开放更底层的APIs，而不仅仅是Python的APIs。便于第三方开发人员，实现逻辑复杂的模块，资源使用方式复杂的模块。
2. 提供IDE，方便第三方开发人员把模块封装成符合Google云计算平台规范的服务。
3. 开发调度工具，用于监督各个服务资源消耗，分配合适的机器去负责各个服务运行等等。
4. 开发预警和修复工具。开放自己的平台，去运行第三方人员（外人）开发的服务。对于Google来讲，有理由提高戒备，预防云计算平台崩溃，万一崩溃了，能够迅速修复。
这四个功能，AppEngine目前都没有实现，所以云计算平台，对于第三方开发人员来说，暂时不是计算平台，而是存储平台。
关键词(Tags): #硅谷评论，家园 这个不难，借用SAP的思想，模块化结构+优化引擎可以解决 首先google可以提供很多模块，有大模块，如Interview模块，然后再提供小模块，如Interview模块中包含的appointment, phone interview, in-person interview, evaluation等等，并提供workflow工具。这样用户即可以用现成的大模块实施业务，也可以利用这些小模块和workflow构造出自己的interview模块。甚至，google还可以接受用户自定义的certified的模块以实现特殊的应用。有了这三种方法，我相信google可以应付99%的企业计算了。
而对于每个模块的执行，gogle可以在设计时对workflow实施优化，也可以实时监控并根据服务器负荷做real time balance。这个在稍稍大型的软件中都不是新技术了。