您现在访问的是微软AZURE全球版技术文档网站,若需要访问由世纪互联运营的MICROSOFT AZURE中国区技术文档网站,请访问 https://docs.azure.cn.

Azure Service Fabric 上的微服务体系结构Microservices architecture on Azure Service Fabric

此参考体系结构显示了部署到 Azure Service Fabric 的微服务体系结构。This reference architecture shows a microservices architecture deployed to Azure Service Fabric. 它显示了一个基本的群集配置,可以作为大多数部署的起点。It shows a basic cluster configuration that can be the starting point for most deployments.

GitHub 徽标 github上提供此体系结构的参考实现。GitHub logo A reference implementation of this architecture is available on GitHub.

Service Fabric 参考体系结构

备注

本文重点介绍 Service Fabric 的 Reliable Services 编程模型。This article focuses on the Reliable Services programming model for Service Fabric. 使用 Service Fabric 部署和管理 容器 超出了本文的讨论范围。Using Service Fabric to deploy and manage containers is beyond the scope of this article.

体系结构Architecture

该体系结构包括以下组件。The architecture consists of the following components. 有关其他术语,请参阅 Service Fabric 术语概述For other terms, see Service Fabric terminology overview.

Service Fabric 群集Service Fabric cluster . 一组网络连接的虚拟机 (Vm) 在其中部署和管理微服务。A network-connected set of virtual machines (VMs) into which your microservices are deployed and managed.

虚拟机规模集Virtual machine scale sets . 利用虚拟机规模集,可以创建和管理一组完全相同的、负载均衡和自动缩放 Vm。Virtual machine scale sets allow you to create and manage a group of identical, load balanced, and autoscaling VMs. 它还提供了容错域和升级域。It also provides the fault and upgrade domains.

节点Nodes . 节点是属于 Service Fabric 群集的虚拟机。The nodes are the VMs that belong to the Service Fabric cluster.

节点类型Node types . 节点类型表示部署节点集合的虚拟机规模集。A node type represents a virtual machine scale set that deploys a collection of nodes. Service Fabric 群集至少具有一个节点类型。A Service Fabric cluster has at least one node type. 在具有多个节点类型的群集中,一个必须声明 为主节点类型In a cluster with multiple node types, one must be declared the Primary node type. 群集中的主节点类型运行 Service Fabric 系统服务The primary node type in the cluster runs the Service Fabric system services. 这些服务提供 Service Fabric 的平台功能。These services provide the platform capabilities of Service Fabric. 主节点类型也充当群集的 种子节点 ,这是维护基础群集可用性的节点。The primary node type also acts as the seed nodes for the cluster, which are the nodes that maintain the availability of the underlying cluster. 配置 其他节点类型 以运行服务。Configure additional node types to run your services.

服务Services . 服务可执行独立于其他服务启动和运行的独立功能。A service performs a standalone function that can start and run independently of other services. 服务实例部署到群集中的节点。Instances of services get deployed to nodes in the cluster. Service Fabric 提供了两种服务:There are two varieties of service in Service Fabric:

  • 无状态服务Stateless service . 无状态服务不保留服务中的状态。A stateless service does not maintain state within the service. 如果需要状态持久性,则状态将写入并从外部存储中检索,如 Azure Cosmos DB。If state persistence is required, then state is written to and retrieved from an external store, such as Azure Cosmos DB.
  • 状态服务Stateful service . 服务状态保留在服务中。The service state is kept within the service itself. 大多数有状态服务通过 Service Fabric 的 可靠集合实现此。Most stateful services implement this through Service Fabric's Reliable Collections.

Service Fabric ExplorerService Fabric Explorer . Service Fabric Explorer 是用于检查和管理 Service Fabric 群集的开源工具。Service Fabric Explorer is an open-source tool for inspecting and managing Service Fabric clusters.

Azure PipelinesAzure Pipelines . 管道Azure DevOps Services 的一部分,它运行自动生成、测试和部署。Pipelines is part of Azure DevOps Services and runs automated builds, tests, and deployments. 也可以使用 Jenkins 等第三方 CI/CD 解决方案。You can also use third-party CI/CD solutions such as Jenkins.

Azure MonitorAzure Monitor . Azure Monitor 收集和存储指标和日志,包括解决方案和应用程序遥测中 Azure 服务的平台指标。Azure Monitor collects and stores metrics and logs, including platform metrics for the Azure services in the solution and application telemetry. 使用此数据可以监视应用程序、设置警报和仪表板,以及针对故障执行根本原因分析。Use this data to monitor the application, set up alerts and dashboards, and perform root cause analysis of failures. Azure Monitor 与 Service Fabric 集成,从控制器、节点和容器以及容器和节点日志中收集指标。Azure Monitor integrates with Service Fabric to collect metrics from controllers, nodes, and containers, as well as container and node logs.

Azure Key VaultAzure Key Vault . 使用 Key Vault 来存储微服务使用的任何应用程序机密,如连接字符串。Use Key Vault to store any application secrets used by the microservices, such as connection strings.

AZURE API 管理Azure API Management . 在此体系结构中, Api 管理 充当接受来自客户端的请求并将这些请求路由到服务的 api 网关。In this architecture, API Management acts as an API gateway that accepts requests from clients and routes them to your services.

设计注意事项Design considerations

此参考体系结构侧重于 微服务体系结构This reference architecture is focused on microservices architectures. 微服务是一个独立的小型代码单元。A microservice is a small, independently versioned unit of code. 它可通过服务发现机制发现,并可通过 Api 与其他服务进行通信。It is discoverable through service discovery mechanisms and can communicate with other services over APIs. 每个服务都是自包含服务,并且应实现单个业务功能。Each service is self-contained and should implement a single business capability. 有关如何将应用程序域分解为微服务的详细信息,请参阅 使用域分析来模拟微服务For more information about how to decompose your application domain into microservices, see Using domain analysis to model microservices.

Service Fabric 提供了一种高效构建、部署和升级微服务的基础结构。Service Fabric provides an infrastructure to build, deploy, and upgrade microservices efficiently. 它还提供自动缩放的选项,管理状态、监视运行状况,并在发生故障时重启服务。It also provides options for auto scaling, managing state, monitoring health, and restarting services in case of failure.

Service Fabric 遵循应用程序模型,其中应用程序是微服务的集合。Service Fabric follows an application model where an application is a collection of microservices. 应用程序 清单 文件中描述了应用程序,该文件定义了该应用程序中包含的不同类型的服务和指向独立服务包的指针。The application is described in an application manifest file that defines the different types of service contained in that application, and pointers to the independent service packages. 应用程序包通常还包含一些参数,这些参数用作服务所使用的某些设置的替代。The application package also usually contains parameters that serve as overrides for certain settings used by the services. 每个服务包都有一个清单文件,描述运行该服务所需的物理文件和文件夹,包括二进制文件、配置文件和该服务的只读数据。Each service package has a manifest file that describes the physical files and folders that are necessary to run that service, including binaries, configuration files, and read-only data for that service. 服务和应用程序独立进行版本控制和可升级。Services and applications are independently versioned and upgradable.

应用程序清单可以选择在创建应用程序实例时自动设置的服务。Optionally, the application manifest can describe services that are automatically provisioned when an instance of the application is created. 这些服务称为 "默认服务"。These are called default services. 在这种情况下,应用程序清单还介绍了如何创建这些服务,包括服务名称、实例计数、安全/隔离策略和放置约束。In this case, the application manifest also describes how these services should be created, including the service's name, instance count, security/isolation policy, and placement constraints.

备注

如果要控制服务的生存期,请避免使用默认服务。Avoid using default services if you want to control the life time of your services. 默认服务是在创建应用程序时创建的,并在应用程序运行时运行。Default services are created when the application is created, and run as long as the application is running.

有关了解 Service Fabric 的详细信息,请参阅 了解 Service Fabric?For more information about understanding Service Fabric, see So you want to learn about Service Fabric?

选择应用程序到服务的打包模型Choose an application-to-service packaging model

微服务的原则是可以独立部署每个服务。A tenet of microservices is that each service can be independently deployed. 在 Service Fabric 中,如果你将所有服务组合到一个应用程序包中,而一个服务未能升级,则整个应用程序升级会回滚,这会阻止其他服务升级。In Service Fabric, if you group all of your services into a single application package, and one service fails to upgrade, the entire application upgrade gets rolled back, which prevents other service from being upgraded.

因此,在微服务体系结构中,建议使用多个应用程序包。For that reason, in a microservices architecture, we recommend using multiple application packages. 将一个或多个密切相关的服务类型置于单个应用程序类型中。Put one or more closely related service types into a single application type. 如果你的团队负责一组运行时间相同且需要同时更新的服务,请具有相同的生命周期,或共享依赖项或配置等资源,然后将这些服务类型放在相同的应用程序类型中。If your team is responsible for a set of services that run for the same duration and need to be updated at the same time, have the same lifecycle, or share resources such as dependencies or configuration, then place those services types in the same application type.

Service Fabric 编程模型Service Fabric programming models

将微服务添加到 Service Fabric 应用程序时,应确定它的状态或数据是否具有高可用性和可靠性。When you add a microservice to a Service Fabric application, decide whether it has state or data that needs to be made highly available and reliable. 如果是,它是否可以将数据存储在外部,或者是作为服务的一部分包含的数据?If so, can it store data externally or is the data contained as part of the service? 如果不需要存储数据或希望将数据存储在外部存储中,请选择 "无状态服务"。Choose a stateless service if you don't need to store data or want to store data in external storage. 例如,如果你想要将状态或数据保留为服务的一部分 (例如,你需要数据驻留在接近代码) 的内存中,或者无法容忍对外部存储区的依赖项,请考虑选择有状态服务。If you want to maintain state or data as part of the service (for example, you need that data to reside in memory close to the code), or cannot tolerate a dependency on an external store, consider choosing a stateful service.

如果你有想要在 Service Fabric 上运行的现有代码,则可以将其作为可执行文件(作为服务运行的可执行文件)作为来宾可执行文件运行。If you have existing code that you want to run on Service Fabric, you can run it as a guest executable, which is an arbitrary executable that runs as a service. 或者,你可以将可执行文件打包到具有部署所需的所有依赖项的容器中。Alternatively, you can package the executable in a container that has all the dependencies needed for deployment. Service Fabric 将容器和来宾可执行文件作为无状态服务建模。Service Fabric models both containers and guest executables as stateless services. 有关选择模型的指南,请参阅 Service Fabric 编程模型概述For guidance about choosing a model, see Service Fabric programming model overview.

对于来宾可执行文件,您负责维护运行该程序的环境。With guest executables, you are responsible of maintaining the environment in which it runs. 例如,假设来宾可执行文件需要 Python。For example, suppose that a guest executable requires Python. 如果可执行文件不是自包含的,则需要确保在环境中预先安装了所需的 Python 版本。If the executable is not self-contained, you need to make sure that the required version of Python is pre-installed in the environment. Service Fabric 不管理环境。Service Fabric does not manage the environment. Azure 提供了多种机制来设置环境,包括自定义虚拟机映像和扩展。Azure offers multiple mechanisms to set up the environment, including custom virtual machine images and extensions.

若要通过反向代理访问来宾可执行文件,请确保已将 UriScheme 属性添加到来宾可执行文件的服务清单中的 终结点 元素。To access a guest executable through a reverse proxy, make sure you have added the UriScheme attribute to the Endpoint element in the guest executable's service manifest.

    <Endpoints>
      <Endpoint Name="MyGuestExeTypeEndpoint" Port="8090" Protocol="http" UriScheme="http" PathSuffix="api" Type="Input"/>
    </Endpoints>

如果服务具有其他路由,请在 PathSuffix 值中指定路由。If the service has additional routes, specify the routes in the PathSuffix value. 此值不应以 "/" 作为前缀或带有后缀。The value should not be prefixed or suffixed with '/'. 另一种方法是在服务名称中添加路由。Another way is to add the route in the service name.

    <Endpoints>
      <Endpoint Name="MyGuestExeTypeEndpoint" Port="8090" Protocol="http" PathSuffix="api" Type="Input"/>
    </Endpoints>

有关详细信息,请参阅:For more information, see:

API 网关API gateway

API 网关 (入口) 位于外部客户端与微服务之间。An API gateway (ingress) sits between external clients and the microservices. 它充当反向代理,将来自客户端的请求路由到微服务。It acts as a reverse proxy, routing requests from clients to microservices. 它还可以执行各种横切任务,例如身份验证、SSL 终止和速率限制。It may also perform various cross-cutting tasks such as authentication, SSL termination, and rate limiting.

大多数情况下,建议使用 Azure API 管理,但 Traefik 是一种常用的开源替代方法。Azure API Management is recommended for most scenarios, but Traefik is a popular open-source alternative. 这两种技术选项都与 Service Fabric 集成。Both technology options are integrated with Service Fabric.

  • API 管理公开公共 IP 地址并将流量路由到你的服务。API Management exposes a public IP address and routes traffic to your services. 它在与 Service Fabric 群集相同的虚拟网络中的专用子网中运行。It runs in a dedicated subnet in the same virtual network as the Service Fabric cluster. 它可以使用专用 IP 地址访问通过负载均衡器公开的节点类型的服务。It can access services in a node type that is exposed through a load balancer with a private IP address. 此选项仅在 API 管理的高级层和开发人员层中提供。This option is only available in the Premium and Developer tiers of API Management. 对于生产工作负荷,请使用 "高级" 层。For production workloads, use the Premium tier. 有关定价信息,请参阅 API 管理定价Pricing information is described in API Management pricing. 有关详细信息,请参阅 AZURE API 管理概述Service Fabric。For more information, see Service Fabric with Azure API Management overview.
  • Traefik 支持路由、跟踪、日志和指标等功能。Traefik supports features such as routing, tracing, logs, and metrics. Traefik 在 Service Fabric 群集中以无状态服务的形式运行。Traefik runs as a stateless service in the Service Fabric cluster. 可以通过路由支持服务版本控制。Service versioning can be supported through routing. 有关如何为服务入口设置 Traefik 以及作为群集中的反向代理的信息,请参阅 Azure Service Fabric 提供程序For information on how to set up Traefik for service ingress and as the reverse proxy within the cluster, see Azure Service Fabric Provider. 有关将 Traefik 与 Service Fabric 结合使用的详细信息,请参阅 Traefik Service Fabric 上的智能路由 (博客文章) 。For more information about using Traefik with Service Fabric, see Intelligent routing on Service Fabric with Traefik (blog post).

与 Azure API 管理不同,Traefik 不能使用多个分区) 来解析有状态服务 (的分区。Traefik, unlike Azure API Management, does not have functionality to resolve the partition of a stateful service (with more than one partition) to which a request is routed. 有关详细信息,请参阅 Add a 匹配程序 for 分区 servicesFor more information, see Add a matcher for partitioning services.

其他 API 管理选项包括 Azure 应用程序网关Azure 前门Other API management options include Azure Application Gateway and Azure Front Door. 这些服务可以与 API 管理一起使用,以执行路由、SSL 终止和防火墙等任务。These services can be used in conjunction with API Management to perform tasks such as routing, SSL termination, and firewall.

服务间通信Interservice communication

为了促进服务到服务的通信,请考虑使用 HTTP 作为通信协议。To facilitate service-to-service communication, consider using HTTP as the communication protocol. 在大多数情况下,我们建议使用 反向代理服务 进行服务发现。As a baseline for most scenarios, we recommend using the reverse proxy service for service discovery.

  • 通信协议。Communication protocol. 在微服务体系结构中,服务需要在运行时使用最小耦合来相互通信。In a microservices architecture, services need to communicate with each other with minimum coupling at runtime. 若要启用与语言无关的通信,HTTP 是一种行业标准,其中包含各种工具和 HTTP 服务器,这些工具和 HTTP 服务器以不同的语言提供,并 Service Fabric 支持。To enable language-agnostic communication, HTTP is an industry-standard with a wide range of tools and HTTP servers that are available in different languages, all supported by Service Fabric. 因此,对于大多数工作负荷,建议使用 HTTP 而不是 Service Fabric 的内置服务远程处理。Therefore, using HTTP instead of Service Fabric's built-in service remoting is recommended for most workloads.
  • 服务发现。Service discovery. 若要与群集中的其他服务进行通信,客户端服务需要解析目标服务的当前位置。To communicate with other services within a cluster, a client service needs to resolve the target service's current location. 在 Service Fabric 中,服务可以在节点之间移动,导致服务终结点动态更改。In Service Fabric, services can move between nodes, causing the service endpoints to change dynamically. 若要避免连接到陈旧终结点,可以使用 Service Fabric 的命名服务来检索更新的终结点信息。To avoid connections to stale endpoints, Service Fabric's Naming Service can be used to retrieve updated endpoint information. 不过,Service Fabric 还提供了一个用于提取命名服务的内置 反向代理服务However, Service Fabric also provides a built-in reverse proxy service that abstracts the naming service. 此选项更易于使用,并生成更简单的代码。This option is easier to use and results in simpler code.

服务间通信的其他选项包括Other options for interservice communication include,

  • Traefik 用于高级路由。Traefik for advanced routing.
  • 适用于服务需要使用 DNS 的兼容性方案的DNSDNS for compatibility scenarios where a service expects to use DNS.
  • Wcfcommunicationclient <TCommunicationClient > 类。ServicePartitionClient<TCommunicationClient> class. 类可缓存服务终结点,并可实现更好的性能,因为调用直接在没有中介或自定义协议的服务之间进行。The class caches service endpoints and can enable better performance, as calls go directly between services without intermediaries or custom protocols.

可伸缩性注意事项Scalability considerations

Service Fabric 支持缩放这些群集实体:Service Fabric supports scaling these cluster entities:

  • 缩放每个节点类型的节点数。Scaling the number of nodes for each node type.
  • 缩放服务。Scaling services.

本部分重点介绍自动缩放。This section is focused on autoscaling. 您可以选择在适当的情况下手动缩放。You can choose to manually scale in situations where appropriate. 例如,需要手动干预才能设置实例数。For example, a situation where manual intervention is required to set the number of instances.

可伸缩性的初始群集配置Initial cluster configuration for scalability

当你创建 Service Fabric 群集时,将根据你的安全和伸缩性需求来预配节点类型。When you create a Service Fabric cluster, provision the node types based on your security and scalability needs. 每个节点类型将映射到虚拟机规模集,并且可以独立缩放。Each node type is mapped to a virtual machine scale set and can be scaled independently.

  • 为每个具有不同的可伸缩性或资源要求的服务组创建节点类型。Create a node type for each group of services that have different scalability or resource requirements. 首先预配节点类型 (该节点类型成为 Service Fabric 系统服务) 的 主节点类型Start by provisioning a node type (which becomes the Primary node type) for the Service Fabric system services. 然后,创建单独的节点类型以运行公共或前端服务,并根据需要为后端和专用或隔离服务创建其他节点类型。Then create separate node types to run your public or front-end services, and other node types as necessary for your backend and private or isolated services. 指定 放置约束 ,以便仅将服务部署到预期节点类型。Specify placement constraints so that the services are only deployed to the intended node types.
  • 为每个节点类型指定持久性层。Specify the durability tier for each node type. 持久性层表示 Service Fabric 影响虚拟机规模集更新和维护操作的能力。The durability tier represents the ability for Service Fabric to influence virtual machine scale set updates and maintenance operations. 对于生产工作负荷,请选择 "白银" 或 "更高" 持久性层。For production workloads, choose the Silver or higher durability tier. 有关每个层的信息,请参阅 群集的持续性特性For information about each tier, see The durability characteristics of the cluster.
  • 如果使用青铜持久性层,某些操作需要手动步骤。If using the Bronze durability tier, certain operations require manual steps. 对于具有铜牌持续性层的节点类型,请在中进行缩放期间需要其他步骤。For node types with Bronze durability tier additional steps are required during scale in. 有关缩放操作的详细信息,请参阅 此指南For more information on scaling operations, see this guide.

缩放节点Scaling nodes

Service Fabric 支持放大和缩小的自动缩放。每个节点类型可以单独配置为自动缩放。Service Fabric supports autoscaling for scale-in and scale-out. Each node type can be configured for autoscaling independently.

每个节点类型最多可以有100个节点。Each node type can have a maximum of 100 nodes. 从一组较小的节点开始,根据负载添加更多节点。Start with a smaller set of nodes and add more nodes depending on your load. 如果某个节点类型中需要100个以上的节点,则需要添加更多节点类型。If you require more than 100 nodes in a node type, you will need to add more node types. 有关详细信息,请参阅 Service Fabric 群集容量规划注意事项For details, see Service Fabric cluster capacity planning considerations. 虚拟机规模集不会立即扩展,因此,在设置自动缩放规则时,请考虑此因素。A virtual machine scale set does not scale instantaneously, so consider that factor when you set up autoscale rules.

若要支持自动缩放,请将节点类型配置为具有 "白银" 或 "黄金" 持续性层。To support automatic scale-in, configure the node type to have the Silver or Gold durability tier. 这可以确保在 Service Fabric 完成重定位服务之前延迟中的缩放,并且虚拟机规模集通知 Service Fabric 已删除 Vm,而不是暂时关闭。This makes sure that scaling in is delayed until Service Fabric is finished relocating services and that the virtual machine scale sets inform Service Fabric that the VMs are removed, not just down temporarily.

有关在节点/群集级别进行缩放的详细信息,请参阅 缩放 Azure Service Fabric 群集For more information about scaling at the node/cluster level, see Scaling Azure Service Fabric clusters.

缩放服务Scaling services

无状态服务和有状态服务应用不同的缩放方法。Stateless and stateful services apply different approaches to scaling.

无状态服务的自动缩放Autoscaling for stateless services

  • 使用平均分区加载触发器。Use the average partition load trigger. 此触发器根据缩放策略中指定的负载阈值,确定何时将服务放大或缩小。This trigger determines when the service is scaled in or out, based on a load threshold value specified in the scaling policy. 还可以设置检查触发器的频率。You can also set how often the trigger is checked. 查看 基于实例的缩放的平均分区负载触发器See Average partition load trigger with instance-based scaling. 这允许您增加到可用节点数。This allows you to scale up to the number of available nodes.
  • 在服务清单中将 InstanceCount 设置为-1,这会告诉 Service Fabric 在每个节点上运行服务的实例。Set InstanceCount to -1 in the service manifest, which tells Service Fabric to run an instance of the service on every node. 此方法使服务能够在分类扩展时动态缩放。This approach enables the service to scale dynamically as the cluster scales. 当群集中的节点数发生变化时,Service Fabric 会自动创建和删除要匹配的服务实例。As the number of nodes in the cluster changes, Service Fabric automatically creates and deletes service instances to match.

备注

在某些情况下,你可能想要手动缩放你的服务。In some cases, you might want to manually scale your service. 例如,如果有从事件中心读取的服务,则可能希望从每个事件中心分区读取一个专用实例,以避免对分区的并行访问。For example, if you have a service that reads from Event Hubs, you might want a dedicated instance to read from each event hub partition, to avoid concurrent access to the partition.

为有状态服务缩放Scaling for stateful services

对于有状态服务,缩放由分区数、每个分区的大小以及在给定计算机上运行的分区/副本数来控制。For a stateful service, scaling is controlled by the number of partitions, the size of each partition, and the number of partitions/replicas running on a given machine.

  • 如果要创建分区服务,请确保每个节点都获得足够的副本,以便分配工作负荷,而不会导致资源争用。If you are creating partitioned services, make sure each node gets adequate replicas for even distribution of the workload without causing resource contentions. 如果添加了更多节点,则默认情况下 Service Fabric 将工作负荷分配到新计算机。If more nodes are added, Service Fabric distributes the workloads onto the new machines by default. 例如,如果有5个节点和10个分区,则默认情况下 Service Fabric 会将两个主副本放置在每个节点上。For example, if there are 5 nodes and 10 partitions, by default Service Fabric will place two primary replicas on each node. 如果横向扩展节点,则可以获得更高的性能,因为工作会均匀地分布到多个资源。If you scale out the nodes, you can achieve greater performance, because the work is evenly distributed across more resources. 有关利用此策略的方案的信息,请参阅 Service Fabric 中的缩放For information about scenarios that take advantage of this strategy, see Scaling in Service Fabric.
  • 不支持添加或删除分区。Adding or removing partitions is not well supported. 通常用于缩放的另一种方法是动态创建或删除服务或整个应用程序实例。Another option commonly used to scale is to dynamically create or delete services or whole application instances. 通过创建或删除新命名服务进行缩放中描述了该模式的示例。An example of that pattern is described in Scaling by creating or removing new named services.

有关详细信息,请参阅:For more information, see:

使用度量值平衡负载Using metrics to balance load

根据您设计分区的方式,可能会有具有获得更多流量的副本的节点。Depending on how you design the partition, you might have nodes with replicas that get more traffic than others. 若要避免这种情况,请将服务状态分区,以便将其分发到所有分区。To avoid this situation, partition the service state so that it is distributed across all partitions. 使用有效的哈希算法的范围分区方案。Use the range partitioning scheme with a good hash algorithm. 请参阅 分区入门See Get started with partitioning.

Service Fabric 使用指标来了解如何在群集中放置和平衡服务。Service Fabric uses metrics to know how to place and balance services within a cluster. 你可以在创建服务时为与服务关联的每个指标指定默认负载。You can specify a default load for each metric associated with a service when that service is created. 然后,Service Fabric 在放置服务时,或每当服务需要移动 (例如,在升级期间) 尝试平衡群集中的节点。Service Fabric then takes that load into account when placing the service, or whenever the service needs to move (for example, during upgrades) to try to balance the nodes in the cluster.

最初指定的服务默认负载将在服务的生存期内不会更改。The initially specified default load for a service will not change over the lifetime of the service. 为了捕获给定服务的变化指标,建议你监视服务,然后动态报告负载。To capture changing metrics for a given service, we recommend that you monitor your service and then report the load dynamically. 这允许 Service Fabric 根据在给定时间报告的负载调整分配。This allows Service Fabric to adjust the allocation based on the reported load at a given time. 使用 iservicepartition.reportpartitionhealth 来. reportload 等 方法报告自定义指标。Use the IServicePartition.ReportLoad method to report custom metrics. 有关详细信息,请参阅 动态负载For more information, see Dynamic load.

可用性注意事项Availability considerations

将服务置于主节点类型之外的节点类型中。Place your services in a node type other than the primary node type. Service Fabric 系统服务始终部署到主节点类型。The Service Fabric system services are always deployed to the primary node type. 如果将服务部署到主节点类型,则它们可能会与系统服务争用资源并干扰系统服务。If your services are deployed to the primary node type, they might compete with system services for resources and interfere with the system services. 如果某个节点类型需要托管有状态服务,请确保至少有5个节点实例,并选择 "白银" 或 "黄金" 持续性层。If a node type is expected to host stateful services, make sure there are at least five node instances and you select the Silver or Gold Durability tier.

请考虑约束服务的资源。Consider constraining the resources of your services. 请参阅 资源调控机制See Resource governance mechanism.

  • 不要将资源控制和资源非管控服务混合在同一节点类型上。Do not mix resource governed and resource non-governed services on the same node type. 非管控服务可能会消耗过多的资源,从而影响资源管控服务。The non-governed services might consume too many resources, affecting the resource governed services. 指定 放置约束 可以确保这些类型的服务不会在同一组节点上运行。Specify placement constraints to make sure that those types of services do not run on the same set of nodes. 请参阅 指定资源调控See Specify resource governance. (这是 Bulkhead 模式的示例 ) (This is an example of the Bulkhead pattern.)
  • 指定要为服务实例预留的 CPU 内核和内存。Specify the CPU cores and memory to reserve for a service instance. 有关资源调控策略的使用情况和局限性的信息,请参阅 资源调控For information about usage and limitations of resource governance policies, see Resource governance.

请确保每个服务的目标实例或副本计数大于1,以避免单点故障 (SPOF) 。Make sure every service's target instance or replica count is greater than 1 to avoid a single point of failure (SPOF). 可用作服务实例或副本计数的最大数等于服务所约束到的节点数。The largest number that you can use as service instance or replica count equals the number nodes that to which the service is constrained.

请确保每个有状态服务至少有两个活动辅助副本。Make sure every stateful service has at least two active secondary replicas. 建议为生产工作负荷使用5个副本。Five replicas are recommended for production workloads.

有关详细信息,请参阅 Service Fabric 服务的可用性For more information, see Availability of Service Fabric services.

安全注意事项Security considerations

下面是在 Service Fabric 保护应用程序的一些要点:Here are some key points for securing your application on Service Fabric:

虚拟网络Virtual network

考虑为每个虚拟机规模集定义子网边界,以控制通信流。Consider defining subnet boundaries for each virtual machine scale set to control the flow of communication. 每个节点类型在 Service Fabric 群集的虚拟网络中的子网中都有其自己的虚拟机规模集。Each node type has its own virtual machine scale set in a subnet within the Service Fabric cluster's virtual network. 可以将 (Nsg) 的网络安全组添加到子网,以允许或拒绝网络流量。Network Security Groups (NSGs) can be added to the subnets to allow or reject network traffic. 例如,对于前端和后端节点类型,可以将 NSG 添加到后端子网,只接受前端子网的入站流量。For example, with front-end and back-end node types, you can add an NSG to the backend subnet to accept inbound traffic only the front-end subnet.

从群集调用外部 Azure 服务时,如果 Azure 服务支持,则使用 虚拟网络服务终结点When calling external Azure Services from the cluster, use Virtual Network service endpoints if the Azure service supports it. 使用服务终结点仅保护群集的虚拟网络的服务。Using a service endpoint secures the service to only the cluster's Virtual Network. 例如,如果使用 Cosmos DB 存储数据,请使用服务终结点配置 Cosmos DB 帐户,以便仅允许来自特定子网的访问。For example, if you are using Cosmos DB to store data, configure the Cosmos DB account with a service endpoint to allow access only from a specific subnet. 请参阅 从虚拟网络访问 Azure Cosmos DB 资源See Access Azure Cosmos DB resources from virtual networks.

终结点和服务间通信Endpoints and interservice communication

请勿创建不安全的 Service Fabric 群集。Do not create an unsecured Service Fabric cluster. 如果群集向公共 internet 公开管理终结点,则匿名用户可以连接到该终结点。If the cluster exposes management endpoints to the public internet, anonymous users can connect to it. 不支持将不安全群集用于生产工作负荷。Unsecured clusters are not supported for production workloads. 请参阅: Service Fabric 群集安全方案See: Service Fabric cluster security scenarios.

保护你的服务间通信:To secure your interservice communications:

  • 请考虑在 ASP.NET Core 或 Java web 服务中启用 HTTPS 终结点。Consider enabling HTTPS endpoints in your ASP.NET Core or Java web services.
  • 在反向代理和服务之间建立安全连接。Establish a secure connection between the reverse proxy and services. 有关详细信息,请参阅 连接到安全服务For details, see Connect to a secure service.

如果你使用的是 API 网关,则可以将 身份验证卸载 到网关。If you are using an API gateway, you can offload authentication to the gateway. 请确保在没有 API 网关的情况下,不能直接访问单个服务 () 除非已设置了额外的安全性,以便对消息进行身份验证是否来自网关。Make sure that the individual services cannot be reached directly (without the API gateway) unless additional security is in place to authenticate messages whether they come from the gateway.

不要公开 Service Fabric 反向代理。Do not expose the Service Fabric reverse proxy publicly. 这样做会导致公开 HTTP 终结点的所有服务都可从群集外部进行寻址,引入安全漏洞,并可能不必要地泄露群集之外的其他信息。Doing so causes all services that expose HTTP endpoints to be addressable from outside the cluster, introducing security vulnerabilities and potentially exposing additional information outside the cluster unnecessarily. 如果要公开访问服务,请使用 API 网关。If you want to access a service publicly, use an API gateway. API 网关部分中提到了某些选项。Some options are mentioned in the API gateway section.

远程桌面对于诊断和故障排除非常有用,但请确保不将其保持打开状态,否则会导致安全漏洞。Remote desktop is useful for diagnostic and troubleshooting, but make sure not to leave it open otherwise it causes a security hole.

机密和证书Secrets and certificates

将机密(如连接字符串)存储到 Azure Key Vault 中的数据存储。Store secrets such as connection strings to data stores in Azure Key Vault. Key Vault 必须与虚拟机规模集位于同一区域。The Key Vault must be in the same region as the virtual machine scale set. 你将需要:You will need to:

  • 验证服务对 Key Vault 的访问。Authenticate the service's access to the Key Vault.

    在托管服务的虚拟机规模集上启用 托管标识Enable managed identity on the virtual machine scale set that hosts the service.

  • 将你的机密存储在 Key Vault 中。Store your secrets in the Key Vault.

    添加可以转换为键值对的格式的机密。Add secrets in a format that can be translated to a key-value pair. 例如,CosmosDB--AuthKey。For example, CosmosDB--AuthKey. 构建配置时,"--" 将转换为 ":"。When the configuration is built, "--" is converted into ":".

  • 在您的服务中访问这些机密。Access those secrets in your service.

    在的 appSettings.js中添加 Key Vault URI。Add the Key Vault URI in your appSettings.json. 在您的服务中,添加从 Key Vault 读取的配置提供程序、生成配置,并从生成的配置访问机密。In your service, add the configuration provider that reads from the Key Vault, builds the configuration, and accesses the secret from the built configuration.

下面是一个示例,其中的工作流服务以 "CosmosDB--Database" 格式将机密存储在 Key Vault 中。Here's an example where the Workflow service stores a secret in the Key Vault in the format "CosmosDB--Database".

namespace Fabrikam.Workflow.Service
{
    public class ServiceStartup
    {
        public static void ConfigureServices(StatelessServiceContext context, IServiceCollection services)
        {
            var preConfig = new ConfigurationBuilder()
                …
                .AddJsonFile(context, "appsettings.json");

            var config = preConfig.Build();

            if (config["AzureKeyVault:KeyVaultUri"] is var keyVaultUri && !string.IsNullOrWhiteSpace(keyVaultUri))
            {
                preConfig.AddAzureKeyVault(keyVaultUri);
                config = preConfig.Build();
            }
    }
}

若要访问该机密,请在生成的配置中指定该机密名称。To access the secret, specify the secret name in the built config.

       if(builtConfig["CosmosDB:Database"] is var database && !string.IsNullOrEmpty(database))
       {
            // Use the secret.
       }

不要使用客户端证书访问 Service Fabric Explorer。Do not use client certificates to access Service Fabric Explorer. 请改用 Azure Active Directory (Azure AD) 。Instead, use Azure Active Directory (Azure AD). 另请参阅 支持 Azure AD 身份验证的 Azure 服务Also see, Azure services that support Azure AD authentication.

不要使用自签名证书进行生产。Do not use self-signed certificates for production.

静态数据保护Data at rest protection

如果已将数据磁盘附加到 Service Fabric 群集的虚拟机规模集,并且服务将数据保存在这些磁盘上,则必须对磁盘进行加密。If you have attached data disks to the virtual machine scale sets of the Service Fabric cluster and your services save data on those disks, you must encrypt the disks. 有关详细信息,请参阅 使用 Azure PowerShell (Preview) 在虚拟机规模集中加密 OS 和附加的数据磁盘 For more information, see Encrypt OS and attached data disks in a virtual machine scale set with Azure PowerShell (Preview).

有关保护 Service Fabric 的详细信息,请参阅:For more information about securing Service Fabric, see:

复原注意事项Resiliency considerations

若要从故障中恢复并维护完全正常的状态,应用程序必须实现某些复原模式。To recover from failures and maintain a fully functioning state, the application must implement certain resiliency patterns. 下面是一些常见模式:Here are some common patterns:

  • 重试模式:处理应为暂时性的错误,例如资源暂时不可用。Retry pattern: To handle errors that are expected to be transient, such as resources being temporarily unavailable.
  • 断路器:用于解决可能需要更长时间才能解决的故障。Circuit breaker: To address faults that might need longer to fix.
  • Bulkhead 模式:隔离每个服务的资源。Bulkhead pattern: To isolate resources per service.

此引用实现使用 Polly(一个开源选项)来实现所有这些模式。This reference implementation uses Polly, an open-source option, to implement all of those patterns.

监视注意事项Monitoring considerations

在浏览监视选项之前,我们建议阅读有关 Service Fabric 的诊断常见方案的文章。Before you explore the monitoring options, we recommend you read this article about diagnosing common scenarios with Service Fabric. 可以考虑在以下集中监视数据:You can think of monitoring data in these sets:

下面是用于分析该数据的两个主要选项:These are the two main options for analyzing that data:

  • Application InsightsApplication Insights
  • Log AnalyticsLog Analytics

您可以使用 Azure Monitor 设置仪表板以进行监视,并向操作员发送警报。You can use Azure Monitor to set up dashboards for monitoring and to send alerts to operators. 还有一些与 Service Fabric 集成的第三方监视工具,例如 Dynatrace。There are also some third-party monitoring tools that are integrated with Service Fabric, such as Dynatrace. 有关详细信息,请参阅 Azure Service Fabric 监视合作伙伴For details, see Azure Service Fabric Monitoring Partners.

应用程序指标和日志Application metrics and logs

应用程序遥测提供有关服务的数据,可帮助你监视服务的运行状况并确定问题。Application telemetry provides data about your service that can help you monitor the health of your service and identify issues. 若要在服务中添加跟踪和事件:To add traces and events in your service:

  • 如果你正在通过 ASP.NET Core 开发服务,则为 " Microsoft "。Microsoft.Extensions.Logging if you are developing your service with ASP.NET Core. 对于其他框架,请使用所选的日志记录库,如 Serilog。For other frameworks, use a logging library of your choice such as Serilog.
  • 您可以使用 SDK 中的 TelemetryClient 类添加自己的检测,并在 Application Insights 中查看数据。You can add your own instrumentation by using the TelemetryClient class in the SDK and view the data in Application Insights. 请参阅 将自定义检测添加到应用程序See Add custom instrumentation to your application.
  • 使用 EventSource记录 ETW 事件。Log ETW events by using EventSource. 默认情况下,此选项在 Visual Studio Service Fabric 解决方案中可用。This option is available by default in a Visual Studio Service Fabric solution.

Application Insights 提供了许多内置遥测:请求、跟踪、事件、异常、指标、依赖项。Application Insights provides a lot of built-in telemetry: requests, traces, events, exceptions, metrics, dependencies. 如果服务公开 HTTP 终结点,请通过调用 AspNetCore.useapplicationinsights 扩展方法来启用 Application Insights。If your service exposes HTTP endpoints, enable Application Insights by calling the UseApplicationInsights extension method for Microsoft.AspNetCore.Hosting.IWebHostBuilder. 有关检测服务 Application Insights 的信息,请参阅以下文章:For information about instrumenting your service for Application Insights, see these articles:

若要查看跟踪和事件日志,请使用 Application Insights 作为结构化日志记录的接收器之一。To view the traces and event logs, use Application Insights as one of sinks for structured logging. 通过调用 AddApplicationInsights 扩展方法,使用检测密钥配置 Application Insights。Configure Application Insights with your instrumentation key by calling the AddApplicationInsights extension method. 在此示例中,检测密钥在 Key Vault 中存储为机密。In this example, the instrumentation key is stored as a secret in the Key Vault.

    .ConfigureLogging((hostingContext, logging) =>
        {
            logging.AddApplicationInsights(hostingContext.Configuration ["ApplicationInsights:InstrumentationKey"]);
        })

如果服务未公开 HTTP 终结点,则需要编写一个自定义扩展插件,该扩展将跟踪发送到 Application Insights。If your service does not expose HTTP endpoints, you need to write a custom extension that sends traces to Application Insights. 有关示例,请参见参考实现中的工作流服务。For an example, see the Workflow service in the reference implementation.

ASP.NET Core services 使用 ILogger 接口 进行应用程序日志记录。ASP.NET Core services use the ILogger interface for application logging. 若要使这些应用程序日志在 Azure Monitor 中可用,请将 ILogger 事件发送到 Application Insights。To make these application logs available in Azure Monitor, send the ILogger events to Application Insights. 有关详细信息,请参阅 ILogger in a ASP.NET Core 应用程序For more information, see ILogger in an ASP.NET Core application. Application Insights 可以将相关属性添加到 ILogger 事件,用于可视化分布式跟踪。Application Insights can add correlation properties to ILogger events, useful for visualizing distributed tracing.

有关详细信息,请参阅:For more information, see:

Service Fabric 运行状况和事件数据Service Fabric health and event data

Service Fabric 遥测包括 Service Fabric 群集及其实体的操作和性能的运行状况指标和事件:其节点、应用程序、服务、分区和副本。Service Fabric telemetry includes health metrics and events about the operation and performance of a Service Fabric cluster and its entities: its nodes, applications, services, partitions, and replicas.

  • EventStoreEventStore. 收集与群集及其实体相关的事件的有状态系统服务。A stateful system service that collects events related to the cluster and its entities. Service Fabric 使用 EventStore 写入 Service Fabric 事件 以提供有关群集的信息,并可用于状态更新、故障排除和监视。Service Fabric uses EventStore to write Service Fabric events to provide information about your cluster and can be used for status updates, troubleshooting, monitoring. 它还可以在给定时间关联来自不同实体的事件,以确定群集中的问题。It can also correlate events from different entities at a given time to identify issues in the cluster. 服务通过 REST API 公开这些事件。The service exposes those events through a REST API. 有关如何查询 EventStore Api 的信息,请参阅 查询群集事件的 EventStore apiFor information about how to query the EventStore APIs, see Query EventStore APIs for cluster events. 可以通过使用 WAD 扩展配置群集,在 Log Analytics 中查看来自 EventStore 的事件。You can view the events from EventStore in Log Analytics by configuring your cluster with WAD extension.
  • HealthStoreHealthStore. 提供群集的当前运行状况的快照。Provides a snapshot of the current health of the cluster. 一种有状态服务,用于聚合由层次结构中的实体报告的所有运行状况数据。A stateful service that aggregates all health data reported by entities in a hierarchy. 数据在 Service Fabric Explorer中进行可视化。The data is visualized in Service Fabric Explorer. HealthStore 还监视应用程序升级。The HealthStore also monitors application upgrades. 可以在 PowerShell、.NET 应用程序或 REST Api 中使用运行状况查询。You can use health queries in PowerShell, a .NET application, or REST APIs. 请参阅 Service Fabric health Monitoring 简介See, Introduction to Service Fabric health monitoring.
  • 请考虑实现内部自定义监视程序服务。Consider implementing internal custom watchdog services. 这些服务可以定期报告自定义运行状况数据,如运行中服务的错误状态。Those services can periodically report custom health data such as faulty states of running services. 有关详细信息,请参阅 自定义运行状况报告For more information, see Custom health reports. 您可以使用 Service Fabric 资源管理器读取运行状况报告。You can read the health reports using the Service Fabric explorer.

基础结构指标和日志Infrastructure metrics and logs

基础结构指标有助于了解群集中的资源分配。Infrastructure metrics help you to understand resource allocation in the cluster. 下面是收集此信息的主要选项:Here are the main options for collecting this information:

  • Windows Azure 诊断 (WAD) 。Windows Azure Diagnostics (WAD). 在 Windows 上的节点级别收集日志和指标。Collect logs and metrics at the node level on Windows. 可以通过在映射到节点类型的任何虚拟机规模集上配置 IaaSDiagnostics VM 扩展来使用 WAD,以便收集诊断事件,如 Windows 事件日志、性能计数器、ETW/清单系统和操作事件以及自定义日志。You can use WAD by configuring the IaaSDiagnostics VM extension on any virtual machine scale set that is mapped to a node type to collect diagnostic events, such as Windows event logs, performance counters, ETW/manifests system and operational events, and custom logs.
  • Log Analytics 代理。Log Analytics agent. 配置 MicrosoftMonitoringAgent VM 扩展,以便将 Windows 事件日志、性能计数器和自定义日志发送到 Log Analytics。Configure the MicrosoftMonitoringAgent VM extension to send Windows event logs, performance counters, and custom logs to Log Analytics.

通过前面的机制(例如性能计数器)收集的指标类型存在一些重叠。There is some overlap in the type of metrics collected through the preceding mechanisms, such as performance counters. 如果存在重叠,建议使用 Log Analytics 代理。Where there is overlap, we recommend using the Log Analytics agent. 由于没有适用于 Log Analytics 代理的 Azure 存储空间,因此延迟较低。Because there is no Azure storage for the Log Analytics agent, there is low latency. 此外,无法轻松地将 IaaSDiagnostics 中的性能计数器送入 Log Analytics。Also, the performance counters in IaaSDiagnostics cannot be fed into Log Analytics easily.

Service Fabric 中的基础结构监视

有关使用 VM 扩展的信息,请参阅 Azure 虚拟机扩展和功能For information about using VM extensions, see Azure virtual machine extensions and features.

若要查看数据,请配置 Log Analytics 以查看通过 WAD 收集的数据。To view the data, configure Log Analytics to view the data collected through WAD. 有关如何配置 Log Analytics 从存储帐户读取事件的信息,请参阅 设置群集的 Log AnalyticsFor information about how to configure Log Analytics to read events from a storage account, see Set up Log Analytics for a cluster.

还可以查看与 Service Fabric 群集、工作负荷、网络流量、待定更新等相关的性能日志和遥测数据。You can also view performance logs and telemetry data related to a Service Fabric cluster, workloads, network traffic, pending updates, and more. 请参阅 性能监视 Log AnalyticsSee Performance Monitoring with Log Analytics.

Log Analytics 服务映射解决方案 提供有关群集的拓扑的信息 (也就是说,每个节点中运行的进程) 。Service Map solution in Log Analytics provides information about the topology of the cluster (that is, the processes running in each node). 将存储帐户中的数据发送到 Application InsightsSend the data in the storage account to Application Insights. 将数据引入 Application Insights 可能会有一些延迟。There might be some delay in getting data into Application Insights. 如果要实时查看数据,请考虑使用接收器和通道配置 事件中心If you want to see the data real time, consider configuring Event Hub using sinks and channels. 有关详细信息,请参阅 使用 Windows Azure 诊断的事件聚合和集合For more information, see Event aggregation and collection using Windows Azure Diagnostics.

从属服务指标Dependent service metrics

  • Application Insights 应用程序映射 通过使用在服务之间进行的 HTTP 依赖项调用,以及安装的 Application Insights SDK 来提供应用程序的拓扑。Application Insights Application Map provides the topology of the application by using HTTP dependency calls made between services, with the installed Application Insights SDK.
  • Log Analytics 中的服务映射解决方案 提供有关来自/到外部服务的入站和出站流量的信息。Service Map solution in Log Analytics provides information about inbound and outbound traffic from/to external services. 此外,服务映射与其他解决方案集成,例如更新或安全。In addition, Service Map integrates with other solutions such as updates or security.
  • 自定义监视器可用于报告有关外部服务的错误条件。Custom watchdogs can be used to report error conditions on external services. 例如,如果服务无法访问外部服务或数据存储 (Azure Cosmos DB) ,则该服务可以报告错误运行状况报告。For example, the service could report an error health report if it cannot access an external service or data storage (Azure Cosmos DB).

分布式跟踪Distributed tracing

在微服务体系结构中,有几项服务经常参与完成任务。In microservices architecture, several services often participate to complete a task. 其中每个服务的遥测通过使用上下文字段进行关联, (操作 ID、请求 ID 等) 分布式跟踪。The telemetry from each of those services is correlated by using context fields (operation ID, request ID, and so forth) in a distributed trace. 通过使用 Application Insights 中的 应用程序映射 ,可以生成分布式逻辑操作的视图,并使应用程序的整个服务图形可视化。By using Application Map in Application Insights, you can build the view of distributed logical operation and visualize the entire service graph of your application. 你还可以使用 Application insights 中的事务诊断来关联服务器端遥测。You can also use transaction diagnostics in Application Insight to correlate server-side telemetry. 有关详细信息,请参阅 统一跨组件事务诊断For more information, see Unified cross-component transaction diagnostics.

Application Insights 应用程序映射 通过使用在服务之间进行的 HTTP 依赖项调用,以及安装的 Application Insights SDK 来提供应用程序的拓扑。Application Insights Application Map provides the topology of the application by using HTTP dependency calls made between services, with the installed Application Insights SDK. 关联使用队列异步调度的任务也很重要。It's also important to correlate tasks that are dispatched asynchronously using a queue. 有关在队列消息中发送相关遥测数据的详细信息,请参阅 队列检测For details about sending correlation telemetry in a queue message, see Queue instrumentation.

有关详细信息,请参阅:For more information, see:

警报和仪表板Alerts and Dashboards

Application Insights 和 Log Analytics 支持 (Kusto 查询语言) 的 广泛查询 语言,可用于检索和分析日志数据。Application Insights and Log Analytics support an extensive query language (Kusto query language) that lets you retrieve and analyze log data. 使用查询来创建数据集,并在诊断仪表板中将其可视化。Use the queries to create data sets and visualize it in diagnostics dashboards.

当特定的资源中出现特定情况时,请使用 Azure Monitor 警报来通知 sysadmin。Use Azure Monitor alerts to notify sysadmins when certain conditions occur in specific resources. 通知可以是电子邮件、Azure 函数、呼叫 web 挂钩等。The notification could be an email, Azure function, call a web hook, and so on. 有关详细信息,请参阅 Azure Monitor 中的警报For more information, see Alerts in Azure Monitor.

日志搜索警报规则 允许定期定义和运行针对 Log Analytics 工作区的 Kusto 查询。Log search alert rules allow you to define and run a Kusto query against a Log Analytics workspace at regular intervals. 如果查询结果符合特定条件,则会创建警报。An alert is created if the query result matches a certain condition.

成本注意事项Cost considerations

使用 Azure 定价计算器估算成本。Use the Azure pricing calculator to estimate costs. 其他注意事项,请参阅 Microsoft Azure Well-Architected 框架的 "成本" 部分。Other considerations are described in the Cost section in Microsoft Azure Well-Architected Framework.

对于此体系结构中使用的某些服务,以下是一些需要考虑的事项。Here are some points to consider for some of the services used in this architecture.

Azure Service FabricAzure Service Fabric

创建 Service Fabric 群集时,需要支付你选择的计算实例、存储、网络资源和 IP 地址。You are charged for the compute instances, storage, networking resources, and IP addresses you choose when creating a Service Fabric cluster. Service Fabric 的部署费用。There are deployment charges for Service Fabric.

虚拟机规模集Virtual machine scale sets

在此体系结构中,微服务部署到作为虚拟机规模集的节点。In this architecture, the microservices are deployed into nodes that are virtual machine scale sets. 需要为作为群集的一部分部署的 Azure Vm 以及存储和网络等底层基础结构资源付费。You are charged for the Azure VMs that are deployed as part of the cluster and underlying infrastructure resources, such as storage and networking. 虚拟机规模集服务无增量收费。There are no incremental charges for the virtual machine scale sets service.

Azure API 管理 (APIM) Azure API Management (APIM)

APIM 用作将请求从客户端路由到群集中服务的网关。APIM is used as a gateway to route the requests from clients to your services in the cluster.

定价选项各不相同。There are different pricing options. " 消耗 " 选项按使用付费计费,并包含网关组件。The Consumption option is charged on a pay-per-use basis and includes a gateway component. 根据工作负荷,选择 Api 管理定价中所述的选项。Based on your workload, choose an option described in Api Management pricing.

Azure Application InsightsAzure Application Insights

Application insights 用于收集所有服务的遥测数据,还可通过结构化方式查看跟踪和事件日志。Application insights is used for collect telemetry for all services and also to view the traces and event logs in a structured way. Azure Application Insights 采用基于引入的数据量(还可以选择用于更长的数据保留期)的即用即付模型。The pricing for Azure Application Insights is a Pay-As-You-Go model based on data volume ingested and optionally for longer data retention. 有关详细信息,请参阅 管理 Application Insights 的使用情况和成本For more information, see Manage Usage and Cost For Application Insights.

Azure MonitorAzure Monitor

对于 Azure Monitor Log Analytics,需要为数据引入和保留付费。For Azure Monitor Log Analytics, you are charged for data ingestion and retention. 有关详细信息,请参阅 Azure Monitor 定价For more information, see Azure Monitor Pricing for more information.

Azure Key VaultAzure Key Vault

Azure Key Vault 用于将 Application insights 的检测密钥存储为机密。Azure Key Vault is used to store the Application Insight's instrumentation key as a secret. Azure Key Vault 在两个服务层中提供。Azure Key Vault is offered in two service tiers. 如果不需要 HSM 保护的密钥,请选择 " 标准 "。If you don't need HSM-protected keys, choose the Standard . 有关每个层中的功能的信息,请参阅 Key Vault 定价For information about the features in each tier, see Key Vault pricing.

Azure DevOps ServicesAzure DevOps Services

此参考体系结构仅使用 Azure Pipelines。This reference architecture only uses Azure Pipelines. Azure 以单个服务的形式提供 Azure 管道。Azure offers the Azure Pipeline as an individual Service. 对于 CI/CD 和每月无限制分钟的每月每月1800分钟,会允许免费的 Microsoft 托管作业You are allowed a free Microsoft-hosted job with 1,800 minutes per month for CI/CD and one self-hosted job with unlimited minutes per month, extra jobs have charges. 有关详细信息,请参阅 Azure DevOps Services 定价For more information, see Azure DevOps Services Pricing.

DevOps 注意事项DevOps considerations

Azure PipelinesAzure Pipelines

使用 Azure Pipelines 部署引用实现。The reference implementation is deployed using Azure Pipelines. 有关微服务体系结构中的 DevOps 注意事项,请参阅 CI/CD for 微服务For DevOps considerations in a microservices architecture, see CI/CD for microservices

你还可以在本 教程中了解如何使用 CI/CD 将容器应用程序部署到 Service Fabric 群集。You can also learn how to deploy a container application with CI/CD to a Service Fabric cluster, in this tutorial.

部署解决方案Deploy the solution

若要部署此体系结构的引用实现,请按照 GitHub存储库中的步骤进行操作。To deploy the reference implementation for this architecture, follow the steps in the GitHub repo.

后续步骤Next steps