pass云开发可以在本地开发吗

pass云开发可以在本地开发吗

近两年，云计算的热潮此起彼伏，很多声音来自存储、服务器、简单的NoSQL访问，并且误导大众云计算就像自来水、民用电的取用一样，但这只是云计算的准备阶段或初级阶段，就好比给您一台没有浏览器、没有Office和其他文档阅读、编辑的半裸机一样，而真正为您定制的应用或您用于获利的应用还“飘”在地上。相对而言，Azure平台更贴近应用，它提供的不是大众无法直接使用的“基础设施”，而是各类实实在在的应用软件，只不过“飘”在云上而已。
如果用软件运行机制划分，云应用则是站在一个新的起点，而Visual Studio 2010无疑为开发此类应用提供了快捷方式：本质上，云计算需要屏蔽掉物理区域、承载节点、网络拓扑等因素向用户透明地提供服务，而Azure恰恰提供了这些内容：
（1）、具备其他云服务商的基础环境能力。
（2）、整合了Windows Live、Dynamics和WindowsServer产品，其中很多功能非常适合商业环境，类似功能对于ISV或个体开发者而言如果从头开始做，技术上难度过大，而且即便技术上能完成也错失了商业机会。
（3）、充分保护现有开发技能投资，使用Azure的开发者可以继续把绝大部分本地WinForm应用、ASP.NET应用的经验运用到Azure中。
不过，尽管Azure上述特点提供了一个较为可靠的运行环境和API体系，但用户自己开发的云应用能否稳定可靠运行几乎是另一码事，就好像同样一个基于 SQL Server 2008类似功能的系统，有的开发者可以支持200个并发用户，有的只能支持10个并发。据笔者经验，开发云应用在实现阶段的步骤上有些特别之处：
（1）、前期，通过原型系统验证API。考虑云应用开发在业界还比较有限，出于知识积累的考虑，建议采用非抛弃型原型较好，便于团队学习、理解、沉淀相关技术。不过，现阶段也有些不利因素，由于云应用开发尚不甚成熟，API的非兼容更新经常发生，为此即便是原型也建议运用设计模型技巧，在部分关键API处预留后手。
（2）、然后，基于威胁建模分析安全性，对原型进行必要的重构和简单的渗透测试，无论采用CIA（保密性、完整性、可用性：C=Confidentiality,I=Integrity, A=Availability）的防御模型还是SDL的 STRIDE（Spoofing user identity, Tampering with data, Repudiation, Information disclosure, Denial of service, Elevation of privilege）攻击模型，开发云应用必须先过安全关。另外，必须慎重权衡HTTPS的使用范围，这里范围包括三个维度“功能”、“时间”、“数据量”，做到“刚刚够用”（No more no less），否则代价就是真金白银。
（3）、接着，开发功能并通过必要的单元测试、集成测试确认功能有效。
（4）、下面是配置云运行环境，根据不同资源情况下的运行表现在应用中留出“活扣”，便于实际部署后可以根据吞吐率有先手布局。这步非常关键，因为不同于我们以往的企业应用或互联网应用，Azure平台允许我们进行类似的模拟，做类似的装载回归其成本很低。
（5）、最后，根据预估的资源使用情况，选择合理的租费套餐。相对以往的开发，在云平台部署也有不少优势，毕竟装载回归阶段很多租费已基本量化。
（注：另外，云应用还需必要的“非云”运维监控机制保证，还要考虑相应的本地信息备份能力，否则“亡羊”都没处“补牢”。）
上述5个步骤结合Visual Studio 2010均可以较为便捷的完成。不过对于熟悉WinForm应用和ASP.NET应用的开发人员，如何使用Azure存储机制需要一个适应过程：
（1）、Blob Service：虽然提供二进制信息的存储，但最好慎用，对于二进制的多媒体信息而言，采用该服务成本偏高，尽管官方有类似的标杆系统，但考虑到资费以及国内调用效率，建议租用或自建独立的流媒体服务器和文件服务器，调试阶段也须慎重安排调用次序和资源访问路径。
（2）、Table Service：非常有用，但使用中建议考虑自己开发一些“土法”编码的JavaScript、XLS函数，在信息提交前将稀疏的用户数据进行处理，在展现时进行反向处理，例如：一条微博内容为“大胜印尼9个球！！！！！！！！！！！！”，不妨在提交前处理为“大胜印尼9个球/[!12/]”，虽然有些烦琐但考虑到 Azure的收费方式，能省还是给自己省点。之所以没有直接提压缩算法，同样因为Azure的收费方式，您可以根据应用的内容特点，权宜计算时间和存储空间。
（3）、Queue Service：是个容易被忽略但其实更容易出彩的服务，不仅仅限于向Work Role发送消息。一方面通过他的异步处理能力，常常可以在相同Host Service 使用的情况下支持多并发用户；另外，在处理结果（包括：查询结果）交付方面也有一定灵活性，减少因为多个处理流程争用资源产生的无谓支出，毕竟本地数据库死锁等待一段时间后Kill一方这个处理，资源消耗相对较小、成本低，类似问题出现在云库（毕竟现阶段SQL Azure的锁处理不如本地 SQL Server的完善）消耗可是实实在在的费用。采用Queue Service可以通过分隔、分工处理流程的方法，将争用面缩小，让您的云应用可以“悠着劲儿”的完成处理。