微软云计算定义:云+端、软件+服务

 关于云计算,微软是个新人。但是,提起微软的云计算,很容易浮现出这样的字母和符号:Azure、S+S。微软的思路很清晰,它把未来的计算定义在云+端、软件+服务因为对于Amazon.com和G

     关于“云”计算,微软是个新人。但是,提起微软的云计算,很容易浮现出这样的字母和符号:Azure、S+S。微软的思路很清晰,它把未来的计算定义在 云+端、软件+服务——因为对于Amazon.com和Google所代表的云服务的意义,微软面对的挑战是如何成为用户的唯一的选择而不是包括前两者的 选择之一。


  以软件或者说以推出端的产品而发家的微软,并不代表它对于网络计算没有清楚的技术方向和商业认识,更多的时候,它惯用的颠覆式做法为市场机会到来时做好准备,或者至少是提供了可以借鉴的经验。


  “云计算对微软来说并不是一个新的概念。”张亚勤表示。2000年6月,微软正式提出了.NET战略,在当时已经初现“云计算”的端倪,“只是 因为翻译不同而被称为网络计算”。尽管今天.NET已被微软公开评价“并不完全成功”,但是已经可能成为微软在今天推动云端计算的前车之鉴。


  微软当时认为,所有的存储都会到网络上,这是.NET战略中的三大重点之一,也成为.NET的软肋;另外两个是基于网络的操作系统和开发工具的 架构,以及更加人性化的自然界面。.NET战略是将微软所开发的各种软件与互联网紧密结合起来,目的是简化各种计算设备之间的信息共享与交换,微软也寄望 借此把业务重点转移到互联网上。


  从这个角度看,.NET所走的弯路是值得的。微软承认,.NET技术很伟大,只是迷失了方向。云计算可以使微软继续其从软件公司到网络平台服务提供者的转变的梦想。今天来看,这个梦想就是Windows Azure。


  去年10月,微软首席软件架构师Ray Ozzie推出微软云计算平台Windows Azure,这将把微软带入一个崭新的时代。Azure来源于法语,语意为天空一样的湛蓝色,这也正是微软所希望的,把其打造成承载所有云上的应用和服务的蓝天。


  Azure服务平台的底层是微软新一代的云操作系统Windows Azure,包括计算、存储、管理等。在Windows Azure操作系统之上,目前运行着Live Services,.NET Services,SQL Services,SharePoint Services和Dynamics CRM Services五大服务,作为未来微软下一代网络服务的基础。


  其中,Live Services是以用户为中心的,提供诸如联系人信息、博客、图片等服务;.NET Services提供应用开发所需要的通用服务,比如服务总线、访问控制和工作流服务等,用户可以不必一遍又一遍开发重复的功能和基础设施;SQL Services提供了数据管理的服务;SharePoint Services提供协作服务,而Dynamics CRM Services则提供类似Salesforce的应用级的服务。在Windows体系中,现场服务器架构和云计算并不矛盾,而是互相补充,这也是 Azure服务平台独特的策略。


  这也就意味着,从个人用户、到企业、到第三方开发人员都可以获得来自微软的云端服务,而这样的平台会造就一个“云产业”。


  张亚勤同时对记者表示,未来的云计算会更加开放。并且在把计算需求交付给远端的“云”时,终端也会越来越多种多样:个人电脑、上网本、智能手 机、汽车、电器——只要是带电的物体,都能像享受“电力”一样享受云服务。作为支撑,而微软也将会投入巨资在全球范围建造数据中心。


  随着云计算时代的到来,软件开发模式和商业模型都将进入全面开放组合的新时代。而张亚勤说,“对于云端计算,要有信心、也要有耐心。”微软的行动告诉人们,在技术日新月异变化的时代,要抓住新技术的市场机会,人“云”亦“云”是行不通的。

 

转自:http://webvshcom.2181612061.open-source.cn/a/caijing/qita/2009/1007/77.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
第1章我们的领域: 会议管理系统1 1.1Contoso公司简介1 1.2谁与我们同行2 1.3Contoso会议管理系统3 1.3.1系统概览3 1.3.2非功能性需求4 1.4开始我们的旅程5 1.5更多信息5 第2章领域分解——站点规划6 2.1本章术语定义6 2.2会议管理系统里面的有界上下文7 2.2.1订单和注册有界上下文7 2.2.2会议管理有界上下文7 2.2.3支付有界上下文8 2.2.4不包括在内的有界上下文8 2.2.5Contoso会议管理系统的上下文路线图9 2.3为什么选择这些有界上下文10 2.4更多信息11 第3章订单和注册有界上下文12 3.1订单和注册有界上下文简介12 3.2本章术语定义13 3.3领域定义(普适语言)14 3.4订单创建的需求分析16 3.5系统架构17探索CQRS和事件源目录3.6模式和概念17 3.6.1系统验证21 3.6.2交易边界22 3.6.3并发处理22 3.6.4Aggregates和Aggregate Roots22 3.7实现细节23 3.7.1高层架构23 3.7.2写者模型28 3.7.3使用Windows Azure服务总线37 3.8对测试的影响44 3.9本章小结47 3.10更多信息47 第4章扩展和改进订单和注册有界上下文48 4.1修改有界上下文48 4.1.1本章术语定义49 4.1.2用户需求49 4.1.3系统架构49 4.2模式和概念51 4.2.1记录定位器51 4.2.2读者查询51 4.2.3向读者提供部分履行的订单信息54 4.2.4CQRS命令验证55 4.2.5倒计时定时器和读者模型56 4.3实现细节56 4.3.1订单访问码(记录定位器)57 4.3.2倒计时定时器58 4.3.3使用ASP.NET MVC验证60 4.3.4将改动推送到读者62 4.3.5重构SeatsAvailability aggregate66 4.4对测试的影响68 4.4.1接受测试和领域专家68 4.4.2使用SpecFlow功能来定义接受测试68 4.4.3通过测试来帮助开发人员理解消息流75 4.5代码理解的旅程: 痛苦、释放和学习的故事77 4.5.1测试很重要77 4.5.2领域测试78 4.5.3硬币的另外一面80 4.6本章小结83 4.7更多信息84 第5章准备V1发布85 5.1Contoso会议管理系统的V1发布版85 5.1.1本章术语定义85 5.1.2用户需求86 5.1.3系统架构87 5.2模式和概念91 5.2.1事件源91 5.2.2基于任务的用户界面92 5.2.3有界上下文之间的集成95 5.2.4分布式交易和事件源98 5.2.5自治与集权99 5.2.6读者的实现方法100 5.2.7最终一致性100 5.3实现细节101 5.3.1会议管理有界上下文101 5.3.2支付有界上下文102 5.3.3事件源105 5.3.4基于Windows Azure表格的事件库111 5.3.5订单总价计算114 5.4对测试的影响114 5.4.1时序问题114 5.4.2引入领域专家115 5.5本章小结115 5.6更多信息115 第6章系统版本控制116 6.1本章术语定义116 6.1.1用户需求116 6.1.2系统架构117 6.2模式和概念118 6.2.1修改事件定义118 6.2.2确保消息的自洽性119 6.2.3集成事件的保存121 6.2.4消息排序122 6.3实现细节123 6.3.1对零成本订单的支持123 6.3.2显示剩余座位数127 6.3.3删除重复命令130 6.3.4确保消息排序131 6.3.5保存会议管理有界上下文的事件135 6.3.6从V1版本迁移到V2版本139 6.4对测试的影响140 6.4.1重访SpecFlow140 6.4.2在迁移过程中发现错误143 6.5本章小结143 6.6更多信息144 第7章加入弹性和优化性能145 7.1本章术语定义145 7.2系统架构145 7.3加入弹性147 7.3.1增加事件重复处理时的弹性148 7.3.2确保命令的发送148 7.4优化性能148 7.4.1优化前的用户界面流程149 7.4.2用户界面优化150 7.4.3基础设施优化151 7.5无停机迁移158 7.6实现细节159 7.6.1改进RegistrationProcessManager类160 7.6.2用户界面流程优化165 7.6.3消息的异步接收、处理和发送170 7.6.4在流程内部对命令进行同步处理171 7.6.5使用备忘录模式来实现快照173 7.6.6对事件进行并行发布175 7.6.7在订购服务里面对消息进行过滤176 7.6.8为SeatsAvailability aggregate创建专门的SessionSubscriptionReceiver 实例177 7.6.9缓存读者模型数据179 7.6.10使用多个议题来划分服务总线180 7.6.11其他的优化和强化措施181 7.7对测试的影响184 7.7.1集成测试185 7.7.2用户界面测试185 7.8本章小结185 7.9更多信息185 第8章尾声: 经验教训186 8.1我们学到了什么186 8.1.1性能很重要186 8.1.2实现消息驱动并不简单187 8.1.3平台的挑战187 8.1.4不同的CQRS188 8.1.5事件源和交易日志记录190 8.1.6引入领域专家190 8.1.7什么时候该使用CQRS190 8.2如果重新来过,我们会做的有什么不同191 8.2.1以牢靠的消息和保存基础设施为起点191 8.2.2更好地利用基础设施的能力191 8.2.3采纳更加系统化的方法来实现流程管理器192 8.2.4对应用程序实施不同的划分192 8.2.5以不同方式组织项目团队192 8.2.6对领域和有界上下文的CQRS适用性进行评估192 8.2.7为性能进行规划192 8.2.8重新考虑用户界面193 8.2.9探索事件源的其他用处193 8.2.10探索有界上下文的集成问题193 8.3更多信息194

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值