ASP.NET Core Service Fabric 演示





3.00/5 (2投票s)
在 Visual Studio 2019 中开发演示服务织布。
引言
越来越多的企业因其卓越的性能而选择云作为其电子商务平台。Microsoft Azure 云 Active Directory 为基于 Web 应用程序的信息系统提供了完美的身份管理平台。Azure 云中的资源组可以理想地对业务资产进行分类,例如可以存储在 Azure 云中并用于整个业务应用程序的结构化和非结构化数据。
Azure 云可以将本地应用程序集成到云中。Azure 云可以为下一代 Web 技术提供 .NET 技术的容器化,这会给传统 Web 技术带来巨大的变革。一个很好的例子是能够扩展资源后端以应对高密度的客户端访问请求,例如数千万用户同时登录系统而不会影响性能。
Azure ASP.NET 微服务和 Service Fabric 分布式应用程序是用于未来业务需求的新技术。
开发
从 Visual Studio 2019 创建新的 Service Fabric 项目,选择有状态 ASP.NET Core Web 服务和 API,然后单击下面的创建按钮
向项目中添加新的 API 控制器,并按下面的方式更新 get 和 put 代码
构建解决方案并将其部署到本地群集,请参见下图
由于 ASP.NET Core Web 服务的自托管功能,本地群集可以像 IIS Web 服务器一样工作,管理 Web 应用程序,就像 IIS Web 服务器通常所做的那样。打开下面的云资源管理器以浏览群集。
单击左窗格中的实例以获取微服务 URL 链接,如下所示
由于后端服务被调用时动态 URL 和端口号会不断变化,因此前端微服务无法调用它,因为前端微服务需要一个静态 URL。但是,我们可以将此动态 URL 复制到 postman 中并在 postman 中进行 get 和 put 测试,如下所示
为了使此后端服务能够被 API 客户端调用,我们需要在 API 客户端中创建代理 URL,此代理 URL 可以将 URL 映射到此后端服务。
我们可以向此 Web 解决方案添加许多其他项目,例如前端无状态 ASP.NET Core MVC 微服务。此 MVC 控制器可以使用有状态后端微服务的代理 URL 来消耗后端数据。
因此,无状态 MVC 控制器中的方法是将请求从 UI 传递到有状态后端微服务,等待后端响应,然后将响应解析到 UI 中。
有状态微服务是副本服务,可以复制为新实例以响应新的前端请求。这允许我们在前端需要处理大量请求时扩展后端服务。
前端无状态微服务可以触发群集中从主后端服务复制的新服务。复制后,此服务被视为新客户端请求的主服务。因此,客户端服务可以使用新的代理 URL 连接到此新的后端服务。
Service Fabric 应用程序由无状态前端和有状态后端微服务组成。一个前端微服务可以与多个有状态后端微服务通信,一个有状态后端微服务可以与多个无状态前端微服务通信。
每个微服务都托管在节点内的 Docker 容器中。例如,上面的示例中创建了三个 Docker 容器来托管两个前端微服务和一个动态后端微服务。这是 Service Fabric 应用程序的一个迷人的新功能,它将使我们能够扩展后端服务以应对来自前端的大量请求。例如,一万名想要同时登录同一登录页面的用户,传统的 Web 应用程序只有一两个后端端点来处理这种登录,大量的请求,所以通常会崩溃这些后端。这对于需要登录页面透明工作的业务来说不是一个好做法。因此,我们可以做的是扩展后端,例如为这种大量请求创建越来越多的后端微服务。如果流量降低,后端可以根据需要缩减。当然,Service Fabric 是解决方案。
本地云是 Azure 云的开发和测试环境。我们可以在这个本地云中注册、调试、测试和部署开发的本地应用程序,就像在发布应用程序到生产环境之前在真正的 Azure 云中所做的一样。这可以为 Azure 云编程节省我们大量的资源。
本地云实际上是一个容器,其中可以创建许多 pod。默认 pod 包含种子节点,它实际上是一个 Docker 容器,可以根据需要复制此种子 Docker 容器。在此 pod 中,每个节点代表一个具有共享操作系统的 VM。每个节点用于存储独立的微服务工件,请参见下面的示例
在这里,我们可以在默认的 Node0
中创建三个 Docker 容器。这三个 Docker 容器独立存在,并具有各自的领域功能。这意味着这三个 Docker 容器中的三个应用程序不会相互干扰,除非我们让它们协同工作。这就是所谓的微服务通信,这在我们需要处理的实际应用程序中是很常见的情况。
有状态 ASP.NET Core 微服务可以动态创建。上面的示例有一个 test7 ASP.NET Core 微服务副本,它是从代码创建的,请参见下面
将此端点 URL 复制到 postman,我们可以轻松测试其 get
/put
函数,示例如下
这意味着这个有状态后端 ASP.NET Core API 微服务可以用于为 API 客户端执行 CRUD 操作。但是,这个端点 URL 是动态生成的,所以我们不能用它来进行 API 客户端调用。我们可以在 API 客户端中创建一个代理,通过 Azure/本地云中的命名服务器和 DNS 服务器将代理 URL 映射到此动态 URL。
我们可以创建一个 ASP.NET Core MVC 作为 API 客户端,示例如下
此客户端托管在另一个 Docker 容器中。它有一个静态端点 URL。我们可以从浏览器访问它,如下所示
Service Fabric 中的微服务通信允许前端与后端进行数据操作。无状态 ASP.NET Core MVC 是一个托管在 Docker 容器中的微服务,作为 API 客户端,它将调用另一个 Docker 容器中的有状态 ASP.NET Core API 微服务。API 服务端点 URL 是动态创建的,因此 API 客户端不会用它来调用。API 客户端中的代理 URL 用于此类通信,如下所示。
有状态 ASP.NET Core 后端微服务可以根据需要进行扩展。如果“/poll/test7” API 由于其带宽而无法快速响应请求,我们需要扩展这个后端瓶颈,以便将请求分配给副本后端,请参见以下示例
在这里,我们在 API 客户端的HomeController 中创建一个新方法,当传入新的查询字符串时,会在后端创建一个副本 API,如下所示
因此,成千上万的后端微服务可以轻松快速地复制,这在虚拟机中对于高流量 Web 应用程序来说非常困难。现在是时候让我们在这个领域表现出兴趣了。
历史
- 2019年5月29日:初始版本