使用 IBM Cloudant 和 Dyn 配置并运行一个多地区 Bluemix 应用程序

IBM Bluemix 即时运行时（基于 Cloud Foundry）通过在一个地区内的多个节点上运行应用程序的多个实例来支持应用程序可用性。但是，要在 Bluemix 上提供真正可靠的云应用程序，应该考虑采用某种利用了 Bluemix 的全球覆盖范围的多地区架构。

目前，在 Bluemix 上交付一个合适的多地区应用程序（能跨地区执行负载平衡的应用程序）需要一个外部路由器或路由服务。但是，即使在您完成该应用程序后，仍会面临保持您的动态内容在不同地区间同步的挑战。如果采用单一数据库方法，您的应用程序可能遇到数据库延迟问题。如果采用分布式数据库方法，您可能发现您的分布式数据库不适合分散到全球。

我将介绍如何通过以下方式配置和运行一个多地区 Bluemix 应用程序：

• IBM Cloudant NoSQL Database 的 master-to-master 复制同步您的数据
• 带 Traffic Director 的 Dyn Managed DNS 提供了地区负载平衡和故障转移

第 1 步. 注册一个域

要使用 Dyn Managed DNS，必须控制一个可以委托给您分配的 Dyn 名称服务器的域。如果已经有一个可以委托的域，请跳到第 2 步。如果没有，那么应该向任何经过认证的域名注册商（比如 Dyn 的域名注册商 ）注册一个域。

第 2 步. 在多个 Bluemix 地区创建您的应用程序

1. 导航到Bluemix，注册（如果需要）并登录。
2. 在 Bluemix 控制台中，展开右上角的 Account and Support 面板并记下您目前所在的地区。截至编写本文时，IBM Bluemix 是从 3 个不同地区托管的：

   地区	位置	控制台 URL	API 端点
   Sydney	澳大利亚悉尼	https://console.au-syd.bluemix.net	https://api.au-syd.bluemix.net
   United Kingdom	英国伦敦	https://console.eu-gb.bluemix.net	https://api.eu-gb.bluemix.net
   US South	德克萨斯州达拉斯	https://console.ng.bluemix.net	https://api.ng.bluemix.net

   每个 Bluemix 地区都独立运行，但拥有统一的计费和帐户系统。完成第 3-8 步后，需要在其他 Bluemix 地区重复这些步骤。
3. 选择 Manage Organizations ，然后选择 DOMAINS 选项卡并添加您的域：

   

4. 如果（除 HTTP 外）您想处理 HTTP 流量，那么还需要为您的域提供一个通配符 SSL 证书（例如 *.ibmjstart.biz），并将它上传到 Bluemix。（在 保护应用程序 上了解有关的更多信息。）
5. 单击 SAVE ，然后导航到 CATALOG 并创建 Node.js Cloudant DB Web Starter 样板的一个新实例。为应用程序提供一个名称，确保已从 Domain 下拉列表中选择了您的域：

   

6. 在载入应用程序期间，导航到 Overview 页面并单击 图标添加第二个路由，其中包含您的 Bluemix 地区的默认域（例如 mybluemix.net）。

   

   此路由为您提供了在配置您的自定义域的 DNS 之前，访问您在特定地区运行的应用程序版本的后门。但是，如果您希望将应用程序的访问限制到单个 URL，不要忘记在未来删除此路由。
7. 展开您的 Cloudant NoSQL DB 服务磁贴的 Show Credentials 部分，记下您的 Cloudant 帐户的密码 — 本教程后面将使用该密码。为了让不同的 Cloudant 用户名和密码保持简单，可以考虑使用一个格式类似下表的临时表：

   地区	用户名	密码
   US South	-bluemix
   United Kingdom	-bluemix
   Sydney	-bluemix

8. 记下密码后，单击该磁贴本身，然后单击 LAUNCH 启动 Cloudant 仪表板。您会有一个名为 my_sample_db 的数据库。保持仪表板处于打开状态，返回到 Bluemix 控制台。

现在对您希望托管您的应用程序的每个 Bluemix 地区重复第 3-8 步，在每个地区为该应用程序提供相同的名称和域。完成上述操作后，您的 Node.js Cloudant DB Web Starter 应该已在每个 Bluemix 地区运行，并为每个地区打开了一个 Cloudant 仪表板。

第 3 步. 配置 Cloudant 复制

1. 在每个 Cloudant 仪表板中，打开 my_sample_db 数据库的 Permissions 视图。为其他每个地区中的 Cloudant 用户名授予 Replicator 权限，或者使用 Generate API key 按钮创建一个密钥/密码组合，供其他每个地区使用。

   

2. 现在打开每个地区的 Replication 部分，从其他每个地区配置一个连续复制任务：

   

   这会在每个地区创建一个名为 “_replicator” 的新数据库，并为每个复制任务创建一个文档。
3. 配置复制后，使用您之前分配的 “后门” 路由在每个配置的地区打开您的应用程序，以便测试它们：

   地区	域
   US South	mybluemix.net
   United Kingdom	eu-gb.mybluemix.net
   Sydney	au-syd.mybluemix.net

阅读： 关于 Cloudant 复制的更多信息

Master-to-master 数据复制是 Cloudant/CouchDB 的一个良好功能，但您应该考虑如何处理文档冲突。默认策略是随机挑选冲突优胜者，但应用程序可以自行处理冲突。为此，最轻松的方式是将您的应用程序设计为通过确保唯一的 document _id 和避免文档更新来避免冲突。

阅读： 有关冲突解决的更多信息

第 4 步. 将更新部署到您的应用程序

从任何 Bluemix 地区导航回应用程序 Overview 页面，单击右上角的 ADD GIT ，然后根据对话框在新 Bluemix DevOps Services 项目中填充样板的内容。

创建存储库后，关闭该对话框并单击 GIT URL ，在 IBM Bluemix DevOps Services 中打开您的项目。接下来，单击 BUILD & DEPLOY 打开您项目的部署管道。该项目已有一个针对创建该项目时所在地区的工作管道，但您可能希望配置 Deploy Stage，将它部署到其他 Bluemix 地区。

您可以通过向 Deploy Stage 添加其他作业将其部署到其他 Bluemix 地区。一定要正确设置每个地区的目标，并保存新的配置。

现在已配置好该管道，让我们尝试稍作更改。单击页面顶部附近的 EDIT CODE ，在内置编辑器中打开 manifest.yml 文件，修改内存阈值和实例数量：

applications: - path: .   memory: 256M   instances: 2   ...

此代码告诉 Bluemix 平台（在每个地区）运行该应用程序的 2 个实例，而不是 1 个实例。无论是否采用 DNS 故障转移，都强烈建议运行应用程序的多个实例，避免在发生隔离的事故或平台维护时出现意外宕机。

备注：非试用版 Bluemix 用户会收到为期一个月在 512 MB 下运行的免费限额。因为各个地区的使用量会聚合在一起，所以这意味着上述配置将会让您超出此限额。

切换到 GIT 视图，并提交和推送您的更改。

推送您的更改会自动调用交付管道，将您的更新部署到所有已配置的地区。导航回 BUILD & DEPLOY 部分来检查进度。

第 5 步. 配置 DNS

要通过自定义域访问您的应用程序，必须首先配置域名系统，将您的路由解析到 Bluemix。要使用 Dyn Managed DNS 实现此目的， 注册其 Managed DNS 产品的 7 天免费试用版帐户 。如果想要配置地理负载平衡和故障转移，可以联系 Dyn 了解其企业计划的定价和可用性。

Managed DNS

注册后，请登录到 Dyn Managed DNS 门户并为您的自定义域创建一个新区域。

记下 Dyn 分配给您的名称服务器。您需要将它们作为 NS 记录添加到第 1 步的 DNS 注册商中，以便将您的域委托给 Dyn。可以通过以下配置了解委托您的域的更多信息：

• 委托您的 dyn.com 域
• 从一个不同的注册商委托您的域

为您的域创建一个区域并将该域委托给 Dyn 后，是时候为您的 Bluemix 应用程序配置一个子域了。为此，可以添加一个与您在 Bluemix 中的应用程序的主机名相匹配的新节点。

如果已登记参加了企业计划，请跳到 Traffic Director 部分为您的节点配置负载平衡和故障转移。如果没有登记参加企业计划，则无法在没有额外的路由层的情况下配置负载平衡，但您仍然可以继续从 Dyn 节点编辑器添加单个 CNAME Record：

将 CNAME 字段设置为您首选的 Bluemix 地区的安全端点：

备注： 这些 CNAME 记录被解析为不同于每个地区中的默认 “mybluemix” 域的 IP。如果您希望配置 A Records，必须使用这些安全 CNAME 端点的 IP，才能支持来自您的自定义域的 HTTPS。

Traffic Director

Dyn Traffic Director 是一种高度可配置的 DNS 流量管理服务，它通过响应池、规则集和监视器来提供地理位置负载平衡和故障转移。要为您的 Bluemix 应用程序配置 Traffic Director，可从 Dyn 节点编辑器上的 “Add a New Service” 下拉列表中选择它，为它提供一个标签，然后单击 CREATE SERVICE 。

接下来，为每个 Bluemix 地区创建一个单独的响应池：

使用前面的表，添加一个 CNAME Record，其中包含每个响应池的相应 Bluemix 地区的安全端点。

保留大部分字段的默认值，但可以考虑将 “Record Serve Mode” 修改为 “Monitor & Remove”。借助 “Monitor & Obey” 值，在从监视器建立一个成功连接后，故障转移流量会自动还原到响应池。这可能会导致服务反复中断。通过将模式设置为 “Monitor & Remove”，恢复就会变成一种手动干预。

接下来，为每个地区添加一个规则集来配置使用哪个响应池来处理哪些请求。

作为您的规则集的起点，可以复制以下配置：

除了地区配置之外，Response Pool Failover 字段还允许用户自定义在发生故障时采用哪些响应池。要使用此功能，还必须为您的应用程序配置一个监视器。

要配置监视器的探测位置，可将协议保留为 HTTP，将端口设置为 80 ，并指定您的 Bluemix 应用程序的主机。设置较低的 Probe Interval 来缩短潜在宕机时间，为 Expected Data 字段配置将出现在正常运行的应用程序中的信息。在我们的示例应用程序中，可以使用文本 “Favorites Organizer powered by Cloudant.”。

提示：在真实场景中，您可能希望在您的应用程序中包含一个专门的状态页面，它仅在应用程序的所有服务依赖项都正常运行时才返回预期的文本。

配置一个通知程序，以便在监视器检测到服务中断时收到一封电子邮件，这是一项可选操作。在测试配置时，您可能还希望在一个单独的选项卡中打开 Probe Results 链接，以验证对您的网站的状态检查。

配置响应池、规则集和监视器后，发布您对 Traffic Director 和区域的更改。如果所有设置都正确配置，那么您会看到节点配置编辑器中列出了 Traffic Director 服务（和您的响应池的状态）：

第 6 步. 尝试运行

1. 在浏览器中加载您的应用程序（这次使用您的自定义域）并上传一个文件。刷新该页面，确保该文件已正确上传。
2. 从命令终端（或使用您浏览器的开发人员工具）运行 nslookup 来查看哪个地区在处理您的请求。

如果使用 Traffic Director 来执行地区负载平衡和故障转移，可继续：

3. 登录到处理您的请求的地区的 Bluemix 控制台并停止该应用程序。
4. 在浏览器中刷新您的应用程序，您会收到一个 404 错误。
5. 刷新 Dyn 网站，保持 Node Editor、Traffic Director 或 Probe Results 页面处于打开状态，直到您看到状态更新。（请注意，这将取决于您在上面配置的 Probe Interval。）
6. Dyn 识别故障后，该地区会将故障转移到您的地区的下一个响应池。
7. 从命令终端运行 nslookup 来查看 DNS 更改是否已生效。该网站应在为您的 A Records 配置的 TTL（存活时间）内的某个时刻解析到它的新地址。
8. 该网站解析到它的新 IP 后，在一个新浏览器中加载该页面。请注意，一些浏览器（比如 Google Chrome）会将 DNS 响应缓存到已配置的 TTL 之后。但是，甚至在这些浏览器中，新 IP 也应在几分钟内生效。
9. 您的网站现在应从配置的故障转移地区加载。得益于 Cloudant，您在最初的地区上传的文件应仍然存在！

DNS 故障转移的限制

尽管 Dyn Traffic Director 提供了一种有用的方法来减轻特定于地区的宕机，但值得注意的是 DNS 故障转移有一些重要的限制：

• Dyn Monitor 最快每分钟轮询您的应用程序一次。
• 网络上可能不会执行短于 30 秒的 DNS TTL 语句。
• 一些浏览器（比如 Google Chrome）实现了 “DNS 锁定 (DNS Pinning)”，它会将 DNS 响应缓存比配置的 TTL 更长的时间（我的每次本地测试最长为 5 分钟）。

二者相结合，可实现最长 6.5 分钟的窗口（当用户的浏览器在发生故障转移之前锁定一个 PI 时），但平均窗口会短得多。

此外，在一些故障场景中，应用程序可能在事故过程中反复启动停止。为了避免在这些场景中恢复流量，我推荐使用 “Monitor & Remove” 服务模式来处理流量恢复行为。

备注：尽管本教程中没有介绍，但您可以通过 Dyn API 从您自己的自定义监视器调用故障转移功能，进一步缩短 60 秒的监视窗口。这也可以用于实现与自动恢复故障转移流量相关的更复杂规则。

结束语

使用 Dyn 的地区负载平衡，您的 URL 的全球访问者将由最靠近其位置的 Bluemix 数据中心处理。通过配置故障转移，您能够明确知道，如果一个 Bluemix 地区开始出现问题，那么您的用户将会定向到一个有效的站点。与 Cloudant master-to-master 同步功能相结合，是在 Bluemix 上运行容错、云原生应用程序的秘诀。

BLUEMIX SERVICES USED IN THIS TUTORIAL:

• Cloudant NoSQL 服务 提供了访问一个始终在线、全面托管的 NoSQL JSON 数据层的能力。
• IBM Bluemix DevOps Services 为您的团队提供了一个集成的应用程序开发和部署的服务集合，所以您始终可以更快地交付高质量的软件。