什么是 Azure Service Fabric?
我们先从几个定义入手,并快速了解 Azure Service Fabric。 本概述有助于确定 Service Fabric 是否适合分布式计算解决方案。
什么是容器?
容器是软件的原子单元,将应用程序及其所有依赖项(如库和配置文件)包装到其自己的独立环境中,其中包括在该环境中运行软件所需的所有内容。 容器直接在内核顶层运行,在文件系统与其他资源之间界定了范围。 容器内部的应用程序不知道容器外部的其他任何应用程序或进程。
为何使用容器?
容器模型具有以下优势:
小:容器使用单个存储空间和层的版本与更新,提高了效率。
快:容器无需启动整个操作系统,因此启动速度更快,通常只需几秒。
可移植性:容器化的应用程序映像可以移植到云中或本地运行、移植到虚拟机中运行,或者直接在物理计算机上运行。
资源监管:容器可以限制可在其主机上消耗的物理资源。
如何管理容器?
容器业务流程是帮助管理员使用容器管理环境的软件的一般术语。 管理员输入环境的所需状态,例如正在运行的某个服务的五个副本。 然后,业务流程协调程序尝试使环境与所需状态匹配。 达到所需状态后,业务流程协调程序会尝试维护该状态。 如果其中一个服务失败,则业务流程协调程序会尝试部署新副本。
大多数业务流程协调程序做的不仅仅是处理初始部署和失败情况。 它们还可以处理升级并解决资源消耗和治理问题。
容器业务流程从根本上讲是在环境中实现和维护一些所需的配置状态。
群集资源管理器是在 Service Fabric 中处理业务流程的系统组件。
什么是微服务?
微服务应用程序和微服务体系结构是指小型、独立、松散耦合的服务,这些服务协同工作以实现结果。
服务可以完全独立于彼此进行开发,它们使用不同的技术堆栈、库和框架。 可以独立部署服务,因此可以更新体系结构的组件,而无需重新部署整个应用程序。 服务负责保存自己的数据。 服务使用定义完善的 API 进行通信,并且彼此的内部实现是无关的。
为何使用微服务?
微服务模型具有以下优势:
敏捷性:微服务独立部署,减少了发布功能的复杂性。 无需重新部署整个应用程序即可更新服务。
故障隔离:如果单个微服务不可用,它不会中断整个应用程序,但前提是上游微服务能够正确处理故障。
可伸缩性:服务可独立扩展,这样你就能扩展需要更多资源的子系统,而无需扩展整个应用程序。 可以看到这非常适合容器和容器业务流程模型。
数据隔离:架构更新更简单,因为只有单个微服务受到影响。
什么是无状态和有状态服务?
在无状态服务中,每个请求和答复可以单独理解。 可以想象一个简单的计算器服务,你可在其中发送要执行的计算(比如 2+2)并收到一个答案 (4)。 如果想要对该结果执行其他计算(比如 4 x 2),则可以手动发送请求以计算 4 x 2 并收到 8。 但是,服务不会意识到你使用的是初始计算的结果。
在有状态服务中,每个请求和答复都放入服务了解并可以引用的事务历史记录。 再以计算器服务为例,但这次是针对有状态版本。 请求执行计算 2+2,并且收到 4。 这一次,请求服务将上一个结果乘以 2(假设语法类似于 Answer x 2)。 结果收到 8,就像第一个示例中的那样。 但是这一次,计算器服务知道前一个事务 (Answer) 的结果为 4。
什么使用无状态和有状态服务?
解决方案可以使用无状态服务、有状态服务或两者。
选择哪个取决于应用程序的需求。 如果需要在会话之间保留服务的状态,则需要有状态服务。 如果服务不需要保留状态,或者可以依赖外部存储来保留其状态,则可以使用无状态服务。
使用微服务体系结构,可以将无状态服务和有状态服务混在一起。 微服务是独立的,可以使用完全不同的技术堆栈,因此你可以设计成一些服务要求保留状态,而有些则不需要。
什么是 Azure Service Fabric?
Azure Service Fabric 管理分布式计算系统,并使得部署和管理容器化应用程序、实现微服务体系结构以及使用可靠的有状态服务和无状态服务变得简单。 Service Fabric 提供开发和操作工具,支持各种编程模型、容器业务流程、群集运行状况和监视、自动缩放等。
Service Fabric 提供两种不同的群集模型,具体取决于你的偏好。 标准群集模型要求管理群集的所有基础资源。 托管群集模型将这些资源抽象化,而 Azure 会管理它们。
可以在 Azure 门户或使用 Azure 资源管理器 模板创建群集。