分类:  Azure云架构师入门    ◆ 标签:  #Azure   #基础   #Azure Cloud Architecting   ◆ 发布于: 2023-06-05 11:36:38

目前这个结构也是小型应用或者是小型企业应用在Azure云计算上常用的架构之一，相比较N层结构，反而该结构更多的小型应用首选或者更小型的企业会选用，因为很多大型企业在N层应用上已经深耕多年，他们有丰富的基础维护经验，他们直接将原有的IT团队从维护实体硬件转为维护云资源，逐步消减IT维护人员，慢慢过渡。但是采用web-queue-辅助角色这样的体系架构，该结构先天性选择Azure PaaS服务和组件，已经无需太多的IT人员参与，对于大型企业迁移应用和系统至云是不利的，因此该架构的选择不是很多传统企业的首选，反而对于一些初创企业以及更小型的企业或者应用的首选，当然也有更小型的用户直接选择一台虚拟机干完所有的事情也是可以的，但是如果有预计业务的增长，反而还是推荐选择该架构。

该架构的示意图如下:

这个图可以很好的显示架构的详细信息：

• 可以添加一个或者多个数据库
• 添加一个缓存层，例如Azure Redis
• 提供静态内容的CDN
• 可以添加一些其他的远程服务，例如电子邮件或者SMS服务等等。
• 添加用于身份验证的平台或者第三方等等，例如Azure AAD

在这个体系结构里需要注意的另外一点是架构中的各个角色本身是无状态的，如果需要会话状态的保持，就需要一个额外的存储保存会话，可能会考虑使用不同的会话技术，例如cookie或者tracking id等等。另外需要注意的辅助角色主要用于完成一些长时间运行的操作，或者是一些批处理的事件，如果没有这些业务需求，辅助角色也可以不需要。

前端可能是简单的基于MVC结构的web应用，也可能是基于web api的结果，在展示层可能是由客户代码来处理的API请求等等。

什么场景选用该结构

前面说过了这种结果在Azure上是依赖于PaaS服务的，而不是像N层应用一样选择基于IaaS的架构。因此选择该架构可以依赖于Azure的自动缩放以及基于PaaS的安全架构做出选择，例如可以选择Azure Web App的AutoScale以及ASE等等服务。总体来说，这个架构更简单，更适合一些小型的团队，应用以及企业。

• 具有相对简单的业务领域的应用，没有太复杂的业务场景。
• 应用有一些长时间运行的任务。
• 使用托管服务，而非基础架构，即想使用PaaS而不是IaaS.

架构优点

该架构的有点就是简单，很容易理解。

• 结构简单，易于理解
• 易于部署和管理
• 清晰的关注点分离结构。
• 使用异步消息分离前端和辅助的角色。
• 前端和辅助角色可以独立缩放。

可能会遇到的问题

• 前端和辅助角色容易随着规模的扩大，变得难以维护。
• 如果代码或者数据结构共享，可能会造成前端和辅助角色难以解耦。

最佳实践

• 如果使用Web API，需要仔细设计API。
• 使用自动缩放处理负载。
• 使用缓存，缓存半静态的数据。
• 使用CDN来托管全静态内容。
• 适当的使用混合的存储，例如混合使用关系型数据库或者NoSQL数据库。
• 对数据进行分区，分片，提高伸缩性，减少竞争和优化性能。

微软推荐的体系结构图

如果你要在Azure上部署该体系的结构，可以采用如下的架构，这个架构也可以作为其他云平台的参考，你总能找到相对应的组件:

这张图里可能大家会不太熟悉Azure Function, 大家可以去找找Azure function的文档阅读一下。

其他注意事项

• 并不是每个事务都必须经过队列和辅助角色才能存储。 Web 前端可以直接执行简单的读取/写入操作。 辅助角色设计用于资源密集型任务或长时间运行的工作流。 在某些情况下，可能根本不需要辅助角色。
• 使用应用服务的内置自动缩放功能来扩大 VM 实例数。 如果应用程序上的负载遵循可预测的模式，请使用基于计划的自动缩放。 如果负载是不可预测的，请使用基于指标的自动缩放规则。
• 请考虑将 web 应用和函数应用放入单独的应用服务计划。 这样，便可以单独缩放它们。
• 使用单独的应用服务计划进行生产和测试。 否则，如果使用同一计划进行生产和测试，则说明测试正在生产 VM 上运行。
• 使用部署槽位来管理部署。 这使你可以将更新的版本部署到过渡槽，然后切换到新版本。 如果更新时出现问题，它还允许你切换回以前的版本。
• 注意在web层使用第三方的api或者远程调用(指Azure 外部的)存在SNAT的限制。