武汉的开发者们注意啦!AI技术战略、框架以及最佳实战尽在Azure OpenAI Day 了解详情
写点什么

针对可扩展的、高可用的云架构的模式与反模式

  • 2014-05-09
  • 本文字数:2089 字

    阅读完需:约 7 分钟

当设计一个具有高可扩展性和可用性的系统时,最重要的就是架构选择问题。以 Azure 客户的用法为例,微软讨论了与 Azure 客户一起看到的模式和反模式,以及它对系统架构的四个方面有怎样的影响:

  • 可扩展性:我能否增加资源以处理增加的需求?
  • 可用性:我的应用能否容忍短暂的和持久的故障?
  • 可管理性:我是否有办法了解生产系统的健康和性能?
  • 可行性:我能否在时间和成本预算之内构建和维护这个系统?

可扩展性

可扩展性来自于两个方面:资源和密度。能力是指增加额外的硬件,它可能微不足道(在一个负载均衡器后增加额外的网络服务器)也可能非常地困难(增加一个次要的数据库服务器)。密度是指你能以怎样的效率去使用已经拥有的能力。传统的性能调优可以大幅地增加密度。

附带报导:点钱照明

在演讲期间有一个共同主题是“点钱照明”。 Mark Simms 说,它的意思是无缘无故地做一些毫无效率的事。例子包括使用网络地址转换(NAT)去代替本身的负载均衡器,或者把 XML 作为内部数据交换格式。

可度量的资源

可度量的资源是某些需要小心监控的东西。举例来说,数据库连接就是一种可度量的资源。作为一种有限的资源,滥用它就会大幅度地降低密度。

以 Azure SQL 为例具体来说。它的标准版只允许每个数据库有 180 个连接。在 ADO.NET 中默认的连接池是 100。所以如果你有两个连接到 Azure SQL 数据库的网络服务器,并且这些网络服务器泄漏连接,那么你很容易就会超出限额。

其他可度量资源的例子还包括认证服务器和第三方网络服务。这些有时被称为“隐形的资源”,因为开发人员设计架构时经常会忽略掉它们。

通过队列负载均衡

上传时的峰值可能会成为问题,尤其是在那些针对大量读取工作负载优化过的系统上。一种降低这种峰值的方式是,通过使用队列以等待时间交换可用性。

在这种方案下,新数据在数据库中不是同步保存的。相反,它们会被放到一个队列中,这是个后台进程监控器。这个后台进程可以使负载趋于平滑,以便数据库始终会被使用,而不是某些时候忙,其他时候闲。

使用队列的其他好处是可以批量处理那些工作。一般来说,把信息批量写入到数据库中要比一次一条记录快得多。

最后要说的是,这还增加了解耦点。后台进程或数据库可以宕掉,完全不会影响前端应用接受新数据的能力。

改善消息队列的可用性

如果过多的消息是被同时接收的,可以使用辅助的消息队列去保存过量的部分。为了做到这一点,你需要设计应用能够支持多个队列,即使最初你打算只部署有一个队列的应用。

如果消息超出了应用能够处理的大小,避免数据丢失的一种技术是把消息写到 blob 存储中。然后队列中的逻辑消息改成了保存一个指向 blob 入口的指针,而不是原始信息。

网络服务器可用性

为了保持网络服务器的可用性,所有下游的调用一定要异步并有界限的。界限一定要在超时和并发请求这两个方面。后者经常被忽略。有一个多少会使人觉得有些尴尬的例子,那就是 Visual Studio Online 长达两个小时的运行中断。这次运行中断的根本原因就是对一个外部认证服务器有过多的并发请求,它已经临时地瘫痪了。

认证服务

这让我们引出了下一个主题——认证服务。当一台认证服务器瘫痪的时候,它完全可以被其他稳定的应用代替。因为这个原因,微软强烈推荐使用联合认证服务器。

记录错误的数据

大多数开发人员都很清楚需要去验证数据,但是当验证失败的时候,他们不知道做什么。仅仅弃掉数据和抛出错误是不够的。应该把错误的数据以它原有的格式记录下来,以便开发人员能够断定为什么会有这种错误的请求。

大多数错误的请求源自不匹配的版本。当用户拥有的客户端比处理请求的服务器的版本更旧(或者更新)时就会产生这种错误。

反模式:配置

微软的 Azure 团队评审客户端代码的时候,他们仍会看到硬编码连接字符串和其他配置数据。当配置需要修改成立即指向不同的硬件时,这可能就会成为一个现实的问题了。

反模式:假定数据库的可靠性

对于最新一代的程序员来说,数据库连接已经给定了。数据库和内网故障几乎从来都不会发生。所以开发人员通常都不会针对异常进行检查。或者即使他们做了检查,也不会正确地处理,然后数据就丢失了。

反模式:SQL注入

没错,这是个非常普遍的问题。在某些情况下,非常基本的网络请求他们都已经检查出有明显的 SQL 注入漏洞了。

反模式:向错误的资源写日志

日志的基础设施需要与应用栈的其他部分隔离开来。如果日志和产品数据一样写到同一个数据库中,丢失一个数据库必然意味着其他数据库也同样丢失了。

反模式:重抛异常

这个领域有两个常见的反模式。第一个是使用“throw ex;”重新抛出异常,而不是用“throw;”,导致堆栈跟踪被丢失了。第二个是重新抛出异常,但却没有更高层的处理去捕获它。在.NET 2.0 和之后的版本中,这必然会导致整个应用的崩溃。

可以在 Building Big: Lessons Learned from Azure Customers 的第九频道查看整个视频。

查看英文原文 Patterns and Anti-Patterns for Scalable and Available Cloud Architectures


感谢崔康对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ )或者腾讯微博( @InfoQ )关注我们,并与我们的编辑和其他读者朋友交流。

2014-05-09 00:021672

评论

发布
暂无评论
发现更多内容

C++ 引用:他是坤坤也是鸡哥

子夜的星

c++ 引用 语法 引用参数函数

技术升级落地需要天时、地利、人和

石云升

极客时间 1月月更 技术领导力实战笔记

Source Map 原理

道道里

前端 webpack sourcemap

架构实战营4.2 存储复制架构随堂练习

西山薄凉

「架构实战营」

架构实战营4.3 存储分片分区架构随堂练习

西山薄凉

「架构实战营」

Python 内置界面开发框架 Tkinter入门篇 乙

eng八戒

Python GUI tkinter

网络安全中API常见漏洞

郑州埃文科技

API漏洞

大数据培训课程靠谱吗?

小谷哥

Java编程培训中心怎么样呢

小谷哥

可观测性之网站性能调优的实际案例-小白都看的懂

Yestodorrow

前端 可观测性 网站性能

web前端线下培训学习靠谱吗?

小谷哥

程序员培训班哪家教的比较好

小谷哥

NodeJS 实战系列:如何设计 try catch

光毅

JavaScript node.js

CBM业务模型是什么和为什么?

涛哥 数字产品和业务架构

企业架构

Verilog HDL门级建模

timerring

FPGA

我们要的一种自学方式,也许是看书自学成才。

叶小鍵

15个 高并发系统设计 锦囊帮助你设计高并发!

风铃架构日知录

Java 程序员 后端 高并发 分库分表

聚焦低碳发电,践行“双碳”之路

脑极体

华为 智能光伏

WEB前端编程培训靠谱吗?

小谷哥

数据可视化图表系列解析——瀑布图

Data 探险实验室

数据分析 数据可视化 图表 可视化数据

架构实战营4.4 如何设计存储架构随堂练习

西山薄凉

「架构实战营」

生产环境10分钟黄金时间快速排障:CPU不定时飙高怎么排查?

KINDLING

Java Linux 后端 监控 ebpf

vivo 超大规模消息中间件实践之路

vivo互联网技术

kafka 中间件 pulsar 消息中间件 RoketMQ

资产梳理与应用自动化部署技术实践

智维数据

大数据 数据可视化 智能运维 应用交付平台 流量分析系统

C++ const与指针

王玉川

c++ 指针 常量 const

一文揭晓,我是如何在Linux中查找自如

蔡农曰

Linux 程序员 运维 后端

设计消息队列存储消息数据的 MySQL 表格

小虎

#架构训练营

软件测试/测试开发 | 接口自动化测试如何进行认证?

测试人

软件测试 自动化测试 接口测试 测试开发

细胞分裂问题的原创解法

王玉川

原创 算法 递归 LeetCode 动态规划

运维训练营第十二课作业

好吃不贵

认识区块链,认知区块链——NFT

MavenTalker

区块链 NFT web3 数字藏品

针对可扩展的、高可用的云架构的模式与反模式_架构_Jonathan Allen_InfoQ精选文章