云计算设计模式指南系列(0) - 背景简介及内容提要
大家好。这个博客很久没有更新了，这半年多来在工作重心上有所变动，现在主要还是研究Azure以及服务端开发这块了。不过最近Windows
App方面的变化的确令人激动，今后在App开发这块应该还会持续关注。我们准备开始撰写若干篇关于云计算以及Azure的博客文章，暂定名《云计算设计模式指南》，这是第0篇，主要是给大家介绍一下我们的想法以及作为系列文章的目录。
首先必须向Patterns & Practices（模式与实践,P&P）小组及其Cloud Development系列致敬。我们希望有更多的开发者能够关注到P&P的Cloud Design Patterns: Prescriptive
Architecture Guidance for Cloud Applications。该系列中包含了24个云计算设计模式以及10个通用场景的设计指导。这里所讲的设计模式并不是指类似经典GoF的设计模式的侧重面向对象、软件工程方面的设计指引，而是联系云计算环境的一些特质和优势所作出的架构设计层次最佳实践。可贵之处在于，事实上其中涉及到Azure的功能、服务方面的内容并不占太多篇幅，更多的只是在描述某个场景的最佳实践的同时，提及对应的在Azure中能通过哪些服务组件来完成目标。所以该系列文章老少咸宜，不管开发者关心的是不是Azure或是.Net，都将从中受益。
言归正传，正值Azure在中国大陆正式商用一周年之际，我们最近也在构思一系列的关于Azure以及云计算架构设计方面的中文博客文章，内容主要来自于平时的实践和积累，所以在引用和翻译到一些Azure官方和非官方的文档资料的同时，还会尝试加入一些个人的观点、学习笔记以及样例代码、项目。早些在学习前文所提到的Cloud Design Patterns系列的时候就已经向几乎身边所有关心Azure的同事朋友强烈推荐阅读。
我们在日常工作中接触到不少国内外的Azure用户，主要还是把Azure平台当做IDC托管机房来用，没有或者来不及考虑利用一些Azure所提供的非常优秀的特性和服务来优化开发和降低运维成本。现在提笔写这个系列文章的最主要的一个动机是希望更多的开发者在接触到云计算特别是Azure的时候，除了IaaS 的VM、Networking等基础设施的迁移之外，能够在开发设计层面重新审视一下当前的实现和架构是否已经充分利用到了云平台的优势，是否能够适应分布式计算存储、易伸缩等架构特性。
以下是我想到的内容大纲，不保证坑会被完全且按次序在接下来几个月中填满，但一定尽力。
Cache-Aside。考虑将一个传统Web 服务的满足横向扩展（scale out）的特性并迁移到云端的第一步往往是检查其缓存机制，这里并不是指狭义上的页面缓存或是数据缓存，而是包括了应用逻辑是否会依赖于某个特别计算实例内的磁盘内容、内存对象、全局变量和缓存数据等等。Azure提供了多种缓存服务但当前官方推荐的是使用Redis Service，不仅功能强大而且Client API通用，我们可以通过Linux或Windows Server VM来部署自己的Redis服务。
Competing Consumer，Priority Queue，Queue-based Load Leveling Pattern，Scheduler
Agent Supervisor Pattern等多方消息传递和分发的相关模式。不同节点之间的通讯消息，在经过队列Queue或主题Topic的缓冲和分发之后，能够极大程度上提高消息传递的效率和可靠性。Azure中消息队列服务我们一般会用到Service Bus。消息传递是个非常大的主题，我们将联系实例场景用最基础的代码演示Service Bus对以上这几个经典场景模式的实现。
Retry pattern。在公有云的环境中，整套解决方案中所涉及的包括虚拟机、网站、存储、数据库、消息队列等等服务可能散落在多个机柜甚至数据中心，而各个服务所在的物理宿主可能被多个实例共享，数据包也可能会被高负荷的网络所临时阻塞。所以在服务间互相调用的时候会有一定几率临时性地产生一些极短暂的错误（transient error），而这些错误往往并不是服务器这段的问题，且只需毫秒级别的等待重试就能解决问题。为了程序能够平稳运行，我们需要能识别这些transient error并加入重试Retry的相关机制。
Cost Effectiveness Design成本效益最大化设计。了解Azure的计费模式介绍、制定缩放计划、识别缩放单元Scale Unit、通过Management API进行自动化操作和管理将会显著降低运维成本，这些特性也是云平台同托管机房的最大的优势。而在功能实现层面，我们可以通过Azure平台或SDK内建的诊断工具（Diagnostics）集中记录和分析服务的运行情况，以分析最优的部署和缩放方案。同时某些细节功能的优化实现也能提高服务接口的吞吐量，更高效合理地利用带宽和存储资源。
NoSQL非关系型数据库实践。同传统关系型数据库相比，主流的NoSQL解决方案在可扩展性、高可用性、并发查询等方面有极大优势，键-值的基本存储和查询方式也允许表内数据结构可变（Schema Free），更能适应海量以及非结构数据的大规模存储查询的需要。 Azure提供了Storage
Table、DocumentDB等NoSQL服务，亦可自行在Linux VM上部署Mongo DB。
Troubleshooting Azure故障排错的方法和工具。日常工作中我们需要同客户一起解决Azure使用过程中碰到的问题。有时我们通过查询数据中心端能够定位问题所在，但是更多时候我们会通过一些更高效的方法来帮助排错。而这里所涉及到的一些工具和方法本身其实并不局限于MSFT内部或付费客户。
同时，我们当前正在开发一个原型项目(POC)。初步想法是构建可随时缩放、扩展的爬虫集群，从外部数据源抓取数据，存储到本地的数据库。最终客户端能够通过API查询数据。抓取操作可以实时响应客户端要求，也能按照既定计划由专门的任务服务器所统筹。这个项目需要运用到多种云计算设计模式和场景，也会涉及到Azure的多个服务，包括Websites/WebRole/WorkerRole/ServiceBus/DocumentDB/Redis/API
Management等。待代码相对稳定成熟后会发布源代码和相关文档。。
其他方面之后亦会随时补充。
文章目录索引 (最后更新3/30)：
云计算设计模式指南系列（0） - 背景简介及内容提要
…