亚马逊AWS官方博客

Tag: 计算

在AWS云上快速搭建高性能计算(HPC)集群

1. 高性能计算的应用场景 科学家、工程师及科研者等经常需要使用大规模高性能计算集群(HPC)来解决计算密集或存储密集型计算的问题,常见的使用高性能计算的场景包括基因处理、金融建模与仿真、计算化学、物理建模与仿真、政府及科研项目等。在这些HPC应用中,通常需要使用HPC集群来帮助我们快速完成计算,从而减少研发成本和时间。比如基因公司为了完成遗传病组学研究,通常一次需要研究上万份基因的样本,分析上百T的数据,如果用自己机房的服务器来完成计算分析,需要数年的时间,如果使用HPC集群,提交基因分析任务,我们能使用集群的分布式资源管理器来调度并最大化的利用机器资源,在数天内完成分析任务,大大的节省计算的时间。常见的高性能计算的场景还包括:视频转码与编码、流体力学、天气预测、材料仿真、汽车碰撞仿真、风险建模、分子建模、上下文搜索、物流建模、地震勘探数据处理、基因数据计算、天体物理、深度学习、动画建模、微电子验证、图像处理、地理信息系统等。 2. 什么是高性能计算 通常所说的高性能计算使用的硬件一般分为两种情况: 高性能计算机 高性能计算机通常指使用了很多处理器(作为单个机器一部分)的机器。 比如说国内的高性能计算机“天河”、“曙光”、“神威-太湖之光”等,如“神威-太湖之光”由40个运算机柜和8个网络机柜组成,一台机柜装有1024块处理器,计算速度12亿亿次浮点运算次数。 高性能计算机集群 使用某一集群中的多台计算机(作为单个计算资源操作)的计算系统和环境。 这是通过将多台计算机,通过软件的方式组成集群,由集群的分布式资源管理器来负责集群中服务器资源的监控、调度等,我们可以将集群看做单个计算资源,然后将任务提交到集群,分布式资源管理器负责将任务调度到具体服务器执行。 比如在2013年的超级计算机500强的竞赛中,AWS使用多个C3实例组建了高性能计算机集群,使用了26496个核,计算峰值速度达593.5万亿次浮点运算次数,当年排名世界第64位。 当我们需要高性能计算的时候,通常由于机房的资源比较固定,很难有很多服务器给我们来组建集群,而借用高性能计算机如“曙光“,”神威“的成本非常高,也不太现实。这时在云上搭建高性能计算集群就非常方便,因为云上有无限量的计算及存储的资源,资源更弹性,计算过程中可以根据业务压力,调整集群服务器数量;在完成计算后,我们可以释放所有计算资源,大大降低了计算成本。 3. 如何使用AWS云搭建HPC集群 通过 AWS,您能在数分钟内完成高性能计算集群的创建,并将并行 HPC 任务的数量增加到大多数本地 HPC 环境都无法支持的规模,从而提高研究速度并缩短获得成效的时间。AWS 可按需提供针对特定应用程序进行优化的 CPU、GPU 和 FPGA 服务器,有众多的服务器类型选择,无需巨额资金投入,从而帮助降低成本。您有权限访问面向紧密耦合、IO 密集型和存储密集型工作负载的完全等分的高带宽网络,这使您能够在数千个核心之间横向扩展,从而更快获得成效。 4. 集群管理软件CFNCluster 您的HPC集群可能拥有成百上千台机器,手工搭建HPC集群意味着你需要创建所有服务器,配置所有软件,这个过程太复杂。为了简化这个操作,AWS提供了CFNCluster集群管理软件,它是由AWS开发和维护的高性能计算集群的框架,能帮助你在数分钟内完成集群的创建和生产部署,CFNCluster创建的集群支持SGE,OpenLava,Torque等高性能计算框架。下图是CFNCluster和HPC集群的关系图: 通过上图可知,通常我们需要在一台服务器上安装CFNCluster软件,然后通过CFNCluster创建和管理多个HPC的集群,HPC集群中的服务器安装了SGE, OpenLava等分布式资源管理器,你可以根据需要配置分布式资源管理器的类型 ,你也可以使用Cloudwatch监控服务,根据业务压力动态调整(AutoScaling)HPC集群计算节点的数量。当HPC集群创建完成后,你可以像以往使用HPC集群一样通过Master节点访问你的HPC集群。下面示例详细介绍了安装CFNCluster和创建HPC集群的详细过程: (1) 在AWS云中创建一台EC2服务器(使用Amazon Linux的AMI),并运行sudo pip install cfncluster安装CFNCluster,示例如下: sudo pip install cfncluster You are using pip version 6.1.1, however version 9.0.1 is available. […]

Read More

新增 – GPU 支持的 Amazon AppStream 2.0 流式处理实例

我们在 re:Invent 2016 发布了 Amazon AppStream 2.0。利用此应用程序流式处理服务可将 Windows 应用程序交付到桌面浏览器。 AppStream 2.0 是完全托管的,并通过运行一般用途的应用程序提供一致的可扩展性能,提供经过优化的计算、内存优化的流式处理实例,并通过 NICE DCV (安全的高保真流式传输协议) 交付。我们的企业和公共部门客户已经开始使用 AppStream 2.0,代替安装在内部的旧应用程序流式处理环境。他们使用 AppStream 2.0 将商业和业务线应用程序交付到桌面浏览器。我们的 ISV 客户使用 AppStream 2.0 将其应用程序原样迁移到云中,不对其代码做任何更改。这些客户专注于演示、研讨会和商业 SaaS 订阅。 我们收到有关 AppStream 2.0 的良好反馈,并且在非常快速地 (即使按照 AWS 标准来看也是很快的) 增加新的功能。到目前为止,今年我们增加了映像生成器、基于 SAML 2.0 的联合访问、CloudWatch 监控、队列 Auto Scaling、简单网络设置、用户文件永久存储 (Amazon S3 提供支持)、VPC 安全组支持以及内置的用户管理,包括用户 Web 门户。 全新 GPU 驱动流式处理实例 很多客户告诉我们,他们需要使用 AppStream 2.0 向其用户交付专业的设计、工程、HPC […]

Read More

使用AWS CodeDeploy和Auto Scaling组实现蓝绿部署

原文: https://aws.amazon.com/blogs/devops/performing-bluegreen-deployments-with-aws-codedeploy-and-auto-scaling-groups/ 作者:Jeff Levine,Amazon Web Services解决方案架构师 AWS提供的服务能够帮助大家利用云的力量来满足开发和部署的需求。AWS CodeDeploy可自动将代码部署到Amazon EC2或本地实例,并支持蓝绿部署方式。在这篇博文中,将讨论蓝绿部署的好处,并展示如何实现。 蓝绿部署的好处 蓝绿部署涉及两个生产环境: 蓝色环境指代正在使用的生产环境。 绿色环境则将发布一个新版本。 以下是蓝绿部署的一些优点: 可在绿色环境下进行测试,而不会中断蓝色环境。 切换到绿色环境不需要停机,只需要重定向用户流量。 问题发生时,可很方便地从绿色环境回滚到蓝色环境,只要将流量重定向回蓝色环境即可,而无需重新构建。 需要变更时,利用不可变基础设施原则初始化新的实例,避免实例配置产生不一致性。 AWS CodeDeploy提供了两种蓝绿部署的方式: 第一种,AWS CodeDeploy为Auto Scaling组创建了副本,启用新的Amazon EC2实例,将应用程序部署到这些新实例,然后重定向用户流量重定到新部署的代码。 第二种,可使用实例标签或Auto Scaling组来选择用于绿色环境的实例。AWS CodeDeploy会将代码部署到标记的实例上。 那么,如何设置你的第一个蓝色环境?最佳做法,当然是采用AWS CodeDeploy的in-place部署方式。当然也可以从已有的空白Auto Scaling组开始。 蓝绿部署的示例 我们来看一下如何使用Auto Scaling组来实现蓝绿部署。 概述 下图中,示例环境包括一组Amazon EC2实例,可作为AWS CodeDeploy的工作站。服务发布管理员或开发人员可以使用此工作站部署新版本的代码。蓝色环境包含一个Auto Scaling组,其中另有两个实例用作Web服务器。 Web服务器,最初将包含应用程序的第一个版本和AWS CodeDeploy客户端。负载均衡器以轮转的方式,将流量引导到两个Web服务器。 服务发布管理员使用工作站实例,将新版本的应用程序推送到AWS CodeDeploy,并启动蓝绿部署。 AWS CodeDeploy会创建Auto Scaling组的副本,启动两个新的Web服务器实例,并安装新版本的应用程序,然后将负载均衡器重定向到新实例。 原实例仍然是原Auto Scaling组的一部分。 如果需要,均可重新关联到负载均衡器中。 构建该示例的先决条件 以下是需要的准备工作。 具有使用Amazon EC2,Amazon S3,Amazon VPC,AWS CodeDeploy和AWS CloudFormation权限的IAM用户。 选定构建示例环境的AWS区域和可用区域。 Amazon EC2密钥对。 […]

Read More

全新推出 – Auto Scaling for Amazon DynamoDB

Amazon DynamoDB 拥有十万多的客户,客户身处各种行业,使用案例也各不相同。这些客户依赖于 DynamoDB 在任何规模下都能提供的一致性能和覆盖全球 16 个地理区域的服务网络。最近我们注意到一个趋势,客户正在使用 DynamoDB 来为他们的无服务器应用程序提供支持。这是一个很好的搭配:使用 DynamoDB,您无需考虑配置服务器、执行操作系统和数据库软件修补或跨可用区配置复制以确保高可用性之类的事情 – 您只需创建一些表,然后开始添加数据,其他的交给 DynamoDB 处理。 DynamoDB 提供预置容量模式,可以让您设定您的应用程序所需的读取和写入容量。尽管这让您无需考虑服务器,在 AWS管理控制台中进行简单的 API 调用或按钮单击就可以对表的配置进行更改,但客户已经在询问我们,有没有方法让管理 DynamoDB 容量变得更加轻松。 现在,我们推出了 Auto Scaling for DynamoDB,可帮助您实现表和全局二级索引容量管理的自动化。您只要指定所需的目标使用率,并提供读取和写入容量的上限和下限。之后,DynamoDB 将利用 Amazon Cloudwatch 警报来监控吞吐量占用情况,并根据需要上调或下调预置容量。Auto Scaling 对于所有新表和索引默认启用,您还可以对现有表和索引配置此功能。即使您不在左右,DynamoDB Auto Scaling 也将监控您的表和索引,并根据应用程序流量的变化自动调整吞吐量。这使您可以更加轻松地管理 DynamoDB 数据,帮助您最大程度地提高应用程序的可用性,并帮助您降低 DynamoDB 成本。我们来看看它是如何工作的…… 使用 Auto Scaling 现在当您创建新表时,DynamoDB 控制台会提出一组适宜的默认参数。您可以原样接受它们,也可以取消选中“Use default settings”,然后输入您自己的参数: 以下是您输入自己的参数的方式: 目标使用率以占用容量与预置容量的比值来表示。以上参数将允许提供足够的空间,使占用容量能够在读取或写入请求突增时倍增 (请参阅容量单位计算,了解更多有关 DynamoDB 读取和写入操作与预置容量之间关系的信息)。预置容量的变化是在后台发生的。 Auto Scaling 的实际操作 为了了解这项重要的新功能的实际操作,我按照入门指南中的指示进行了操作。我启动了一个全新的 […]

Read More

利用Kong及AWS Lambda构建无服务器的后端逻辑

Kong是一个开源的API GW及微服务管理层,基于Nginx, Cassandra或者PostgreSQL构建,最初由Mashape开发,用于为其API Marketplace管理超过15,000个API和微服务,并于2015年开源。Kong具有如下优点: 可扩展性:通过简单地添加更多的机器,Kong可以轻松地水平缩放,这意味着您的平台可以处理几乎任何负载,同时保持低延迟。 模块化:可以通过添加新的插件来扩展,并通过RESTful Admin API轻松配置所有插件。 平台无关性:Kong可以运行在任何地方,包括本地数据中心及公有云,支持物理机,虚机及容器部署。 目前Kong的最新版本为0.10.2,支持的插件如下: 认证:Basic Authentication, Key Authentication, OAuth2.0 Authentication, OAuth 2.0 Introspection, HMAC Authentication, JWT, LDAP Authentication 安全:ACL, CORS, Dynamic SSL, IP Restriction, Bot Detection 流控:Rate Limiting, Response Rate Limiting, Request Size Limiting 无服务器架构:AWS Lambda, OpenWhisk 分析监控:Galileo, Datadog, Runscope 内容转换:Request Transformer, Response Transformer, Correlation ID 日志:TCP/UDP/HTTP Logging, File […]

Read More

Lambda@Edge – 在边缘智能地处理 HTTP 请求

去年年底,我宣布推出预览版 Lambda@Edge,并谈论了如何使用它在靠近客户的位置 (低延迟) 智能地处理 HTTP 请求。申请并获得预览版访问权的开发人员一直在很好地使用它,并为我们提供了大量非常有用的反馈意见。在预览期间,我们添加了生成 HTTP 响应和支持 CloudWatch Logs 的功能,并根据反馈意见更新了路线图。 现已正式发布 今天我很高兴地宣布 Lambda@Edge 现已正式发布!您可以使用它来: 检查 Cookie 并重写 URL 以执行 A/B 测试。 根据 User-Agent 标头将特定对象发送给用户。 通过在将请求传递到源之前查找特定标头来实现访问控制。 添加、删除或修改标头以将用户指引到不同的缓存对象。 生成新的 HTTP 响应。 干净利落地支持旧 URL。 修改或缩减标头或 URL 以提高缓存利用率。 向其他 Internet 资源发出 HTTP 请求,并使用结果自定义响应。 Lambda@Edge 允许您创建基于 Web 的丰富且个性化的用户体验。由于它正迅速成为当今世界的常态,因此您不需要配置或管理任何服务器。您可以直接上传代码 (在Node.js 中编写的 Lambda 函数),并选择您为分发版创建的其中一个 CloudFront 行为以及所需的 CloudFront 事件: 在本例中,我的函数 (假设名为 EdgeFunc1) […]

Read More

新增 – EC2 Auto Scaling 的目标跟踪策略

最近我介绍过 DynamoDB Auto Scaling,并演示了它如何使用多个 CloudWatch 警报来实现 DynamoDB 表的自动容量管理。此功能在后台使用了一种更为通用的 Application Auto Scaling 模型,我们计划以后逐渐在多项不同 AWS 服务中投入使用该模型。 这一新的 Auto Scaling 模型包括一项重要的新功能,我们称之为目标跟踪。在创建使用目标跟踪的 Auto Scaling 策略时,需要为特定 CloudWatch 指标选择一个目标值。然后,Auto Scaling 旋转相应的旋钮 (打个比方) 推动指标趋向于目标,同时调整相关的 CloudWatch 警报。比起使用初始步进扩展策略类型来手动设置范围和阈值而言,采用对应用程序有意义的任何指标驱动的单元来指定期望的目标,通常来说要更简单,也更为直接。不过,您可以结合使用目标跟踪和步进扩展来实现高级扩展策略。例如,您可以使用目标跟踪实现扩展操作,使用步进扩展实现缩减操作。 现在面向 EC2 现在我们为 EC2 Auto Scaling 增加了目标跟踪支持。您现在可以创建应用程序负载均衡器请求计数、CPU 负载、网络流量或自定义指标 (Request Count per Target 是新指标,也是在今天发布) 驱动的扩展策略: 这些指标都具有同一个重要的特性:添加额外的 EC2 实例会推动指标下降 (但不会改变总体负载),反之亦然。 要创建使用目标跟踪的 Auto Scaling 组,只需输入策略名称、选择一个指标,然后设置所需的目标值: 您可以选择禁用策略的缩减功能。如果禁用,您可以手动缩减,也可以使用独立的策略。您可以使用 AWS Management Console, […]

Read More

新增 – CloudWatch Events 的跨账户传送功能

CloudWatch Events 让您能够跟踪和响应 AWS 资源中的更改。您可以获得几乎实时的事件流,并使用规则将其路由到一个或多个目标 (AWS Lambda 函数、Amazon Kinesis 流、Amazon SNS 主题等)。生成的事件取决于特定的 AWS 服务。例如,以下是为 EC2 实例生成的事件: 或者,对于 S3 (必须启用 CloudTrail 才能创建使用这些事件的规则): 请参见 CloudWatch 事件类型列表,以查看有哪些服务和事件可用。 新的跨账户事件传送客户要求我们扩展 CloudWatch Events,以处理跨多个 AWS 账户的一些有趣且强大的使用案例,我们也很乐意满足这些要求。今天,我们将添加对 CloudWatch Events 的受控、跨账户传送的支持。如您所见,现在您可以安排将事件从一个 AWS 账户路由到另一个账户。与现有的事件传送模式一样,您可以使用 CloudWatch Events 规则来指定要将哪些事件发送到另一个账户。 以下是客户与我们分享的一些使用案例: 隔离问题 – 客户希望在单独的账户中处理和响应事件,以实施高级安全方案。 汇总 – 客户正在使用 AWS Organizations,并希望在整个组织范围内跨多个 AWS 账户跟踪某些类型的事件。 每个 AWS 账户都使用资源事件总线来分发事件。该对象可追溯到 CloudWatch Events 的引入,但从未这样被正式地称呼过。AWS 服务、PutEvents […]

Read More

白皮书:Amazon EC2 Container Service(ECS)上的微服务架构(下篇)

ECS上构建微服务架构 在构建微服务架构时面临的一个主要问题就是,如果减轻运行、维护、扩展和管理微服务架构所需大规模分布式集群资源的工作量和复杂性。目前主流的解决此问题的方案之一就是通过容器化部署和运行服务,降低运维和部署的复杂性。Amazon EC2 Container Service(ECS)是AWS提供的一个容器管理服务,能够应对和解决微服务架构的部署和运维中面临的种种挑战。 本章节首先介绍Amazon ECS及其架构和工作原理,然后介绍利用Amazon ECS及其他相关AWS服务分层构建的一个高可用、高可扩展性、容错的微服务,并讨论该方案中涉及的分布式系统监控、服务发现、异步通信等问题。 Amazon ECS 简介 什么是Amazon ECS Amazon ECS是一个高度可扩展伸缩、高性能容器管理服务,支持Docker容器[vi]并能够让你轻构地在EC2实例构建的集群中运行应用程序。 Amazon ECS能够让你轻松地进行安装、操作和扩展你的集群资源。使用简单的API调用,你就可以启动和停止基于Docker的应用程序、查询你的集群状态、还可以使用其他熟悉的服务,诸如安全组、ELB、EBS卷和AWS IAM角色。 Amazon ECS的特点 与Docker完美兼容:支持 Docker 并使您能够在 Amazon EC2 实例的集群间运行和管理 Docker 容器。Amazon ECS 所管理的集群中的每个 EC2 实例都运行有 Docker 守护程序,所以无论您将何应用程序打包为本地容器,它都将部署和运行在 Amazon ECS 上,无需进行任何配置更改。 内置集群托管:管理自己的容器管理基础设施通常涉及安装、操作、扩展自己的集群管理软件、配置管理系统和监控解决方案。这些系统的可用性和可扩展性架构和管理很难。Amazon ECS 消除了容器管理工作的复杂性。使用 Amazon ECS,您只需要启动容器实例集群并指定想要运行的任务即可,所有集群管理工作将由 Amazon ECS 完成。 编程控制:Amazon ECS 为您提供一组简单的 API,方便您集成和扩展服务。使用 API,您可以创建和删除集群、注册和取消注册任务、启动和终止 Docker 容器,并能提供集群及其实例的状态相关详细信息。您还可以使用 AWS CloudFormation[vii] 预置 […]

Read More

白皮书:Amazon EC2 Container Service(ECS) 上的微服务架构(上篇)

简介 微服务是一种软件开发的组织和架构方法,它可以加快软件交付周期、增强创新和自主性,提高软件的可维护性和可伸缩、可扩展性,同时也提高了企业开发和发布软件服务的能力。使用微服务架构,软件产品将由多个独立的、可通过API进行交互的服务组成。这些服务将由各个小团队独自负责。 通过本白皮书,我们将首先总结一下微服务架构的特性,讨论构建微服务架构面临的挑战和难题,然后介绍AWS的ECS容器集群服务,以及如何利用ECS结合其他AWS提供的服务解决微服务架构中遇到的难题。 什么是微服务架构 微服务架构的特性 近些年,微服务架构的概念变得越来越火[i],事实上微服务并非某项具体的技术或框架,它也不是软件工程学中新的概念,而是一些成功的,经过实践论证的概念的组合,比如面向对象方法论、敏捷开发、面向服务架构、API-first设计、以及持续集成。 “微服务”这个名词是一个概括性的术语,很难对其进行精确的定义。但是所有微服务架构方法都具有以下共同特性: 去中心化:微服务架构是由去中心化数据管理的分布式系统组成。它不依赖中心数据库上统一的数据库模式。每一个服务都有自己独立的数据模型。去中心化的另一个含义是,每个服务在开发、部署、管理和维护过程中也是相互独立的,不依赖某个中心系统。 独立:微服务架构中各个服务组件都可以独立进行更改、升级和替换,而不会影响其他服务组件的正常功能。同样,负责各个服务组件的团队之间也都是相互独立的,互不干扰的。 专注做好一件事:每个服务组件都是专注于某个问题域的功能集合,一旦某个服务复杂度到达一定程度,则应该考虑将其进行服务切分或对其进行再次微服务架构。 多语种:微服务并不是“一体通用”的方法,它允许各个团队根据自己的喜好选择最适合自己问题域的开发语言、开发工具。因此,微服务无论在操作系统、开发语言、数据存储还是工具,都是兼容的。也就是说,微服务是“多语种”的。 黑盒子:微服务中的服务都是按照“黑盒”设计的,也就是说,它们将内部逻辑对外隐藏进来,各个服务间通过定义良好的API进行通信,避免了暗含的相互依赖。 谁构建,谁运行:通常情况下,在生产环境中,构建了某个服务的团队负责该服务的运行和维护。这条规则也称之为DevOps[ii]。DevOps除了能让各个团队按照自己的安排独立工作外,还可以让开发人员更贴近软件产品的真正使用者,能帮助他们更好地了解用户的需求。微服务对于企业组织架构上的影响也是不容忽视的,正如康威定律所言,系统架构是公司组织架构的反映[iii]。 图1:微服务架构的特征 单体型架构 vs. SOA vs. 微服务架构 技术为业务而生,架构也为业务而出现,无论传统单体型架构、SOA和微服务都是因为业务的发展而出现。出现SOA以及微服务框架与业务的发展、平台的壮大密不可分。 单体型架构 当网站或者应用流量很小时,只需一个应用,将所有功能都部署在一起,以减少部署节点和成本,简化开发流程,适合于个人开发或者小团队开发一些功能单一的小产品使用。这是最传统的架构模式,一般整个系统都是有一个统一的数据中心,各个功能模块显式进行相互依赖(比如直接调用模块公开的方法)。当网站流量随着业务发展不断变大时,这种架构的应用在可扩展性、容错性(一旦某个功能模块被流量击溃,整个系统瘫痪)上存在致命性的缺陷。 SOA 当网站或者应用流量变大,单体型架构无法招架之时,可以采取面向服务架构方式,将应用根据系统维度、功能维度、读写维度或者模块维度进行划分成各个独立的服务组件,服务组件间通过某个约定的方式(比如Web Service或者HTTP REST API)进行通信。当服务越来越多,容量的难以准确评估,小服务导致资源浪费等问题逐渐显现,此时需增加一个调度中心基于访问压力实时管理集群容量,提高集群利用率,这种架构一般仍然存在一个统一的数据中心或者调度中心。整个系统的可维护性、可扩展性相对于单体型架构得到提高,但在服务细粒度、隔度性、去中心化方面仍与微服务有差,另外就是SOA架构常常依赖于总线结构,利用可热插拔的中间件以及消息队列来完成服务与服务之间的解耦,对于总线结构的依赖也使得服务的独立性并没有被完全剥离。 微服务架构 在微服务架构中,每个服务都要去中心化,不存在单点故障问题。每个服务都要实现高可用、高负载,不会因为一个服务不可用而影响整套业务流。每个服务细粒度,专注于自己的问题域,与别的服务采用更好的Restful或者良好定义的API进行通信。服务都要高度通用化,即多种终端都可调用,不分语言和平台服务部署或升级简单,不会消耗大量人力并且部署过程不易出现人为错误,同时还具有快速注册与自动服务发现功能。 微服务的益处 许多AWS客户选择微服务架构来解决传统单体型架构中存在的敏捷性和可扩展性限制的问题。让我们来看看选择微服务架构能够带来哪些方面的益处吧。 敏捷 使用微服务的组织由多个负责运维独立服务的小团队组成。各个团队都是在界限明确的小范围内独立、快速地工作,从而起到减小迭代时间的效果。各个小团队效率的提升将使整个企业组织工作效率进行很大程序地提高。 图2标示由多个小团队组成的企业组织架构与由一个大团队组成的企业组织架构,在发布部署一个应用时的工作效率区别。 图2:部署微服务 创新 小团队可以独立自主地针对自己负责的问题域选择相关的技术、框架和工具,这就是创新的体现。职责与义务,让团队产生对自己的服务的责任感。 DevOps通过将开发与运维人员结合到一个团队中,让他们能更早地、更好地沟通,解决了开发部署过程中没必要的摩擦和矛盾。当应用程序部署时,敏捷的处理流程可以让开发和运维工作不再需要暂停下来,相反,整个软件交付周期,从提交代码到发布版本,整个流程将变成自动化的。测试一个新的想法,或者当新功能出现问题时及时回滚,将变得更加轻松。因为失败成本的降低,团队将更加乐于更改和创新。 质量 使用微服务架构您的应用程序,将一定程度上提高代码质量。这跟面向对象设计中提出的分模块开发有同样的效果:提高代码的可重用性、封装性和可维护性。 伸缩性 细粒度解耦的微服务架构另一个好处就是,它非常适合构建大规模系统。它允许针对不同的服务选择最适合的技术,这也是性能优化的体现。每个服务都可以使用最合适的开发语言和框架来实现,利用最优的数据持久化解决方案,并通过各自独立的服务配置进行调优。 合理解耦的微服务架构,可以独立地进行水平伸缩扩展。这相对于传统架构中使用的垂直伸缩有很大的优势。垂直伸缩指的是当业务量、流量增大时,升级硬件资源,将应用部署到“更大的机器”上,这会导致“机器硬件资源上限”和伸缩时宕机的问题。水平伸缩,通过将更多的服务部署到服务池(多个机器组成的集群)中,可以动态地适配流量,并且不会陷入单个机器资源上限问题。整个水平伸缩的过程将会是自动化的。另外,应用程序的可靠性将得到增加,因为出现问题的服务可以自动地被健康的服务替换掉,而不影响整个应用的运行。 可用性 微服务架构可以轻松实现故障隔离。通过健康检查、缓存、隔离仓、断路器等技术,可以减小当某个组件出现故障时的影响,从而保证应用的高可用性。 微服务架构面临的挑战 尽管拥有前面提到的那么多优点,但是微服务架构和所有其他架构一样,都不是解决所有问题的“银弹”。使用微服务架构也会面临一些挑战和难题。比如: 微服务架构都是分布式的,也就会存在所有“分布式计算误区”中提到的问题[iv]。 从单体型架构迁移至微服务架构,需要您准确地划分好各个服务间的界限,并且从应用层到数据库层松耦合代码依赖。 除此之外,在组织管理方面还存在着一些挑战,比如如何组建一个高效的团队,如何将团队转变成DevOps的生产模式,如何合理化开发团队与运维团队的沟通等。 本白皮书主要关注的是架构和运维方面遇到的挑战,如果想了解更多关于AWS如何运用DevOps的知识,请访问https://aws.amazon.com/devops[v] 架构复杂度 在传统单体型架构中,所有的复杂度和依赖都存在项目的代码库中。而对于微服务架构而言,复杂度变成了各个服务间的交互。 在架构上面临的挑战有处理异步通信、连锁故障、数据一致性问题、服务发现和授权认证等问题。 运维复杂度 […]

Read More