云计算设计模式指南系列(0) – 背景简介及内容提要

  大家好。这个博客很久没有更新了,这半年多来在工作重心上有所变动,现在主要还是研究Azure以及服务端开发这块了。不过最近WindowsApp方面的变化的确令人激动,今后在App开发这块应该还会持续关注。我们准备开始撰写若干篇关于云计算以及Azure的博客文章,暂定名《云计算设计模式指南》,这是第0篇,主要是给大家介绍一下我们的想法以及作为系列文章的目录。   首先必须向Patterns & Practices(模式与实践,P&P)小组及其Cloud Development系列致敬。我们希望有更多的开发者能够关注到P&P的Cloud Design Patterns: PrescriptiveArchitecture 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,SchedulerAgent 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…

0

NFC 与 Windows Phone 的那点事儿

说起NFC这个词儿应该已经不陌生了,在我们的生活中有很多使用场景都是使用的这项技术,例如公交卡,门禁,还有银联的闪付卡等等。并且近些年在移动设备上使用的场景也越来越多,例如 对 NFC TAG 的读写,对 NFC+蓝牙 耳机音响的支持,还有手机和手机之间的数据交换场景。 说起NFC这项技术其实也不算新奇了,许多手机都支持例如,Nokia、三星、SONY、HTC、小米都有机型硬件支持NFC的功能。在应用商店中搜索NFC也可以找到不少 NFC 相关的应用,但是目前来讲使用率还是个问题,不管怎样今天我还是想在这里为大家 分享一下在 Windows Phone 平台中对NFC功能的技术支持情况。对不对的请大家参考一下,多多提些意见。 从NFC在手机上支持的场景上看大致分为三种模式(点对点模式,主动模式,被动模式) 首先说一下点对点模式,点对点模式实际上就是在两台手机上都同时打开NFC后,将手机进行触碰(实现 Touch and Connect就是一个典型场景),通过NFC的数据交换,可以引导不同设备进行连接,例如应用和应用间的 Socket,蓝牙耳机、音响 (基于蓝牙配对)。这部分内容请参考我之前的文章 近场通信 NFC / Bluetooth Proximity   主动模式 (读/写 卡模式) 就是在移动设备中NFC模块产生射频场从外部采用相同标准的NFC标签中读写数据。这里面有一个典型的使用场景就是在Android手机上使用支付宝为公交卡充值。 或者从应用当中通过NFC读取银行卡的消费记录 以上两个场景都是属于主动模式,在 Windows Phone 生态系统中也不乏对NFC前景看好的朋友研究过此类功能。在 Windows Phone 8.0 SL 的框架下开发由于SDK的限制不能使用除了NDEN以外的通信格式。所以不能支持此功能,但是在现在的 Windows Universal 框架下 Windows Phone 8.1 可以通过Windows.Devices.SmartCards.SmartCardReader,Windows.Devices.Enumeration.DeviceInformation等SDK实现此功能,但是要有一点要注意的是和类似公交卡这样的NFC设备进行交互还需要手机硬件NFC芯片的支持,特需NXP PN547芯片 只要配置此种芯片的手机就可以实现 多种协议的NFC卡片交互例如:MIFARE Classic/Ultralight/DESfire 如果我没记错的话 公交卡是第一种。目前在Windows Phone…

0