亚马逊AWS官方博客

新增 – 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 函数和其他账户可以向该对象发布事件。

事件总线 (目前每个账户一个,计划将来允许一个账户有更多事件总线) 现在有一个关联的访问策略。该策略指定允许向总线发送事件的一组 AWS 账户。您可以添加一个或多个账户,也可以指定允许任何账户发送事件。

您可以创建基于扇入或扇出模式工作的事件分发拓扑。扇入模式允许您在一个位置处理来自多个账户的事件。扇出模式允许您将不同类型的事件路由到不同的位置和账户。

为了避免形成循环的可能性,从一个账户发送到另一个账户的事件将不会发送到第三个账户。在计划跨账户实施时,应该考虑到这一点。

使用跨账户事件传送为了测试此新功能,我利用了我的工作和个人 AWS 账户。我登录到个人账户并转到 CloudWatch 控制台。然后,我选择 Event Buses,单击 Add Permission,并输入我的工作账户的账户 ID:

我可以在一个位置看到我的所有总线 (目前只允许一个总线) 和权限:

接下来,我登录到我的工作账户,并创建一条规则,以便将事件发送到我的个人账户中的事件总线。在本例中,我的个人账户对我的工作账户中运行的 EC2 实例的状态更改感兴趣:

回到我的个人账户,我创建一条将针对任何 EC2 事件触发的规则,并将其目标设置为配置为发送电子邮件的 SNS 主题:

对我的个人账户中启动的 EC2 实例测试此规则后,我将在我的工作账户中启动一个实例并等待电子邮件消息:

消息中的账户和资源字段来自源 (工作) 账户。

须知事项

此功能在所有提供 CloudWatch Events 的 AWS 区域均可用,您可以立即开始使用它。也可以从 CloudWatch Events APIAWS Command Line Interface(CLI) 访问此功能。从一个账户转发到另一个账户的事件被视为自定义事件。发送账户每发送一百万个事件需支付 1 USD (有关更多信息,请参阅 CloudWatch 定价)。

-Jeff

PS – AWS CloudFormation 支持正在准备阶段,即将推出!

AWS 降价 – 在Amazon EC2 上运行的 SQL Server 标准版

我很高兴地宣布,AWS 迎来了第 62 次降价,本次降价适用于在 EC2 上运行的 Microsoft SQL Server 标准版

许多企业工作负载都在 Microsoft Windows 上运行,主要是在本地部署或企业数据中心。AWS 上提供了各种各样的服务,由我们覆盖全球的基础设施合作伙伴生态系统提供支持,因此,我们认为它是构建、部署、扩展和管理 Windows 应用程序的最佳位置。AdobePitney BowesDeVry University 等客户都已将核心生产 Windows Server 工作负载移到了 AWS。他们的应用程序囊括从 SharePoint 站点到自定义 .NET 应用程序和 SAP 的全部范围,且经常使用 SQL Server。

Microsoft SQL Server on AWS 运行在 EC2 Windows 实例上,并可为您的应用程序开发和迁移提供支持。通过它,您可以控制所有设置,就像在本地部署中运行关系数据库时控制设置一样,它支持 32 位和 64 位版本。

今天,我们将降低在 R4、M4、I3 和 X1 实例上运行的 EC2 上的 Microsoft SQL Server 标准版的按需和预留实例价格,降幅高达 52%,具体取决于实例类型、大小和区域。您可以构建和运行企业级应用程序、可大规模扩展的网站及移动应用程序,成本比以往任何时候都低。

下面是针对每个区域和实例类型的最大降价幅度:

区域 R4 M4 I3 X1
[iad] -51% -29% -50% -52%
[cmh] -51% -29% -50% -52%
[pdx] -51% -29% -50% -52%
[sfo] -51% -30% -50%
[yul] -51% -51% -50% -44%
[gru] -49% -30% -48%
[dub] -51% -29% -50% -51%
[fra] -51% -29% -50% -50%
[lhr] -51% -51% -50% -44%
[sin] -51% -31% -50% -50%
[syd] -51% -30% -50% -50%
[nrt] -51% -29% -50% -50%
[icn] -51% -31% -50% -50%
[bom] -51% -33% -50% -50%

按需实例新的更低价格自 2017 年 7 月 1 日开始生效。预留实例的新定价从今日开始生效。

-Jeff

新增 – 面向 Amazon CloudWatch 控制面板的 API 和 CloudFormation 支持

我们在几年前发布了 CloudWatch 控制面板。在专为这次发布撰写的文章中,我介绍了如何以交互方式创建控制面板,以便以图形形式显示所选的 CloudWatch 指标。发布之后,我们增加了其他功能,包括全屏模式、深色主题、控制 Y 轴的范围、简化的重命名、持久性存储和新的可视化选项

新 API 和 CLI

虽然控制台支持非常有利于交互式使用,但许多客户要求我们提供对控制面板及其中小部件的编程式创建和操作的支持。这些客户想要动态构建和维护控制面板,从而在创建和销毁相应的 AWS 资源时添加和删除小部件。其他客户则希望在两个或多个 AWS 账户中设置和维护一组一致的控制面板。

我非常高兴地宣布,面向 CloudWatch 控制面板的 API、CLI 和 AWS CloudFormation 支持现已推出,您可以立即开始使用!

我们新增了四个 API 函数 (和等效的 CLI 命令):

ListDashboards / aws cloudwatch list-dashboards – 用于提取账户内所有控制面板的列表,或共享通用前缀的子集。

GetDashboard / aws cloudwatch get-dashboard – 用于提取单个控制面板的详细信息。

PutDashboard / aws cloudwatch put-dashboard – 用于创建新控制面板或更新现有控制面板。

DeleteDashboards / aws cloudwatch delete-dashboards – 用于删除一个或多个控制面板。

控制面板概念 我将要向您展示如何使用这些函数和命令。在转入正题之前,我应该介绍几个重要的控制面板概念和属性。

全局 – 控制面板是 AWS 账户的一部分,但未与特定 AWS 区域关联。每个账户最多可以包含 500 个控制面板。

命名 – 每个控制面板都有一个在 AWS 账户内唯一的名称。名称最长可达 255 个字符。

网格模式 – 每个控制面板都由网格单元格组成。网格包括 24 个单元格,高度可根据需要调整。控制面板中的每个小部件可位于一组特定的网格坐标上,大小可跨越一个整数的网格单元格。

小部件 (可视化) – 每个小部件可以显示文本或一组 CloudWatch 指标。文本通过 Markdown 指定;指标可以显示为单个值,或以折线图或堆积面积图的形式显示。每个控制面板最多可以包含 100 个小部件。显示指标的小部件还可以与 CloudWatch 警报相关联。控制面板有 JSON 表示形式,现在您可以在控制台中看到并编辑它。只需单击 Action 菜单并选择 View/edit source 即可:

下面是我的控制面板源:

您可以使用此 JSON 作为您自己的应用程序的起点。如您所见,控制面板中每个小部件的 widgets 数组中都有一个条目;每个条目描述一个小部件,从其类型、位置和大小开始。

使用 API 创建控制面板

假设我要在特定区域为我的每个 EC2 实例创建一个含有小部件的控制面板。我会使用 Python 和适用于 Python 的 AWS 软件开发工具包,然后按如下所示开始创建 (请原谅我的代码不够专业):

import boto3
import json

cw  = boto3.client("cloudwatch")
ec2 = boto3.client("ec2")

x, y          = [0, 0]
width, height = [3, 3]
max_width     = 12
widgets       = []

接着,我直接对实例进行迭代,以便为每个实例创建 widget 词典,并将其附加在 widgets 数组中:

instances = ec2.describe_instances()
for r in instances['Reservations']:
    for i in r['Instances']:

        widget = {'type'      : 'metric',
                  'x'         : x,
                  'y'         : y,
                  'height'    : height,
                  'width'     : width,
                  'properties': {'view'    : 'timeSeries',
                                 'stacked' : False,
                                 'metrics' : [['AWS/EC2', 'NetworkIn', 'InstanceId', i['InstanceId']],
                                              ['.',       'NetworkOut', '.',         '.']
                                             ],
                                 'period'  : 300,
                                 'stat'    : 'Average',
                                 'region'  : 'us-east-1',
                                 'title'   : i['InstanceId']
                                }
                 }

        widgets.append(widget)

我更新循环内的位置 (xy),并形成一个网格 (如果我不指定位置,则小部件会从左向右、从上至下进行排列):

        x += width
        if (x + width > max_width):
            x = 0
            y += height

处理完所有实例后,我创建一个 JSON 版本的小部件数组:

body   = {'widgets' : widgets}
body_j = json.dumps(body)

接下来,我创建或更新我的控制面板:

cw.put_dashboard(DashboardName = "EC2_Networking",
                 DashboardBody = body_j)

运行代码后,会获得以下控制面板:

CloudWatch 团队建议,以编程方式创建的控制面板应包括文本小部件 (用于说明控制面板是自动生成的) 以及指向所使用的源代码或 CloudFormation 模板的链接。这样可防止用户在外部对控制面板进行手动更改。如前所述,每个指标小部件还可以与一个 CloudWatch 警报相关联。您可以通过编程方式或使用 CloudFormation 模板来创建警报,如示例 CPU 使用率警报。如果您决定这样做,则警报阈值会显示在小部件中。要详细了解此操作,请阅读 Tara Walker 近期发布的文章 Amazon CloudWatch 发布了控制面板警报功能。更进一步的操作是,我可以使用 CloudWatch Events 和 Lamba 函数来跟踪某些资源的创建与删除,并在发生更改时更新控制面板。要了解如何执行此类操作,请阅读使用 AWS Lambda 让 CloudWatch 控制面板保持最新

使用 CLI 访问控制面板 我还可以通过命令行访问和操作我的控制面板。例如,我可以生成一个简单的列表:

$ aws cloudwatch list-dashboards --output table
----------------------------------------------
|               ListDashboards               |
+--------------------------------------------+
||             DashboardEntries             ||
|+-----------------+----------------+-------+|
||  DashboardName  | LastModified   | Size  ||
|+-----------------+----------------+-------+|
||  Disk-Metrics   |  1496405221.0  |  316  ||
||  EC2_Networking |  1498090434.0  |  2830 ||
||  Main-Metrics   |  1498085173.0  |  234  ||
|+-----------------+----------------+-------+|

然后,我删除 Disk-Metrics 控制面板:

$ aws cloudwatch delete-dashboards --dashboard-names Disk-Metrics

此外,也可以检索用于定义控制面板的 JSON:

使用 CloudFormation 创建控制面板

控制面板还可以在 CloudFormation 模板中进行指定。下面是一个简单的 YAML 格式的模板 ( DashboardBody 仍以 JSON 指定):

Resources:
  MyDashboard:
    Type: "AWS::CloudWatch::Dashboard"
    Properties:
      DashboardName: SampleDashboard
      DashboardBody: '{"widgets":[{"type":"text","x":0,"y":0,"width":6,"height":6,"properties":{"markdown":"Hi there from CloudFormation"}}]}'

我将模板放置在一个文件中,然后使用控制台或 CLI 创建堆栈:

$ aws cloudformation create-stack --stack-name MyDashboard --template-body file://dash.yaml
{
    "StackId": "arn:aws:cloudformation:us-east-1:xxxxxxxxxxxx:stack/MyDashboard/a2a3fb20-5708-11e7-8ffd-500c21311262"
}

下面是控制面板:

现已推出

此功能现已推出,您可以立即开始使用。您可以免费创建 3 个控制面板,每个控制面板最多包含 50 项指标;如果创建的控制面板超过 3 个,则每月需支付 3 USD (相关价格信息,请访问 CloudWatch 定价页面)。您每月最多可以免费调用 100 万次新 API 函数;如果超出此范围,则每调用 1000 次需支付 0.01 USD。

-Jeff

现已推出 – AWS SDK for Java 2.0 的开发人员预览

AWS 开发人员工具团队一直苦心致力于 AWS SDK for Java 的开发,今天终于推出了 2.0 版开发人员预览版。这个版本是对旧 1.11.x 代码库的重大修改。新 SDK 构建在 Java 8 之上,重点在于一致性、不变性和易用性,包括经常请求的功能,例如支持非阻塞 I/O 以及在运行时选择所需的 HTTP 实现的能力。新的非阻塞 I/O 支持,比现有的服务客户端基于线程的异步变体实现更有效。每个非阻塞请求都返回一个 CompletableFuture 对象。版本 2.0 SDK 包括对早期 API 的许多更改。例如,它使用基于客户端生成器和不可变客户端的一致模型来代替客户端构造函数和可变方法的现有组合。该 SDK 还将用于配置多个区域的离散类集合折叠为单个区域类,并提供一组新的用于流式处理的 API。该 SDK 在 GitHub 上提供。您可以通过打开 GitHub 问题发送公共反馈,也可以按照通常的方式发送提取请求。要了解有关此 SDK 的更多信息,请阅读 AWS 开发人员博客上的AWS SDK for Java 2.0 – 开发人员预览

-Jeff

AWS GovCloud (美国) 和 Amazon Rekognition – 一个功能强大的公共安全工具

已告诉您有关 Amazon Rekognition 的信息,并介绍了它如何使用深度神经网络模型通过检测对象、场景和面部来分析图像。

今天我非常高兴地宣布,Amazon Rekognition 目前已在 AWS GovCloud (美国) 区域可用。要了解更多信息,请阅读 Amazon Rekognition 常见问题Amazon Rekognition 产品详情,查看 Amazon Rekognition 客户案例,然后使用 Amazon Rekognition 开发人员资源 页面上的信息构建您的应用程序。

面向公共安全的 Motorola Solutions

接下来,我将占用一点时间,向您介绍 Motorola Solutions 的研究,探讨如何通过 Amazon Rekognition 强化现场和指挥中心公共安全人员的实时情报。

Motorola Solutions 为 100 多个国家/地区的 100000 多家公共安全和商业客户提供用于移动情报和数字证据管理的软件、服务和工具,其中许多由使用随身、车载和固定式摄像机拍摄的图像提供支持。由于这些图像极其敏感,它们的存储环境必须满足联邦调查局定义的严格的 CJIS (刑事司法信息系统) 安全标准。

近几年来,Motorola Solutions 的研究人员一直在探索人工智能的使用。例如,他们已经使用 Amazon Rekognition、Amazon Lex 和 Amazon Polly 结合自己的软件构建了原型应用程序,用于从随身摄像机的图像中扫描失踪人员并发出提醒,而无需持续的人工关注或交互。仅仅在美国,就有大约 100000 人失踪,执法机构需要携带功能强大的工具。在 re:Invent 2016 上,Dan Law (Motorola Solutions 的首席数据科学家) 介绍了他们如何使用 AWS 在这方面提供帮助。下面是相应视频 (Dan 的专题名为 AI for Public Safety 从27分8秒开始): AWS 和 CJIS Dan 描述的应用程序可以在 AWS GovCloud(US) 中运行。这是一个隔离的云,旨在保护和保存敏感的 IT 数据,同时满足联邦调查局的 CJIS 要求 (和其他许多要求)。AWS GovCloud(US) 位于美国的土地上,完全由美国公民管理。AWS 通常会与客户签署 CJIS 安全协议,并根据需要对我们的员工执行或允许执行背景调查。您可以使用下面这些资源来了解有关 AWS 和 CJIS 的更多信息:

-Jeff

使用基于速率的 AWS WAF 规则保护网站和服务

AWS WAF (Web 应用程序防火墙) 可帮助您的应用程序防御涉及恶意或错误格式请求的很多种应用程序层攻击。我在介绍此服务的第一篇文章 (New – AWS WAF) 中讲过,您可以定义与跨站点脚本、IP 地址、SQL 注入、大小或内容限制匹配的规则:

当传入请求符合规则时,将调用操作。操作可以是允许、阻止或只是对匹配项计数。现有规则模型非常强大,让您能够检测许多不同类型的攻击并予以响应。但是,对于只是包含大量来自某特定 IP 地址的有效请求的攻击,该规则模型无法作出响应。这些请求可能是 Web 层的 DDoS 攻击、暴力登录尝试,甚至是合作伙伴集成出错。

基于速率的新规则

现在我们将在 WAF 中增加基于速率的规则,这样您就能控制何时对黑名单添加或删除 IP 地址,并可以灵活处理异常和特殊情形:

将 IP 地址加入黑名单 – 您可以将发出请求的、速率超出所配置的速率阈值的 IP 地址加入黑名单。

IP 地址跟踪 – 您可以看到哪些 IP 地址当前被加入了黑名单。

删除 IP 地址 – 已加入黑名单的 IP 地址如果不再以高出所配置阈值的速率发出请求,则将自动从黑名单中删除。

IP 地址免审核 – 您可以在基于速率的规则中使用 IP 地址白名单免于将特定 IP 地址加入黑名单。例如,您可能希望允许可信赖的合作伙伴以较高的速率访问您的站点。

监控和报警 – 您可以通过针对每条规则发布的 CloudWatch 指标进行监控和发出警报。您可以结合基于速率的新规则和 WAF 条件实施精细的速率限制策略。例如,您可以使用基于速率的规则和与您的登录页面匹配的 WAF 条件。这样,您可以对登录页面设置较为严格的阈值 (以避免暴力密码攻击),而对于市场推广或系统状态页面设置较为宽松的阈值。阈值按照 5 分钟内来自单个 IP 地址的传入请求数定义。一旦超出此阈值,来自该 IP 地址的额外请求就会被阻止,直至请求速率降至阈值之下。

使用基于速率的规则 下面演示如何定义基于速率的规则来保护您网站的 /login 部分。首先在网页 URI 中定义一个与期望的字符串匹配的 WAF 条件:

然后,使用此条件来定义基于速率的规则 (该速率限制以 5 分钟时间段内的请求数表示,但一旦突破此限制,黑名单机制立即启动):

在定义好条件和规则之后,创建一个 Web ACL (ProtectLoginACL) 将这些都整合起来并与 AWS 资源 (在本例中为 CloudFront 分配) 关联:

然后将规则 (ProtectLogin) 与该 Web ACL 连接:

现在,将根据该规则和 Web ACL 保护该资源。您可以监控相关联的 CloudWatch 指标 (在本例中为 ProtectLoginProtectLoginACL)。您甚至可以创建 CloudWatch 警报,并使用这些警报在突破保护阈值时触发 Lambda 函数。此代码可以检查违反规则的 IP 地址,并作出业务驱动的复杂决策,比如添加一条白名单规则,对可信赖的合作伙伴或具有特殊付款计划的用户提供格外宽松的政策。

现已推出 基于速率的新规则现已提供,您可以立即开始使用!基于速率的规则与常规的规则同样定价;请参阅 WAF 定价页面了解更多信息。

-Jeff

无服务器应用程序:乔治亚州立大学的云计算之旅

近年来,众多高等院校开始越来越多地立足远程教育开展各类创新举措。乔治亚州立大学所推出的虚拟锻炼课程正是解决这一挑战的典型实例之一。该在线课程的目标在于帮助学生们在锻炼过程当中了解如何管理其心率活动,从而获得最理想的运动效果。

最初,学生们需要以手动方式从其健身追踪器当中导出数据,而后将其发送给教师。很明显,这种繁琐的作法远称不上理想。乔治亚州立大学在线学习办公室主任 、首席教学设计师James Castle总结称,“从学生的角度出发,这样的过程可能令人困惑——因为其在进行数据下载时面对着多种报告与文件类型。而任何报告错误或者格式错误都可能导致数据无法正常使用。对于一部分学生来说,数据管理已经成为其学习过程中的巨大障碍。”

为了减轻学生们的负担,James与多位来自计算机科学专业的学生们共同开发出一款替代性解决方案。该团队着目光投向了Amazon Web Services(简称AWS),希望通过一种低成本的方式实现应用程序运行以及无缝化数据收集。如此一来,他们将得以显著简化学生与教练们的数据收集与分析方式。

乔治亚州立大学计算机科学专业大三学生Chuma Atunzu解释称,“为了实现这一目标,我需要查阅大量关于AWS的说明文档。我观看了很多讲解视频,并发现这非常有趣。凭借着这些技术相关经验,我能够利用多项AWS服务构建起一款现代化、无服务器型应用程序。”

在AWS的帮助下,他们设计出的无服务器应用程序分别运用到AWS Lambda、Amazon DynamoDB、Amazon API Gateway、Amazon简单存储服务(简称Amazon S3)、Amazon简单邮件服务(简称Amazon SES)以及Desire2Learn(简称D2L)与Fitbit等。在夏季新学期开始之前,他们进行了为期一个月的应用程序测试,而最终月度计费账单仅为0.01美元。

现在,学生们已经能够在学期初始以一键式操作访问该应用,而后即可享受更为便利的数据管理服务。而教授们则可在获得许可后面向各个模块发出数据请求,并对课程进度及其它情况进行必要分析。

这项在线健身课程如今与Fitbit以及新的无服务器应用程序一同对乔治亚州立大学内身处世界各地的全部学生的心率数据进行监控——无论其身在瑞士、韩国、乞力马扎罗山顶抑或是坦桑尼亚。James解释称:“到目前为止,项目进展似乎一切顺利。我们的学生几乎能够立足世界上的任何地区获取其必要的体征数据信息。”

目前这项课程建立起两类工作负载(而每月成本仅需要1美分!)——其一面向学生,其二则面向教师。

图一:学生工作流

图二:教师工作流

感兴趣的朋友亦可点击此处了解更多与AWS Cloud在高等教育领域的相关应用信息。

 

白皮书: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] 预置 Amazon ECS 集群、注册任务定义和安排容器。
  • 任务调度:Amazon ECS  包含许多任务调度程序和内置的Placement Engine,可以根据您的资源需求(例如 CPU 或 RAM)和可用性要求在集群中放置容器。通过使用可用的任务调度程序,您可以安排长期运行的应用程序和服务以及批量作业。Amazon ECS API 还能提供完整的集群状态信息,允许您编写自己的任务调度程序或集成现有的第三方调度程序(例如 Marathon)。Amazon ECS 是共享状态的乐观并发系统,可以将集群的完整状态呈现给所有的计划程序。通过使用 Amazon ECS API 或 Blox (一个用于容器管理和编排的开源对象集合),您可以开发自己的任务调度程序或集成第三方调度程序。
  • 负载均衡:Amazon ECS 已与 Application Load Balancing (ALB) 集成,支持您在多个容器之间分配流量。您只需指定任务定义和要使用的 ALB,Amazon ECS 服务计划程序将自动添加和删除 ALB 中的容器。您可以在任务定义中指定动态端口,这可为安排在 EC2 实例上的容器提供未使用的端口。您还可以使用基于路径的路由与多个服务共享 ALB。
  • 监控:Amazon ECS 为您的容器和集群提供了监控功能。您可以监控正在运行的任务的 CPU 和内存使用率及总和,这些任务通过 Amazon CloudWatch 按任务定义、服务或集群进行分组。您还可以设置 CloudWatch 警报,在您的容器或集群需要扩大或缩小规模时提醒您。
  • 日志记录:您可以将各个容器实例的 ECS 代理日志和 Docker 容器日志发送到 Amazon CloudWatch 日志,以简化问题诊断。借助 AWS CloudTrail,您还可以记录所有的 Amazon ECS API 调用并将日志文件发送给您。记录的信息包括 API 调用者的身份、API 调用的时间、API 调用者的源 IP 地址、请求参数以及 Amazon ECS 返回的响应元素。
  • 安全性:Amazon ECS支持您为每项 ECS 任务指定一个 IAM 角色。如此一来,ECS 容器实例将获得遵循“最低权限”访问策略的最小角色,允许您分别管理实例角色和任务角色。您还可以查看哪项任务使用哪个角色,这些信息均记录在 CloudTrail 日志中。
Amazon ECS的架构及工作原理
 
ECS的架构

ECS由以下主要组件构成:

  • Task Scheduler:任务调度器负责将task和service以task definition文件描述的形式按照一定的调度策略,放置到相应的Container Instance上进行运行。
  • Resource Manager:Resource Manager负责对宿主机进行通信,申请、释放并管理任务运行时所需资源。
  • ECS Cluster:ECS集群是一组EC2实例的集合,由运行Docker容器的Container Instance(容器实例)组成,构成了ECS运行的整体资源。当运行任务时,ECS会根据task definition的信息从ECR或者任何其他Docker镜像仓库中拉取对应的镜像文件,并在集群中运行。
  • Container Agent:Container Agent负责Container Instance与集群的心跳通信,负责访问Container Instance、健康检查、发送命令等等。默认Container Agent是内置在 Amazon ECS-optimized AMI中的,当您创建Container Instance就已经自动安装了Container Agent。
  • Container Instance:Container Instance就是安装了Container Agent并在ECS集群上进行了注册的EC2实例。当您运行ECS任务时,ECS会根据任务调度策略将任务放置到特定的Container Instance上运行。

图3:ECS的架构
跨AZ保证高可用性

Amazon ECS通过跨可用区(AZ)运行应用程序容器来保证高可用性。您需要在VPC中创建您的ECS集群,通过task definition(任务说明)和task service(服务说明)定义好Docker容器镜像文件,并其运行在您的ECS集群上。此外,您还可以通过Amazon ECR,Docker Hub或任何私有镜像仓库来存储和管理您的Docker容器镜像文件。

图4:跨分区运行ECS集群
灵活的任务调度

Amazon ECS将运行在容器中的作业分为两种类型:task(任务)和service(服务)。

一个task通常指的是一次性的作业,比如定时触发器、批量数据处理等,task 需要由一个task definition文件定义其所需的资源和处理过程,并将它运行在您的集群上。您可以指定运行在您的ECS集群上的task个数。

一个service服务指的是永久运行在后台的作业,您同样需要在task definition文件中对其进行定义。Amazon ECS允许您定义一定数量(由desired count参数指定)的任务进程来支持一个service,当某个任务进程失败或者不健康,ECS会自动启动新的任务进程,以保证该服务的任务数量达到desired count。

那么如何将这些任务放到特定的容器实例上呢?Amazon ECS提供的Task Placement Engine支持多种容器任务调度策略:

  • Binpacking:最少资源利用(根据CPU或者内存)的实例会优先被放置,这种策略会先将任务放到可用资源最少的实例上,减少了启动过多的实例,提高了资源利用率。
  • Spread:根据某个特定值进行平衡放置,这个特定值可以是一个键值对,也可以是instanceId或者host。一般可使用这种策略实现跨AZ的任务放置。
  • Affinity:组合条件的放置策略,比如两个符合条件的task不能同时放到某个实例中,或者两个符合条件的task必须同时放到某个实例中。
  • Distinct Instance:将每项任务放置在不同的容器实例中。

图5:任务调度策略

此外,您可以任意组合多种调度策略,或者通过BLOX项目自定义您的任务调度策略。关于BLOX,详见https://blox.github.io/

分层构建微服务方案

本节我们通过分布式应用中经典的CDN层、API层、应用层以及数据持久层分层介绍使用AWS ECS及其他AWS服务构建一个高性能、高可用的微服务。

图6:分层构建微服务
CDN层

CDN层的意义在于加速静态和动态资源的传输,并潜在地减轻后端服务器的压力。

使用CDN,可以让您的微服务应用客户端从最近的端点或者代理服务器、缓存服务器上获取资源,或者可以让您通往原数据服务器的链路得到优化,从而降低延时, 加快您网站及应用上的图片、视频、脚本等数据的传输。

API层

API层是所有请求的入口,它可以隐藏应用程序的业务逻辑细节,通过诸如HTTP REST API接受外部请求。API层一般还需要对所接收的请求进行流量管理、请求过滤、缓存及访问授权和控制。您可以使用Application Load Balancer(ALB)来实现您的API层。ALB是 Amazon Elastic Load Balancing(ELB) 服务的一个负载均衡选项,支持您在运行于一个或多个 EC2实例上的多个服务或容器之间基于内容定义路由规则。它可以做到:

  • 基于主机的路由:您可以基于 HTTP 标头的“主机”字段路由客户端请求,以便您从同一个负载均衡器路由到多个域。
  • 基于路径的路由:您可以基于 HTTP 标头的 URL 路径路由客户端请求。

ALB提供了对容器化应用程序的支持,您可以对应用程序负载均衡器进行配置,以在单个 EC2 实例的多个端口之间对容器进行负载均衡。借助 Amazon EC2 Container Service (ECS),您可以在 ECS 任务定义中指定一个动态端口,以便在将容器安排到 EC2 实例上时为其提供一个未使用的端口。ECS 计划程序会自动使用该端口将任务添加到 ALB Target Group。

如下图所示:您可以将ALB作为API层的入口,接收外部API调用请求,可以对请求进行过滤和访问控制,并根据一定的分发策略将请求分发给其代理的ECS集群,从而起来负载均衡的作用。关于更多ALB的介绍,请参考:http://docs.amazonaws.cn/elasticloadbalancing/latest/application/introduction.html

图7:使用ALB实现API层作为服务调用入口
应用层

应用层实现了具体的应用程序业务逻辑。AWS提供了多种方式来运行应用程序,您可以将程序直接部署到EC2上、或者使用Elastic Beanstalk服务快速构建运行环境,或者使用无服务器服务AWS Lambda、当然也可以使用容器管理服务ECS。这里介绍ECS利用容器技术运行应用层的好处。

  • 一致性:容器镜像文件具有一致性,无论您将同一个容器镜像部署到开发者的笔记本还是测试环境,抑或是生产环境,容器都会保持一致的工作。
  • 灵活性:容器技术将应用程序划分为各个独立的、松耦合的服务,这一点跟微服务架构思想是完美融合的。容器可以使微服务架构的灵活性得到更好的表现。
  • 高资源利用率:容器允许您预先定义需要使用的资源数据(比如CPU和内存),可以在多个下层宿主机构成的集群上共享资源,达到比虚拟机技术更好的资源利用率。
  • 高工作效率:容器具有一致性、版本公开性、松耦合和可轻松回滚等特性的可以重复使用的工作集。您不需要重复“造轮子”,无论从开发和运维上都可以提高您的工作效率。
数据持久层

数据持久层负责将业务中使用到的数据进行存储和管理。将数据管理和持久化单独封装一层,可以让应用层实现无状态化,从而便于应用层进行水平伸缩扩展和实现容错机制。

静态数据一般可以存储在AWS Simple Storage Service(S3)服务上,并通过AWS CloudFront进行分发。关于S3,可以参考 https://www.amazonaws.cn/s3/

会话数据和常用的数据,可以存储在数据缓存中间件中,比如Memcached或者Redis。AWS提供了ElasticCache服务管理这两种缓存服务。关于ElasticCache,可以参考 https://www.amazonaws.cn/elasticache/

对一致性要求较高的业务数据可以存储在关系型数据库中,AWS Relational Database Service(RDS)服务可以管理六大常见关系型数据库引擎(Microsoft SQL Serve,Oracle,MySQL,MariaDB,PostgreSQL, Amazon Aurora)。关于RDS,可以参考 https://www.amazonaws.cn/rds/

关系型数据库不利于伸缩和业务扩展,利用NoSQL数据库得到了更好的可扩展性、可用性和性能。您可以使用Amazon DynamoDB创建可以存储任意数据、应对大量访问的数据库表。DynamoDB可以将表中数据分布到足够多的服务器上,以满足高性能、大数据量、大访问量的存储要求。关于DynamoDB,可以参考https://www.amazonaws.cn/dynamodb/

解决微服务架构中的常见问题

在讨论如何分层构建微服务后,通过ECS和AWS相关服务,我们已经很大程序上减轻了架构和运维微服务应用所需的工作量。本节我们将讨微服务架构中另外几个常见的问题,并结合AWS提供的相关服务对这些问题进行分析和处理。

服务发现

如何让服务发现彼此并进行交互,这是微服务架构必须解决的问题。服务发现包括检查服务的健康状态以及自动发现新服务上线。在AWS中提供了几种方式来实现服务发现:

1. 基于 Application Load Balancer实现的服务发现

ALB具有健康检查和服务上线注册下线注销的功能,将这些功能与DNS解析服务相结合,可以低成本地轻松解决服务发现问题。

您可以给每个微服务设置自定义的域名,然后通过一个CNAME入口,将这些服务绑定到某个Elastic Load Balancer的DNS下。这些服务的DNS名将会被发布给所有需要访问服务的应用程序, 同时结合ALB基于路径路由的功能,能够利用Target Group和Path的结合分发给不同的微服务,节省资源和成本。

图8:基于Elastic Load Balancer的服务发现

2. 基于Key-Value对存储的服务发现

您还可以使用Key-Value键值对存储的形式来实现服务发现,虽然这种方式实现起来需要您花费比其他方式更多的时间,但是它能提供更好的灵活性和扩展性,并且不用担心DNS缓存问题。这种方式天生与客户端负载均衡技术相吻合,客户端负载均衡可以解决性能瓶颈并简化流量管理。

图9展示的是一个利用Amazon DynamoDB作为Key-Value键值存储,并结合DynamoDB Stream以生产者消费者模式来实现服务状态更改通知的架构。


图9:基于Key-Value对存储的服务发现

3. 基于第三方开源组件的服务发现

您还可以使用开源社区中的服务发现组件来构建服务发现,例如Hadoop的子项目ZooKeeper或者Hashicorp公司的Consul[vii], 这种方式的好处在于合理利用了已有的开源社区中的优秀框架来提供基于Key-Value的特定服务,并且这些开源社区的组件对AWS的集成也非常对友好,能够非常快速的搭建服务发现的方案。下图10展示了Consul与ECS的协同工作, 宿主机将会首先利用Registrator[ix]的Agent在Docker启动时将Consul Agent注册到Consul Server,由于Consul基于消息订阅的模型设计,所以其他服务很快收到订阅知道新的组件上线并且能够通过其API了解到其他服务的状态.


图10:基于Consul服务发现

 

数据一致性

单体型架构的应用一般都是将数据存储在一个数据库中,应用程序中所有模块统一使用一致的数据模型。微服务则不能使用这些中心数据库,因为这与微服务去中心化、要求独立型的原则不符。每一个微服务组件都可以拥有自己的一套数据持久化方案。那么如何在服务通信过程中,保持数据的一致性呢?

通常情况下,微服务中状态的变化将会影响整个系统数据的一致性。在这种情况下,事件驱动模型被实践证明可以用于实现数据的最终一致性。事件驱动模型的核心就是将应用程序每一次状态变化当作一个事件记录下来,与持久化数据状态不同,数据是通过一连串事件流存储起来的。数据库事务日志和版本控制就是应用事件驱动模型最出名的两个例子。

在微服务场景中,事件驱动模型以“订阅者-消费者”形式进行应用程序各服务间的解耦,在各个应用不同数据系统的微服务组件之间共享事件流数据,事件驱动模型还可用于读写分离场景,提升读和写的性能。

下图展示如何利用AWS Kinesis Stream作为中心事件流,捕获各个服务的数据变化作为事件,并将事件流记录在S3上。图中各个微服务组件由ALB、ECS和RDS组成,如图所示,微服务组件Microservice 1由于某个状态改变,向Kinesis发布事件,Kinesis将事件持久化到S3中(客户可以使用Redshift服务对这些事件流进行分析),其他微服务组件如Microservice 2和3订阅了这个事件,会拉取并过滤事件,并在本服务组件中进行相应的处理。通过这种机制,可以实现不同数据系统间数据的最终一致。

图11:Kinesis实现事件驱动
异步通信

在单体型架构的应用中,各个模块间的通信是非常简单的,可以是简单的方法调用或者通过内部事件发布机制。而当使用微服务架构时,服务间的通信必须通过网络远程调用。

常用的微服务通信机器除了HTTP REST API进行API调用外,对于一些对实时性要求不高,又耗时较长的通信场景,经常需要使用到消息队列实现异步通信。Amazon Simple Queue Service(SQS)和Amazon Simple Notification Service(SNS)都是AWS提供的用于异步通信、通知推送的服务。

服务监控与日志记录

在微服务架构中,您需要对各个服务进行监控,以判断服务是否健康,是否可用。您还需要对服务的API调用记录、访问记录等日志进行记录,以实现问题发现和追踪。

您可以使用Amazon CloudWatch来收集系统指标,集中管理和监控日志文件,设置预警并自动适应您的运行环境中发生的变化。Amazon CloudWatch可以监控的AWS资源包括EC2实例、DynamoDB表和RDS DB实例,也可以监控任何您的应用和服务生成的自定义指标和日志文件。

1. 监控

利用Amazon CloudWatch,您可以轻松地对微服务组件进行监控,可以监控整个系统的资源利用率、应用程序的性能和服务的健康状态。CloudWatch非常简单,只要进行一些简单的设置,您就可以拥有一套可靠、可伸缩、灵活的监控方案。您不再需要自己去维护一个复杂的监控系统。在微服务架构中运用CloudWatch的另一个好处就是,CloudWatch提供的自定义收集指标可以让开发人员针对特定服务定制特定指标。另外,基于收集到的自定义指标,自动伸缩也可以得到轻松地实现。

2. 记录日志

持续记录日志对于排查和发现问题起到非常重要的作用。微服务让产生的更新发布频率比以往传统架构更多,并鼓励工程师团队更多地尝试新的功能和特性。了解用户的影响对整个应用的逐步提升起来决定性的作用。
为了更好地调试和总览整个分布式系统的状况,我们必需将日志存储在一个统一的中心。在AWS中,您可以使用Amazon CloudWatch Logs来监控、存储和访问您EC2实例上、CloudTrail或者其他资源上的日志文件。

3. 集中管理日志

您可以有很多不同的选择来集中管理日志文件。大部分AWS服务已经“开箱即用”地集中了日志文件。在AWS中,首要的存放日志文件的地方就是Amazon S3和Amazon CloudWatch Logs。图13展示的是一些AWS服务的日志记录能力。日志文件对于每个系统来说都是重要的部分,基本每一个系统操作都会生成一条日志记录。中心化的日志管理方案就是将所有日志文件放在一个统一的中心位置,这样便于日志的访问、查询和分析。

图12:AWS部分服务的日志记录能力

4. Correlation IDs(关联ID)

在很多场景中,一个请求需要由多个微服务共同合作进行处理。想象一下,一个由数十个微服务组成的复杂的系统,当服务链中某个服务出现一个错误时的对整个服务链所造成的影响有多大。即使每一个微服务都有进行很好的日志记录,并集中化日志管理,要追踪出现的错误,需要将所有这些跟这个错误关联的日志都找出来,这是非常困难的。

关联ID的中心思想就是,当负责面向用户的服务收到请求时创建一个特定的ID。这个ID可以放在HTTP头(比如,使用类似“x-correlation-id”这个的头字段)然后在服务链中传递到其他服务中去。这个ID就可以在各个服务独立的日志中记录,这样针对特定请求,就可以根据这个关联ID将所有关联的日志记录都找出来了。

为了得到日志文件中正确的服务调用顺序,可以在HTTP头中传递一个计数器,每经过一个服务就累加一次。

审计

在微服务架构中需要处理的另一个挑战,就是潜在的数百个分布式服务如何既确保所有用户操作的可见性,又能够在组织层面获得良好的整体感观。为了加强安全管理,对资源访问和引起系统变化的操作进行审计就显得非常重要。对系统的更改无论在独个服务中,还是在跨服务的整个系统层面,都必须进行严格追踪记录。在微服务架构中,更改是经常需要发生的,这也就让对更改的审计变得更加重要。

1. 审计追踪

AWS CloudTrail是一个非常有用的在微服务中追踪更改的工具,因为它能将所有在AWS平台上的API调用进行记录,并实时传送到CloudWatch Logs或者几分钟内传送到Amazon S3中。它可以记录从AWS Management Console、AWS CLI、SDK发起或者直接调用的记录。

所有用户的行为和自动化运行的系统行为都变成可以查询和分析的。CloudTrail记录的信息包括用户账号、时间戳、调用的目标服务、调用者的IP地址、请求参数和返回响应元素。

2. 事件和实时操作

整个系统结构中有一些系统状态的变化是必须对其进行快速响应的,必须快速进行修复或者必须及时跟进处理这些变化。Amazon CloudWatch Events实现了一个近实时的事件系统。它可以声明一些适配某些系统状态变化的规则,并定义好自动响应这些变化的措施。

Amazon CloudWatch Events与CloudTrail结合,可以为所有AWS服务上的所有API调用生成事件。它还支持自定义事件或者根据某个特定的调度策略生成事件(比如定时事件)。当一个事件发生并且符合您系统中定义的规则时,CloudWatch Events将立即通知您预先定义好的系统中的某个角色或人物,以便他们及时做出响应措施。更好的做法是,当事件触发时,您可以定义自动化处理的工作流或者调用一个自定义的Lambda function。

图13展示的是使用CloudTrail和CloudWatch Events处理在一个微服务架构系统中进行审计和系统修复的需求。所有的微服务都由CloudTrail进行追踪、审计并将审计信息存储在S3 bucket中。当一个对您系统的更改发生时,CloudWatch Events能在CloudTrail基础上触发事件警告,及时通知系统管理员。您还可以对所有这些日志信息使用Elasticsearch等搜索引擎技术进行日志查询。

图13:审计追踪和系统修复

总结

微服务架构可以突破传统单体型架构遇到的种种限制,它是松耦合的,去中心化的,黑盒的,多语种的,在可用性、可靠性、可伸缩性、可扩展性、安全性、性能和工作效率上更加优秀。但微服务架构也面临着像资源管理、服务发现、消息通信、数据一致性等诸多问题和挑战,利用AWS提供的ECS及其他相关服务,可以解决微服务架构面临的挑战和难题,轻松架构微服务应用,更好地拥抱微服务带来的种种便利。

客户案例

Remind

(https://aws.amazon.com/cn/solutions/case-studies/remind/)

Remind 是一款 Web 和移动应用程序,教师可以使用该应用程序向学生发送短信并与家长保持联系。Remind 在自己的平台上拥有 2500 万名用户和 150 多万名教师,该应用程序每月可发送 1.5 亿条消息。

“迁移到 Amazon ECS 后,我们服务的性能得到了显著提升。我们将服务响应时间的第 99 个百分位降低了 50%。” – Jason Fischl 工程师副总裁

Coursera

(https://aws.amazon.com/cn/solutions/case-studies/coursera-ecs/)

Coursera 是一家教育技术公司,致力于在全球范围内提供世界上最好的课程。该公司与世界各地的顶尖大学和机构合作,为所有人免费提供各种在线课程。Coursera 拥有来自 190 个国家/地区的 1300 多万用户,提供来自 119 个机构的 1000 多个课程,涵盖从 Python 编程到作曲的各个主题。

“借助 Amazon ECS,Coursera 可以集中精力发布新软件,无需花时间管理群集。” – Frank Chen软件工程师

Shippable

(https://aws.amazon.com/cn/solutions/case-studies/shippable/)

Shippable 是一个提供托管式持续集成、测试和使用 GitHub 和 Bitbucket 等存储库进行部署的平台。该公司在从应用程序创建一直到向最终用户交付软件的整个过程中为开发人员和运营团队提供帮助,并在整个过程中实现完全的自动化和完全的控制。Shippable 的平台有助于消除实现重复性持续集成/持续交付和工作流中的阻碍和难题,这样,开发人员便能够专注于交付高质量代码。

“借助 Amazon ECS,我们的开发人员几乎不用花时间在运营相关工作上。过去,我们的高级开发人员需要将 80% 的时间花费在后端基础设施管理功能方面,而现在则将 80% 的时间投入在客户功能上。” – Avi Cavale首席执行官兼联合创始人

Segment

(https://aws.amazon.com/cn/solutions/case-studies/segment/)

Segment 为企业提供一种可从枢纽中心收集客户数据,以备日后用于分析、市场营销和其他用途的服务。该公司的总部位于旧金山,拥有广泛的客户群,从初创公司到大型企业,其中包括 Nokia、Angie’s List、Conde Nast、The Motley Fool 和 Salesforce Foundation 等。

“转而使用 Amazon ECS 大大简化了服务的运行,无需担心预配置或可用性。”- Calvin French-Owen联合创始人兼首席技术官

mytaxi

(https://aws.amazon.com/cn/solutions/case-studies/mytaxi/)

mytaxi 基于 AWS 设计了一款采用速度快且可轻松扩展的 Docker 容器的微服务架构,以应对新年除夕等特别日子的需求高峰。该公司运行着欧洲领先的出租车应用程序,此应用程序在 40 个城市中将 1000 万用户与 45000 辆出租车联系起来。整个基础设施都构建在 AWS 之上,其中的 Amazon EC2 和 Amazon ECS 等服务可为 mytaxi 的 Docker 容器提供支持。

“2015 年 11 月,我们将 Docker 容器架构移动到了 Amazon ECS,而在 12 月,我们有史以来第一次能够庆祝新年,因为我们的系统可以处理大量请求,并且没有发生任何崩溃或中断,我们对这项成就感到极为自豪。”- Sebastian Herzberg系统工程师

 

Burda Studios

(https://aws.amazon.com/cn/solutions/case-studies/burda-studio/)

BurdaStudios 是全球媒体集团 Hubert Burda Media 的一个部门,拥有近 10000 名员工和 500 多个品牌,包括家庭和生活方式类杂志以及企业间出版物。BurdaStudios 专门从事影视制作和数字出版。该公司的旗舰网站是 Bunte.de,一个在德语欧洲国家/地区 (德国、瑞士和奥地利) 处于领先地位的名人八卦门户。该网站是了解好莱坞演员、体育明星和皇室成员最新新闻的首选网站。它吸引了 600 万独立用户,月访问量高达 3000 – 3500 万次 (其独立用户的数量比最大竞争对手高出约 20%),通过展示、视频和本地广告盈利。

“我们通过 AWS 和微服务架构所做的事情正是数字出版业的未来。”- Hansjörg Posch BurdaStudios 首席技术官

Airtime

(https://aws.amazon.com/cn/solutions/case-studies/airtime/)

使用 AWS 服务重新设计其应用程序之后,Airtime 能够以更加快速可靠的方式为客户提供社交体验,而且不会产生任何延迟。Airtime 是一家社交媒体公司,也是一款移动应用程序,可让用户在 iOS 和 Android 设备上实时分享自己喜爱的音乐、视频,并进行消息收发。该公司通过使用 Amazon EC2、Amazon Route 53 和 Amazon S3 等基本服务开始了采用 AWS 的过程,然后重新设计了自己的平台,以便能在采用 Amazon EC2 Container Service (Amazon ECS) 和 Docker 容器的微服务架构上运行。除了改善客户体验之外,Airtime 还通过滚动部署简化了内部流程,而且可以利用 Elastic Load Balancing Connection Draining 等较新的 AWS 功能。

Abema TV

(https://aws.amazon.com/cn/solutions/case-studies/abema-tv/)

AbemaTV 是一家互联网媒体服务公司,运营着日本领先的流媒体平台之一 – FRESH!by AbemaTV。目前, FRESH! by AbemaTV 可提供大约 1400 个频道和将近 37000 个节目:从广播电台的流媒体服务到由 CyberAgent (AbemaTV 的母公司) 开发的原版影视剧,应有尽有。AbemaTV 使用 Amazon Aurora 数据存储来执行其写入密集型微服务 (例如时间表和聊天),并利用 Amazon Relational Database Service (Amazon RDS) 上的 MySQL 数据库来处理剩余的微服务 API。所有 API 都通过 Amazon CloudFront 和 Amazon API Gateway 进行管理。对于可能会影响 API 响应时间的流程,AbemaTV 实施了一套可通过 Amazon Simple Queue Service (Amazon SQS) 队列接收任务的工作程序。

“Amazon EC2 Container Service 对于我们构建具有高可用性、稳定性的微服务,以及受益于各种 AWS 服务而言至关重要。”- Akinori Yamada 工程团队

Linden Lab

(https://aws.amazon.com/cn/solutions/case-studies/linden-lab/)

Linden Lab 是一家总部位于旧金山的互联网公司,因推出 Second Life 虚拟世界而广为人知。Second Life 为用户提供了一个可生成 3D 内容并与之进行互动的平台。用户可通过 Linden Lab 的客户端程序或通过可选的第三方查看器访问 Second Life 虚拟世界。该公司的其他产品包括 Blocksworld,它让用户可以构建虚拟 3D 块并使用这些 3D 块进行游戏;还包括“Project Sansar”,这是计划于 2016 年发布的用于提供虚拟体验的新平台代码名称。

“使用 Amazon EC2 Container Service,我们可以切实地提高开发速度,从而将构建和部署时间缩短 50% 或更高。借助 Amazon ECS,我们拥有了一个非常稳定的平台,这让我们可以大幅扩展产品规模。” – Landon McDowell 运营副总裁

CyberAgent

(https://aws.amazon.com/cn/solutions/case-studies/cyberagent/)

CyberAgent 是一家互联网媒体服务公司,运营着日本领先的流媒体平台之一 – FRESH!。目前,FRESH! 可提供大约 1400 个频道和将近 37000 个节目,从广播电台的流媒体服务到原版影视剧,应有尽有。CyberAgent 使用 Amazon Aurora 数据存储来执行其写入密集型微服务 (例如时间安排和对话),并利用 Amazon Relational Database Service (Amazon RDS) 上的 MySQL 数据库来处理其余的微服务 API。所有 API 都通过 Amazon CloudFront 和 Amazon API Gateway 进行管理。对于可能会影响 API 响应时间的流程,CyberAgent 实施了一套可通过 Amazon Simple Queue Service (Amazon SQS) 队列接收任务的工作程序。

“Amazon EC2 Container Service 对于我们构建具有高可用性、稳定性的微服务,以及受益于各种 AWS 服务而言至关重要。” – Akinori Yamada 工程团队

Meteor Development Group

(https://aws.amazon.com/cn/solutions/case-studies/meteor-development-group/)

Meteor Development Group 是一款开源的跨平台 JavaScript 应用程序平台,开发人员可以使用它为 Web、Android 和 iOS 应用程序编写代码。Meteor 由总部位于旧金山的 Meteor Development Group 创建,使用分布式数据协议和发布-订阅模式自动将更改传送给客户,无需开发人员编写同步代码。Meteor 是 GitHub 上领先的 Web 应用程序框架,每天有数以千计的公司要依靠该平台构建现代化应用程序。

“AWS 的稳定性大家有目共睹。我们面临的难题是:‘我们能够扩展运行所有客户应用程序所需的计算资源数量吗?’以及,“我们能够扩展协调所有这些资源的机制吗?”使用 AWS,我们可以对这两个问题回答‘能’。” – Matt DeBergalis 联合创始人兼产品副总裁

引用

[vi] https://www.docker.com

[vii] https://aws.amazon.com/cloudformation/

[viii] https://www.consul.io/

[ix]http://gliderlabs.github.io/registrator/latest/

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

更多白皮书:https://aws.amazon.com/cn/whitepapers/

观看在线研讨会视频-运行在Amazon ECS上的微服务架构及实践

 

作者介绍

李磊,AWS解决方案架构师,负责基于AWS的云计算方案的架构设计,同时致力于AWS云服务在国内和全球的应用和推广。在大规模并发后台架构,电商系统,社交网络平台、互联网领域应用,DevOps以及Serverless无服务器架构等领域有着广泛的设计与实践经验。在加入AWS之前超过十年的开发和架构设计经验, 带领团队攻克各种技术挑战,总是希望站在技术的最前沿。

白皮书: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]

架构复杂度

在传统单体型架构中,所有的复杂度和依赖都存在项目的代码库中。而对于微服务架构而言,复杂度变成了各个服务间的交互。

在架构上面临的挑战有处理异步通信、连锁故障、数据一致性问题、服务发现和授权认证等问题。

运维复杂度

运用微服务架构,你不再只是运行一个服务,而是数十个,甚至数百个服务。这也就带来了以下问题:

  • 如何以可伸缩、低成本的方式配置好所需要的资源?
  • 如何避免不同的团队重复“造轮子”,重复处理同一个问题,或重复安装配置相同的软件工具?
  • 如何跟踪并管理好上百个代码流的部署过程和它们之间的相互依赖(不同服务可以单独部署)?
  • 如何监控整个系统的健康并提前感知潜在的热点和流量高峰?
  • 如何在整个系统各个服务间追踪和调试问题?
  • 如何分析一个快速增长并超出预期需求的分布式系统的海量日志数据?
  • 如何处理不同技术栈、开发环境间缺少统一标准的问题?
  • 如何受益于不同技术带来的开发效率,而不受困于维护升级这些技术带来的困难?

微服务与云平台

微服务近些年的崛起与诸如AWS这样的公有云平台的发展密切相关。AWS提供了可以直接解决微服务架构面临的挑战的服务。

  • 按需资源调配:资源可以快速根据资源进行配备。相对于传统的基础设施,云平台几乎可以说在资源上是没有上限的。运行于不同环境、不同版本的服务可以临时或永久地共存。不同需要进行困难的资源预测和评估。按需资源调配解决了如何以可伸缩、低成本的方式配置好所需要的资源的问题。
  • 低成本低风险地进行尝试:你只需为你使用的资源付费,从一定程序上降低了你尝试新想法的成本。新功能或者新服务可以快速地发布,并且当尝试失败时,可以快速关闭这些服务和其所需的资源。降低尝试新想法所需的成本和风险,将大力推动更多的创新。这也是跟微服务架构提倡的高度敏捷相符合。
  • 可编程性:AWS服务自带API、命令行工具(CLI)和针对不同语言的SDK。服务器甚至整个架构都可以通过编码的方式进行克隆、关闭、扩展、监控并且在发生故障时实现自动恢复。标准化和自动化是构建速度、一致性、重复性和可伸缩的关键。你可以通过编码的方式统一管理你所需的资源,减少运维微服务架构所需的精力。
  • 基础设施即代码:除了可以编写脚本来配置和管理你的资源,AWS还支持你将基础设施代码化,像应用程序的代码一样放置到版本管理工具中进行管理。因此,各个版本的基础设施都可以随时进行重新部署。你可以保证基础设施代码与应用程序代码一样的质量和性能。回滚不再只与代码相关,也包含整个基础设施。可编程性和基础设施即代码可以解决运行、维护、扩展微服务架构时面临的问题。
  • 持续交付:云平台的可编程性推动了配置和部署流程的自动化。开发阶段的持续集成概念也因此可以扩展到运维阶段(因为运维也是可编码的了),从而形成持续集成与交付的概念。持续交付解决了如何同时管理多个代码流并行部署交付的问题。
  • 自我管理的服务:云平台最出色的优点就是服务都是自我管理的。你不再需要进行繁重的配置虚拟机、安装配置优化软件、处理资源伸缩扩展、管理备份等运维工作。诸如监控、安全、记录日志、伸缩和保持可用性等系统操作和特性都在云平台服务中内置好了。自我管理的服务从一定程度上缓解了运行微服务架构的复杂度和工作量。
  • 面向服务:AWS本身就是微服务架构的。每一个AWS服务都是针对某个特定问题域的,并且都是通过API进行相互通信。你可以将这些服务像乐高积木一样组合成复杂的结构,用来解决特定的问题。这样就解决了重复“造轮子”的问题。
  • 多语种:AWS提供了多种存储得数据库技术供你选择。AWS Marketplace上有许多可以运行在EC2上的操作系统供你使用。AWS的SDK支持各种各样主流开发语言。这可以让你根据特定问题选择最合适的技术方案,从而避免重复“造轮子”问题。

引用

[i] https://www.google.com/trend/explore#q=Microservices
[ii] https://en.wikipedia.org/wiki/DevOps
[iii] https://en.wikipedia.org/wiki/Conway%27s_law
[iv] https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing
[v] https://aws.amazon.com/devops/

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

更多白皮书:https://aws.amazon.com/cn/whitepapers/

观看在线研讨会视频-运行在Amazon ECS上的微服务架构及实践

作者介绍

李磊,AWS解决方案架构师,负责基于AWS的云计算方案的架构设计,同时致力于AWS云服务在国内和全球的应用和推广。在大规模并发后台架构,电商系统,社交网络平台、互联网领域应用,DevOps以及Serverless无服务器架构等领域有着广泛的设计与实践经验。在加入AWS之前超过十年的开发和架构设计经验, 带领团队攻克各种技术挑战,总是希望站在技术的最前沿。

Amazon EC2 Container Service打造容器化的SaaS应用

概述

在SaaS化应用的改造中,容器技术的应用越来越广泛。相对于传统的虚拟机模式,容器化模式的隔离技术“更轻量”,“ 更快速”,“ 更便捷”. 目前业界越来越广的使用“容器”技术用于应用的微服务化改造,将自己产品的一些服务“微服务”化,构建基于云平台的SaaS化应用。

容器技术改造的难点

1. 技术的复杂性

容器技术应用的难点在于生产环境的实施及部署, 一般需要解决

  • 容器资源编排调度
  • 服务的自动发现及注册
  • 容器的监控及报警
  • 容器的扩展及收缩

这只是解决的部分问题,用户还必须去解决生产环境部署中怎样实现高可用部署及与公有云平台的集成问题。这使得Docker的生产化部署变得困难。

2. Docker编排框架的选型

许多人认为容器技术的价值在编排层,目前在容器的编排框架上主要的流派正在上演 “三国演义”包括,Google Kubernetes、Apache Mesos、Docker  DockerSwarm. Kubernetes,Mesos是目前市场上比较成熟的解决方案,占有较大的市场份额。DockerSwarm的优点是与Docker平台中的许多功能的集成,因为它平滑地内置于Docker平台中。上述三个编排框架都开放源代码,用户只需为技术支持服务付费。除了这些标准外还有许多初创公司也推出了自有的编排框架, 如Rancher使用Java语言开发了Cattle,它是Rancher实现的自有的一套基于Docker的编排引擎。众多的开源或自有的编排框架在不断发展,演进。这给客户的技术平台选型也带来极大的挑战。

Amazon EC2 Container Service(ECS)

为了降低容器平台生产部署的复杂性,Amazon ECS提供了一个平台来管理Docker容器。Amazon ECS是一项高度可扩展的高性能容器管理服务,您将不再需要安装、运维、扩展自己的群集管理基础设施。只需进行简单的 API 调用,您便可以启动和停止支持 Docker 应用程序,查询群集的完整状态,使用各种熟悉的功能,包括安全组、Elastic Load Balancing、EBS 卷和 IAM 角色。您可以使用 Amazon ECS 根据您的资源需求和可用性要求在您的群集中安排容器的置放。您还可以集成自己的或第三方的计划程序,以满足业务或应用程序的特定要求。Amazon EC2 Container Service 没有任何附加费用。您只需为您创建的用于存储和运行应用程序的 AWS 资源 (例如 EC2 实例或 EBS 卷) 付费。Amazon ECS的介绍,请参阅:https://aws.amazon.com/cn/documentation/ecs/

让我们来先看一个简单的Docker应用场景

客户有多套应用系统部署在云端,采用虚拟机隔离的方式,每套系统独占虚拟机资源,造成资源利用率不高。希望通过微服务化改造来提高云资源的利用效率及应用部署的敏捷性。改造的方法是从系统架构上分离应用层,使用Docker来封装应用层工作负载。采用Docker封装是微服务化改造最便捷的一种方式,因为对原有系统的代码修改少。降低了改造,迁移的成本。

将WEB,APP层直接封装成Docker容器运行。前端通过负载均衡传入流量,并负载均衡到Docker集群上。 需要实现服务的自动发现及注册,两级(Docker, EC2)自动扩展/收缩及容器的监控及报警。

下面我们就来介绍一下基于Amazon ECS的实现方法。

1. 应用层的封装

ECS提供了ECR(存储库),具有与Docker HUB一样的镜像存储管理功能.我们准备一个镜像来演示我们的应用层封装,这是一个Apache服务器的镜像,Dockerfile定义如下:

为了模拟三个不同的应用,我们对Apache服务器的配置做小小的更改:

在配置文件中新加了两个目录: app1, app2.并更改目录的初始页面的标题为目录名,这样当访问

提交更改

将镜像Push到ECR存储库,就得到了我们封装的应用层镜像

2. 创建服务

ECS有几个比较重要的概念。 任务服务集群

  • 任务就是您的应用程序的蓝图,是一个最基本的功能单元,包括构成应用程序的一个或多个容器,比如我们的案例中,封装的Apache镜像就是一个任务只包含了一个容器,但在实际案例中任务可能会有一个或多个容器,比如WEB容器,APP容器,它们共同组成一个任务。
  • 多个在一个容器实例或跨主机容器实例运行的任务就构成了服务,服务更像是一个应用的集群,ECS可以与ALB集成实现服务的自动注册及发现。通过使用动态端口映射选项,我们可以简单地注册一个服务到负载均衡器,而 ECS透明地管理Docker容器的注册和注销。我们还得到了传统负载平衡器的所有特性,如健康检查、连接保持和访问日志等。
  • 集群是EC2 实例的逻辑分组。Amazon ECS 从您指定的注册表中下载容器映像,并在集群内的容器实例上运行这些映像。

我们首先创建任务:

由于我们通过不同的URL路径来区分不同的应用,这里只需要创建一个任务定义

任务定义名称: taskweb

任务角色:

网络模式:        桥接

约束:

容器定义:

容器名称: dockerweb

映像: 772041933387.dkr.ecr.us-east-1.amazonaws.com/web-app:v1

内存限制:512M

端口映射:    主机端口:0  容器端口:80  协议:tcp

命令:    /usr/sbin/apache2,-D,FOREGROUND

然后创建集群:

集群名称: erp

实例配置:

预配置模型: 按需实例

EC2 实例类型: m4.large

实例的数量: 4

EC2 Ami Id: amzn-ami-2016.09.g-amazon-ecs-optimized [ami-275ffe31]

EBS 存储: 22

密钥对: martin

联网:

VPC: martin

子网: Pub1

Pub2

安全组: ECSSG

容器实例IAM 角色: ecsInstanceRole

创建负载均衡的ALB

名称: albdocker

模式: 面向internet

IP 地址类型: ipv4

侦听器: http:80

可用区

VPC: martin

AZ: pub1

pub2

分配安全组: ecssg
目标组名称: targetweb

协议: HTTP

端口: 80

运行状况检查

协议: HTTP

路径: /index.php
目标组名称: targetapp1

协议: HTTP

端口: 80

运行状况检查

协议: HTTP

路径: /index.php
目标组名称: targetapp2

协议: HTTP

端口: 80

运行状况检查

协议: HTTP

路径: /index.php

在集群中创建代表不同应用的服务:

服务名称:srvweb

任务定义: taskweb:8

集群: erp

任务数: 2

任务放置模板: AZ均衡放置

可选配置: Elastic Load Balancing

ELB 名称: albdocker

目标组名称: targetweb

路径模式: /

运行状况检查路径: /index.php
服务名称:srvapp1

任务定义: taskweb:8

集群: erp

任务数: 2

任务放置模板: AZ均衡放置

可选配置: Elastic Load Balancing

ELB 名称: albdocker

目标组名称: targetapp1

路径模式: /

运行状况检查路径: /index.php
服务名称: srvapp2

任务定义: taskweb:8

集群: erp

任务数: 2

任务放置模板: AZ均衡放置

可选配置: Elastic Load Balancing

ELB 名称: albdocker

目标组名称: targetapp1

路径模式: /

运行状况检查路径: /index.php

创建完服务后,srvapp1, srvapp1, srvweb已经自动完成在ALB的注册

实现了如下的架构:

集群的状态如下:

现在我们已经实现了微服务化的改造,通过不同的URL就可以访问运行在Docker集群上不同的应用程序。

3. 自动扩展/收缩及监控,报警

还有两级(Docker,EC2)自动扩展/收缩及容器的监控及报警的功能怎么实现呢?  ECS集成了Auto Scaling, Cloudwatch。在集群和服务中都有Autoscaling组,只需要简单配置就可以了,如下图:

看看是不是很简单呢?除了我们可以通过Portal来实现外,ECS还提供了API接口。那还等什么,赶紧去试试吧!

 

作者介绍

杨历,AWS解决方案架构师负责AWS中国合作伙伴生态系统的技术支持工作,致力于为合作伙伴提供AWS云计算方案架构的咨询和设计,上云迁移, 应用优化,培训等服务。在高可用,灾备解决方案,大规模并发应用架构,自动化运维,RDBMS,数据仓库,数据集成等方面有着广泛的设计和实践经验。在加入AWS之前曾在Oracle研发中心,Oracle中国,微软中国担任研发工程师,资深技术顾问等工作。