2

I'm thinking about moving my DAL which uses DocumentDb and Azure Table Storage to a separate Web API and host it as a cloud service on Azure.

The primary purpose of doing this is to make sure that I keep a high performance DAL that can scale up easily and independently of my front-end application -- currently ASP.NET MVC 5 running as a cloud service on Azure but I'll definitely add mobile apps as well. With DocumentDb and Azure Table Storage, I'm finding myself doing a lot of data handling in my C# code, therefore, I think it would be a good idea to keep that separate from my front-end application.

However, I'm very concerned about latency issues introduced by HTTP calls from one cloud service to another which would defeat the purpose of separating DAL into its own application/cloud service.

What is the best way to separate my DAL from my front-end application without introducing any latency issues?

4

2 回答 2

2

我认为横向扩展/分区资源和网络延迟之间的权衡是不可避免的。话虽如此，当使用大型系统工作时，出于多种原因（即启用应用程序任务的并行执行、提高可靠性等），您可能会发现这种折衷是值得的。

以下是一些通用提示，可帮助您最大限度地减少对网络延迟的影响：

  • 尽可能使用缓存来避免跨服务调用。
  • 尽可能批处理跨服务调用和重用连接，以最大限度地减少从一个云服务穿过 NAT 并通过负载均衡器进入另一个云服务的相关成本。注意 - 您的应用程序还必须能够处理断开的连接（在云架构中是不可避免的）。
  • 尽可能监控性能指标以进行测量并识别瓶颈。
  • 将您的应用程序层放在同一个数据中心内，以将跨服务延迟降至最低。

您可能还会发现以下文献很有用： http: //azure.microsoft.com/en-us/documentation/articles/best-practices-performance/

于 2014-09-16T18:43:39.667 回答
1

我最近将我的 DAL 拆分为一个 WebAPI，该 WebAPI 为 MVC 网站和移动应用程序提供来自 DocumentDB 的数据，原因与提问者所述的相同。

来自 aliuy 的声明是公认的良好实践的有效性能考虑。

但更具体地说 - 为了使用 Azure 云服务从 MVC 调用 Web API 而没有延迟，应该为每个资源（网站、云服务等）指定相同的关联组。

关联组是您可以通过 Azure 数据中心中的彼此接近程度对云服务进行分组以实现最佳性能的一种方式。创建关联组时，它会让 Azure 知道将属于您的关联组的所有服务在物理上尽可能地彼此靠近。

https://azure.microsoft.com/en-us/documentation/articles/virtual-networks-migrate-to-regional-vnet/

于 2014-10-09T02:32:27.537 回答