使用Azure云服务架构多服务企业应用程序

Question

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

背景故事

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

工艺流程

让我简要地描述一组简化的服务和流程，然后提出一些有关使用Azure云服务来构建新系统的问题。

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

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

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

A和B都将其数据移交给服务C，服务C将协调来自两个外部源的数据。

然后，将经过验证和对帐的数据从C传递到服务D，该服务执行某些会计功能，然后将结果数据传递到服务E和F。

服务E持续登录到外部系统并向其上载数据。

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

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

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

问题

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

2. 服务C和D是使用多个工作人员角色实例进行扩展的不错选择。 但是，每个实例都必须处理相关数据。 例如，我们可以有4个实例，每个实例为5个单独的客户端处理数据。 我们如何让每个实例按组（以客户为中心）对消息进行处理？ 此外，当进行修补等时，我们如何将负载从一个实例重新分配给其余实例。例如，如果实例1（为5个客户端处理数据）掉线进行OS修补，则其客户端的数据必须为其余实例进行处理，直到再次恢复。 同样，如果我们决定增加其他工作人员角色，又如何重新分配负载？

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

垫

Answer 1

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

问题2：研究Azure Service Bus。 它具有允许客户端处理相关消息的功能。 此处的更多信息： http : //geekswithblogs.net/asmith/archive/2012/04/02/149176.aspx所有排队方法都意味着，如果在可配置的时间内拾取了一条消息但未对其进行处理，它将继续返回队列，以便下一个可用实例可以将其拾取并处理

您可以使用诸如AzureWatch之类的工具来监视队列（存储或服务总线）的深度，并自动调整C和D角色中实例的数量以进行匹配； 并监视角色A，B和E的实例状态，以确保那里始终有正常的实例，并在就绪实例的数量降至0时自动缩放。

高温超导

Answer 2

首先，备份一个步骤。 在Windows Azure上查看应用程序体系结构时，我要做的第一件事就是确定该应用程序是否适合迁移到Windows Azure。 我特别关注应用程序中有多少集成-集成总是比预期的要困难得多，而在云中进行集成时则更是如此。 如果您的大部分工作量需要通过一个始终在线的连接来完成，那么您将很难获得我们向云求助的可用性和可伸缩性。

在不知道您的应用程序详细信息的情况下，以示例方式，假设服务A和B是来自财务数据提供者的提要。 数据提要的提供者确实擅长于其工作，具有高可用性并为企业级成本提供“企业级”（无论其含义如何）。 他们的体系结构也是古老的，在某些情况下非常僵化。 因此，首先，请考虑让您的供稿提供商（提供登录/连接并希望您提取数据）通过Web服务将数据推送给您。 公开的Web服务是扩展和性能的解决方案，并用于Azure上的表存储以及DynamoDB等高吞吐量数据库服务。 （我将挑战任何企业数据提供商，以解释像Amazon S3这样的服务是如何实现米老鼠的。）如果您的数据提供商通过约定的API将数据推送到Web服务，则可以对该服务执行各种扩展和可用性工程成本低。

正如您发现的那样，您的替代方法是构建大量内容，以确保您的体系结构适合数据供应商的单节点模型。 尽管可以做到，但您将花费大量工程资金来手动推导一大堆分布式计算原理。 如果要使用主动-被动体系结构，则需要实现领导者选举算法，以确定何时应该将被动节点变为主动。 这听起来并不简单，因为一个活动节点看起来好像已经消失了，但仍在处理中，并且您不想在其位置插入另一个节点。 因此，您将实现一个心跳信号，或什至是一个单独的“见证”节点，除了监视哪些节点仍在运行以对其进行处理之外，别无所求。 您提到停机和打补丁是不可接受的。 那么什么可以接受？ 是几分钟还是几秒钟，还是不到一秒钟？ 您是要让被动节点接管另一个节点还是从另一个节点开始？

您可能会发现，实现所有这些功能的开发成本低于构建和托管高可用性物理服务器的成本。 也许您可以将负载分开并在物理机箱上的单独运行中运行数据源服务，并在Windows Azure上完成繁重的处理。 我什至不会看Azure虚拟机，因为尽管它们不像角色那样循环使用，但它们偶尔会遇到问题-至少比企业级硬件还要多。 首先与您的数据提要供应商进行讨论-他们可能有一个解决方案，或者一个可以将其拼凑在一起的解决方案（例如，两次登录仅需支付一个价格，而“第二个”帐户/实例通常会丢弃其数据）。

对传统企业集成要非常小心。 他们要求在当今面向云的世界中看起来很奇怪的事情。 例如，我已经请求我的呼叫服务具有固定的IP地址。 您可能会发现，为解决其他人的体系结构而必须编写的代码最好花在购买物理服务器上。 推迟数据提供者-现在是他们摆脱90年代的时候了。

[免责声明]“企业”，特别是那些从事金融服务的企业，一直在说他们的要求很特殊-更高的吞吐量，更高的安全性，更高的法规和更高的可用性。 除了极少数情况（例如高频交易）外，我倾向于在大多数情况下称之为“牛市”。 他们受到大量IT预算和昂贵套件供应商的影响，使他们无法享用午餐，并且灌输了他们对服务器抱有的信念。 我对企业硬件/软件/服务业务的个人看法影响了这个答案。 你的旅费可能会改变。