0

我对使用 azure 云服务构建企业应用程序有一些疑问。

返回故事

我们有一个由 SQL 后端上的十几个 WCF Windows 服务组成的系统。我们目前有大约 10 个客户端，但预计可能会增长到 100 个，系统的吞吐量需求可能会增加 100 倍。当前的系统设计不佳，根本无法扩展。因此，现在似乎是在 azure 平台上重新设计的合适时机。

工艺流程

让我简要描述一组简化的服务和流程，然后问一些关于使用 azure 云服务构建新系统的问题。

服务 A 登录到外部系统并持续下载数据

服务 B 登录到第二个外部系统并持续下载数据

服务 A 和 B 中的每一个都只能有一个登录实例。

A 和 B 都将他们的数据传递给服务 C，后者协调来自两个外部源的数据。

然后将经过验证和核对的数据从 C 传递到服务 D，后者执行一些记帐功能，然后将结果数据传递给服务 E 和 F。

服务 E 不断登录到外部系统并向其上传数据。

服务 F 生成报告并通过 FTP 等发布给客户端

该系统实际上远比这复杂得多，但上面说明了所涉及的过程。该系统每周 6 天、每天 24 小时运行。队列将用于缓冲所有服务之间的消息传递。

我们可以使用 Azure 持久性虚拟机构建这个系统，并利用服务总线、队列等，但这会将我们与垂直扩展策略联系起来。鉴于以下问题，我们如何利用云服务来实现它。

问题

  1. 鉴于服务 A、B 和 E 永久登录到外部系统，每个系统只能有一个活动实例。如果我们将这些实现为单实例工作者角色，则会出现停机和修补问题（这是不可接受的）。如果我们为每个实例创建两个实例，是否有一种标准方法可以在 azure 上使用工作角色实现主动-被动负载平衡，或者我们是否必须构建自己的负载平衡器？这个问题有没有我没有想到的另一种解决方案？

  2. 服务 C 和 D 是使用多个工作角色实例进行扩展的良好候选者。然而，每个实例都必须处理相关数据。例如，我们可以有 4 个实例，每个实例为 5 个单独的客户处理数据。我们如何让每个实例分组处理消息（以客户端为中心）？此外，在进行修补等时，我们如何将负载从一个实例重新分配到其余实例。例如，如果为 5 个客户端处理数据的实例 1 因操作系统修补而停机，则其客户端的数据必须是由其余实例处理，直到它再次恢复。同样，如果我们决定增加额外的工作者角色，我们如何重新分配负载？

您能提供的任何见解或建议将不胜感激。

垫

4

2 回答 2

0

问题 #1：您必须实现自己的负载平衡。这应该不会非常复杂，因为您可以使用 Blob 存储租用功能在一个实例的存储中的某个 Blob 上保留互斥锁，同时保持与外部系统的连接处于活动状态。如果您知道连接仍然有效且成功，则可以每隔 X 时间续订一次租约。角色中的每个其他工作人员都可以检查该租约以查看它是否过期。如果它过期了，下一个工作人员会加入并获取租约，然后打开与外部源的连接。

问题 #2：查看 Azure 服务总线。它具有允许客户端处理相关消息的能力。更多信息在这里： http: //geekswithblogs.net/asmith/archive/2012/04/02/149176.aspx 所有排队方法都意味着如果一条消息被拾取但没有在可配置的时间内得到处理，它就会去回到队列中，以便下一个可用实例可以拾取并处理它

您可以使用AzureWatch之类的工具来监控队列的深度（存储或服务总线）并自动缩放 C 和 D 角色中的实例数量以匹配；并监控角色 A、B 和 E 的实例状态，以确保那里始终有一个健康的实例，并在就绪实例的数量降至 0 时自动扩展。

高温高压

于 2013-03-11T04:29:47.103 回答
0

首先，后退一步。在查看 Windows Azure 上的应用程序架构时，我做的第一件事就是确定该应用程序是否适合迁移到 Windows Azure。我特别关注应用程序中有多少集成——集成总是比预期的更困难，在云中进行时更是如此。如果您的大部分工作负载需要通过一个始终在线的连接来完成，那么您将很难获得我们转向云的可用性和可扩展性。

在不知道您的应用程序的细节的情况下，但作为示例，假设服务 A 和 B 是来自金融数据提供商的提要。数据馈送的提供者非常擅长他们的工作，具有高可用性，并为企业级成本提供“企业级”（无论这意味着什么）。他们的架构也是老派的，在某些情况下，非常死板。因此，首先，请考虑要求您的提要提供商（提供登录/连接并希望您提取数据）通过 Web 服务向您推送数据。公开的 Web 服务是扩展和性能的解决方案，用于从 Azure 上的表存储到 DynamoDB 等高吞吐量数据库服务。（我将挑战任何企业数据提供商来解释像 Amazon S3 这样的服务如何是米老鼠。

正如您所发现的，您的替代方案是构建大量的东西，以确保您的架构适合您的数据供应商的单节点模型。虽然可以做到，但您将花费大量工程资金来手动掌握一大堆分布式计算原理。如果您打算采用主动-被动架构，则需要实现领导者选举算法，以确定被动节点何时应该变为活动状态。这并不像听起来那么微不足道，因为一个活动节点可能看起来已经消失了，但仍在处理中——而且您不想在其位置上插入另一个节点。因此，您将实现一个心跳，甚至是一个单独的“见证”节点，除了密切关注哪些节点是活动的以便对它们做一些事情之外什么都不做。您提到停机和修补是不可接受的。那么什么是可以接受的呢？几分钟或几秒钟，还是不到一秒钟？您希望被动节点从其他节点停止的地方接管，还是重新开始？

您可能会发现实现所有这些的开发成本低于构建和托管高可用性物理服务器的成本。也许您可以分离负载并在物理机器上以共同的方式运行数据馈送服务，并在 Windows Azure 上完成繁重的处理工作。我什至不会看 Azure VM，因为尽管它们不像角色那样循环利用，但它们偶尔会遇到问题——至少比企业级硬件更严重。从与您的数据馈送供应商讨论开始——他们可能有一个解决方案，或者一个可以拼凑在一起的解决方案（例如，一次登录两次，而“第二个”帐户/实例大多丢弃其数据）。

对传统企业整合要非常小心。他们要求在当今面向云的世界中看起来很奇怪的东西。例如，我曾要求我的呼叫服务有一个固定的 IP 地址。您可能会发现，为解决其他人的架构而必须编写的代码最好花在购买物理服务器上。抵制数据提供者——他们是时候走出 90 年代了。

[免责声明]“企业”，尤其是金融服务行业的企业，一直在说他们的要求是特殊的——更高的吞吐量、更高的安全性、高法规和更高的可用性。除了极少数情况（例如高频交易）外，我倾向于在大多数情况下称其为“牛市”。他们受到大量 IT 预算和昂贵工具包供应商带他们去享用美味午餐的影响，并被灌输给他们拥抱服务器的信念。我对企业硬件/软件/服务业务的个人看法影响了这个答案。你的旅费可能会改变。

于 2013-03-11T14:45:51.433 回答