我对使用azure云服务构建企业应用程序有一些疑问。
Back Story
我们在SQL后端有一个由大约12个WCF Windows服务组成的系统。我们目前有大约10个客户，但预计可能会增加到100个，系统的吞吐量需求可能会增加一百倍。目前的系统设计很差，根本无法扩展。所以现在似乎是在天蓝色平台上重新设计的适当时机。
流程
让我简要描述一组简化的服务和流程，然后提出一些有关利用azure云服务构建新系统的问题。
服务A登录到外部系统并连续下载数据
服务B登录到第二个外部系统并连续下载数据
每个服务A和B只能有一个登录实例。
A和B都将他们的数据交给服务C，服务C协调来自两个外部来源的数据。
然后，验证和协调的数据从C传递到服务D，后者执行一些会计功能，然后将结果数据传递给服务E和F.
服务E不断登录到外部系统并上传数据。
服务F生成报告并通过FTP等将其发布给客户
系统实际上比这复杂得多，但上面说明了所涉及的过程。该系统每周6天，每天24小时运行。队列将用于缓冲所有服务之间的消息传递。
我们可以使用Azure持久性虚拟机构建此系统，并利用服务总线，队列等，但这会将我们与垂直扩展策略联系起来。考虑到以下问题，我们如何利用云服务来实现它。
问题
鉴于服务A，B和E永久登录到外部系统，每个系统只能有一个活动实例。如果我们将这些实现为单实例工作者角色，则存在停机和修补的问题（这是不可接受的）。如果我们创建了两个实例，那么有一种标准方法可以在azure上实现与工作者角色的主动 - 被动负载平衡，还是我们必须构建自己的负载均衡器？我还没有想到这个问题的另一个解决方案吗？
服务C和D是使用多个辅助角色实例进行扩展的理想选择。但是，每个实例都必须处理相关数据。例如，我们可以有4个实例，每个实例处理5个单独客户端的数据。我们如何才能让每个实例以组（以客户为中心）处理消息？此外，当修补发生时，我们如何将负载从一个实例重新分配到剩余的实例等。例如，如果为5个客户端处理数据的实例1关闭以进行操作系统修补，那么其客户端的数据必须是由剩余的实例处理，直到它再次恢复。同样，如果我们决定增加额外的工作人员角色，我们怎么能重新分配负载呢？
非常感谢您能提供的任何见解或建议。
垫
答案 0 :(得分：0)
问题＃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时自动调整。
HTH
答案 1 :(得分：0)
首先，备份一步。在Windows Azure上查看应用程序体系结构时，我要做的第一件事就是确定该应用程序是否适合迁移到Windows Azure。我特别关注应用程序中的集成程度 - 集成总是比预期更困难，在云中进行集成时更是如此。如果您的大部分工作量需要通过单个永远在线的连接来完成，那么您将很难获得我们转向云的可用性和可扩展性。
在不知道您的应用程序的详细信息的情况下，但举例来说，假设服务A＆amp; B是来自金融数据提供者的馈送。数据馈送提供商非常擅长他们的工作，具有高可用性，并提供企业级成本的“企业级”（无论这意味着什么）。他们的建筑也是老式的，在某些情况下，非常严格。首先，请考虑询问您的Feed提供商（提供登录/连接并希望您提取数据）以通过Web服务向您推送数据。暴露的Web服务是扩展和性能的解决方案，可用于Azure上的表存储，也可用于DynamoDB等高吞吐量数据库服务。 （我将挑战任何企业数据提供商来解释像Amazon S3这样的服务是如何使用mickey-mouse。）如果您的数据供应商通过商定的API将数据推送到Web服务，您可以在服务上执行各种扩展和可用性工程成本低。
正如您所发现的，您的替代方案是构建大量内容以确保您的体系结构符合数据提供者的单节点模型。虽然可以做到，但您将花费大量的工程资金来实现一大堆分布式计算原则。如果您要使用主动 - 被动架构，则需要实施领导者选举算法，以确定被动节点何时应变为活动状态。这并不像听起来那么微不足道，因为主动节点可能看起来已经消失，但仍在处理 - 而且你不想在其位置插入另一个节点。那么你将实现一个心跳，甚至是一个单独的“见证”节点，除了关注哪些节点存在以便对它们做些什么之外什么都不做。您提到停机时间和修补是不可接受的。什么是可以接受的？几分钟或几秒钟，还是不到一秒钟？您希望被动节点从另一个停止的地方接管，还是重新开始？
您可能会发现实现所有这些的开发成本低于构建和托管高可用性物理服务器的成本。也许您可以分离负载并在物理盒上的co-lo中运行数据馈送服务，并且可以在Windows Azure上完成大量处理。我甚至不会看Azure VM，因为虽然它们不像角色那样回收，但它们偶尔会遇到问题 - 至少不仅仅是企业级硬件。从与数据源供应商的讨论开始 - 他们可能有一个解决方案，或者可以拼凑在一起的解决方案（例如，两个登录的价格为一个，而'第二个'帐户/实例主要抛弃其数据）。
要非常小心传统的企业集成。他们要求在今天的云导向世界中看起来很奇怪的事情。例如，我有一个请求，我的呼叫服务有一个固定的IP地址。您可能会发现，为了解决其他人的体系结构而必须编写的代码最好花在购买物理服务器上。推迟数据提供商 - 现在是他们退出90年代的时候了。
[免责声明]'企业'，特别是那些从事金融服务的企业，一直表示他们的要求是特殊的 - 更高的吞吐量，更高的安全性，更高的法规和更高的可用性。除了极少数情况（例如高频交易）之外，我倾向于在大多数情况下称之为“牛市”。他们受到大量IT预算和昂贵套件供应商的影响，他们将他们带入花哨的午餐，并被灌输到他们拥抱服务器的信念中。我个人对企业硬件/软件/服务业务的看法影响了这个答案。您的里程可能会有所不同。