中国最早的"云平台"---刘邦手下的"谋臣武将"

     声明：最近一直想写篇关于云计算（及云存储）方面的文章，好把我个人对于当下“云”的一些理解说
出来。考虑目前网上的文章，视频BLOG介绍这方面的内容已有不少。另外在园子里的Anytao也开始写有关
方面的系列文章，我不想再写那方面的东西了，就把希望就全放在Anytao的那个系列上吧。

     目前网上关于云计算的文章都是立足当下，放眼未来。而我这篇则把视角倒退回两千多年以前的楚汉相
争时期，在那时的政治舞台上只有两个利益集团（不是google和微软，呵呵）。这两个集团的核心人物分别
是刘邦（汉高祖）和楚霸王项羽。

    而提到刘邦就会让人想起他在战胜项羽之后对他的手下说的那段至今仍发人深醒的话：  

   夫运筹帷幄之中，决胜千里之外，吾不如子房（张良字子房）；镇国家，抚百姓，给饷馈（供给军饷），
不绝粮道，吾不如萧何；连百万之众，战必胜，攻必取，吾不如韩信。

 

     其实这里的张良，萧何，韩信，还有陈平，彭越（中国最早的游击战发明人）。就是刘邦眼中的云计算
平台。

    

     刘邦作为一个志向远大的枭雄，其内心的欲望不可说不强，但其贵有自知之明。对自己的不足（特别是
智谋和军事上）向来有清醒的认识。同时又能克制内心的欲望。这个原型很想当下的企业家或公司老总。其
总想将自己的企业发展成为行业领军人物，甚至是下一个GOOGLE或FACEBOOK。这样的野心是刺激其不断
努力，超越自身的强大动力。但人必定能力精力有限，不可能事必亲躬。同时自己的见识阅历，经验等又不
够，空有抱负却无人助之。刘邦相对来说要幸运一些，起码他手下有上述的这些能人，这就好比拥有了那个
时代最为强大的“搜索引擎”。刘邦要做的就是当遇到了政治或军事问题时，只要登陆google的“智谋搜索
（张良）”和“军事搜索（韩信和彭越）”输入对手名称“项羽”这个关键字就可以了。而在云端，这些谋
士和将领则开始根据自己的平生所学的知识储备和作战经验进行“综合运算和评估”返回来的是一条条的锦
囊妙计和军事方略和具体布署。当然这个云计算平台的返回结果会有一些（有时会很多），必定这里有好主
意也有“馊主意”，而作为“大汉阵营”的董事长兼CEO，会根据自己的实际情况来加以灵活采纳。

    但这里还是会牵扯一个问题，即刘邦如何确保他头顶上的“云”是在为他的阵营（企业公司）来运算并
且是正确运算着呢？这一点可以看看刘邦是怎么做的：

     话说在刘邦先进汉中之后，他的云平台里的一个谋士（具体名字没有记载）给他出了个馊主意，让他派
兵把守“函谷关”（函谷关是咸阳的一个重要关口，素有“一夫当关，万夫莫开”的说法）。这样当项羽打
过来时，就通挡住他的军队，刘邦就可安心当他的“关中王”了。但项羽是何许人，在函谷关受到阻击后不
费什么力气就打下来了。后来刘邦的左司马曹无伤看到风头不对，暗地投靠到项羽阵营通风报信，说刘邦要
当关中王（原文：沛公欲王关中，使子婴为相，珍宝尽有之）。项羽听后大怒，命手下将领明天一早吃饱饭
后就出兵把刘邦灭了。

     而这时项羽阵营中又出来一个人叫项伯，他与刘邦手下的张良是好友（估计那时就有SNS了）。所以项
伯连夜通风险报信，来到刘邦这边找张良，让他（张良）赶紧跑路。而这时张良可以说已与刘邦穿一条裤子
了。所以张良就赶紧来通知刘邦，这时刘邦大惊，说了那句他经常用的口头禅：“为之奈何（我该怎么办呢
）”。

     请大家注意，这句话会造成下面这个操作：

     通过IE访问那时最厉害的智谋搜索引擎--“张良智谋插索”，并提交了“救命呀，咋整呀呀!!!!!!”
这个查询请求。
   
     当前张良心中早就计划了，他让刘帮装怂，并给项羽赔理解道歉。并将缴获的珠宝美女（刘帮很好这
口儿的）一并上缴给项羽。刘邦觉得有理，从之。

     接下来刘邦问了一句非常重要的话：“你跟那个项伯是个啥关系，他为什么要通知你”。这句话非常
重要，他反应了刘邦高度的“政治警觉性（不是科学发展观呀）”。当然张良就把与项伯有生死之交的事
说了一遍。之后刘邦感觉放心了，都最终按张良的计谋办，也就有了历史上著名的“鸿门宴”。

     说了上面一通，一个核心就是企业要能够让当前运行的云计算的结果对自己来说是“可靠安全正确”
的，必定企业是把自己要分析的核心数据（商业机密）提供上去，做为原始数据给了云端，并怀着不安的
心情等待着查询结果（想想那时刘邦的心情）。

    当然AZURE提供了“云计算平台权限管理服务”来加强这方面内容的认证和安全保障。如下图：
    
    
    
    
    请大家注意其中的以数据序号标识的内容，其定义了权限认证的一个正常流程是个什么样子：）
   
    除此之外，我想企业和开发者还想从云端中得到别的一些东西，它们可能包括：   

     1.计算过程的透明性（这一点我觉得非常重要，这就好比我把钱交给了“证券投资公司”，我要了解
当前交易员（操盘手）的交易流程，否则他只会告诉我“涨”和“跌”，而我不仅要结果。还要知道为什
么会这样）。
    
     2.持久性。因为云端计算是个复杂的过程，有时计算时间可能会较长。如果时间太长，而此时云里又
出现了什么问题导致计算被暂时中断，则这些临时结果可以被安全的保存下来（非本企业不能访问这些临
时数据），等条件具备时再运行其余任务。要实现这个需求就需要将任务持久化到云端。而目前Azure提
供了SQL服务、Live服务、.NET服务(工作流和认证)、SharePoint和动态CRM等组件。比如工作流就是
一个不错的持久性支持组件，我们可以将当前运行在云端的应用程序实现（单一实例运行，可参见云端的
部署文件中有相应的XML节点设置）和当前已执行完的操作持久化到数据库(Sqlserver)中或使用AZURE
的SQL服务组件，这样就实现了我上面所谈到的需求（当然这些组件当初是否就是出于这样的意图而设计
的，这里就不得而知了）。
    当然将来AZURE是否支持WF4还不清楚（有知道朋友麻烦请通知我，呵呵），因为WF4将会支持双向
的持久通信，这对于那些运行时间超长且要回传数据到客户端的计算任务来说是个福音。
    
     3.可跟踪性，这一点相对于开发的可调试性，而不是仅在本地开发调试，还要支持远程调试，这是因
为云端的复杂操作流程无法在桌面开发环境下简单重现，这也就给我们找出当前应用中存在的问题造成了
一定程度上的麻烦，希望Azure能够提供类型SandBox这样的工具，这样可以在云端有个测试运行环境。
相信这会是个不小的亮点。

 

      另外就是在Azure内也实现了总线结构，但我目前还不太清楚其与BIZTALK中的ESB结构是什么关系，
或者说是没有关系。Azure是用于服务的发布和订阅的服务总线，这一点比较好理解，但如何从SOA中的服
务总线角度来说，实现消息的订阅发布才是根本。而之前亚马逊公司（Amazon.com, Inc.，纳斯达克股票
代码：AMZN）旗下的亚马逊网络服务有限责任公司(Amazon Web Services LLC，简称AWS）研究的产
品是基于面向服务上的，只是现在云火了，也来凑热闹，发布了用于"内容传递的自助式即用即付网络服务"
CloudFront。聊到这里，我越来越感觉这个云就是SOA的“外壳”。而这个SOA也不是简单面向企业级的
而是面向整个互联网提供服务的SOA架构系统。但这里不如再假设一把： 

   GOOGLE做互联网搜索大赚一笔后，将触手延伸到了企业级搜索服务。那高高在上的云会不会在市场成
熟之后也推出相应的企业级云服务呢。我想这会是云的一个方向。

    
     说了这些，云里雾里的，头有点大了。最后不妨提醒一下：
   
     以云为卖点，认为这是企业全部的核心竞争力，然后用一支铅笔写"商业计划书"的Leader，等他看到铅
笔的铅蕊类型时，上会赫然写着“2B”。

    好了，今天的内容就先“乱喷”到这里了：）

    原文链接:http://www.cnblogs.com/daizhj/archive/2008/11/20/1337513.html

    作者: daizhj, 代震军

    Tags: 刘邦,云,Azure,Workflow

    网址: http://daizhj.cnblogs.com/