横向扩展英文简称：Scale Out，全称：Scale horizontally，横向扩展，向外扩展。
纵向扩展英文简称：Scale Up，全称：Scale vertically，纵向扩展，向上扩展。
不管横向扩展还是纵向扩展都是一种架构的概念。
横向扩展：比如可以增加一台节点/机器 比如：mysql新增加一个从库、tomcat新增加一台机器;
纵向扩展：比如可以通过修改mysql参数内存比例、修改tomcat的线程数;
在体系结构中使用纵向扩展和横向扩展
我们很少能准确预测系统负载。 面向公众的应用程序可能会在普及程度和使用量上快速增长，内部应用程序也可能随着业务增长而需要支持更大的用户群。 即使我们能预测负载，负载也往往不是恒定的。 零售商在节假日期间的需求更高，而体育网站在季后赛期间达到访问高峰。
在本单元中，我们将：
- 定义纵向的扩展或缩减以及横向的扩展或缩减
- 讨论 Azure 可改善缩放功能的一些方法
- 看看无服务器和容器技术如何提高体系结构的缩放能力
什么是缩放？
当我们了解如何增加或降低应用程序的计算容量和相对成本时，定义两个关键概念非常重要：“缩放”和“资源”。
- 缩放是管理资源以帮助应用程序满足一组性能要求的过程。 有太多资源为用户服务时，将无法有效地使用这些资源，并且会浪费资金。 可用资源太少时，应用程序的性能可能会受到不利影响。 目标是要在优化成本的同时满足你定义的性能要求。
- “资源”可以指管理和运行应用程序需要的任何内容。 虚拟机的内存和 CPU 是最明显的资源，但某些 Azure 服务可能会要求考虑带宽或抽象，例如 Azure Cosmos DB 请求单位 (RU)。
假设应用程序需求不变，很容易预测所需的适当资源量。 但是在现实中，应用程序的需求随时间的推移而变化，因此预测所需的适当资源量较为困难。 如果幸运的话，这种变化是可预测或周期性的，但这并非所有场景的典型情况。 理想情况下，你希望预配适当数量的资源来满足需求，然后根据需求变化调整数量。
在本地场景中（即你购买和管理自己的服务器时），进行缩放比较困难。 添加资源可能成本高昂，而且通常需要很长时间才能使资源联机。 有时甚至会超出增加容量实际需要的时间。 在系统需求低时缩减资源也同样困难，你可能不得不面对成本增加这一问题。
轻松缩放是 Azure 的一个重要优势。 大多数 Azure 资源都提供在需求变化时轻松添加或删除资源的能力。 许多服务都有自动选项，可监控需求并做出调整。 自动缩放功能通常被称为“自动缩放”。 通过自动缩放，你可以为可用的最小和最大实例数级别设置阈值。 该功能还根据性能指标（例如 CPU 使用率） 添加或删除实例。
什么是纵向扩展或缩减？
使用服务的单个实例（如虚拟机）时，可能需要缩放实例可用的资源数量。
- “纵向扩展”是增加给定实例的容量的过程。 例如，若要增加处理容量，可以将虚拟机从 1 个 vCPU、3.5 GB RAM 增加到 2 个 vCPU、7 GB RAM。
- “纵向缩减”是减少给定实例的容量的过程。 例如，你可以将虚拟机的容量从 2 个 vCPU 和 7 GB 的 RAM 减少到 1 个 vCPU 和 3.5 GB 的 RAM。 通过这样的方式来缩减容量和成本。
下图显示了更改虚拟机大小的示例。
我们来从 Azure 资源的角度看一看纵向扩展或纵向缩减的含义：
- 在 Azure 虚拟机中，根据虚拟机大小进行缩放。 每个 VM 大小具有一定数量的 vCPU、RAM 和与之相关的本地存储。 例如，你可以从 Standard_DS1_v2 虚拟机（1 个 vCPU、3.5 GB 的 RAM）纵向扩展到 Standard_DS2_v2 虚拟机（2 个 vCPU、7 GB 的 RAM）。
- Azure SQL 数据库是 Microsoft SQL Server 的一种平台即服务 (PaaS) 实现。 你可以基于数据库事务单位 (DTU) 或 vCPU 的数量对数据库进行纵向扩展。 DTU 是基础资源的抽象，也是 CPU、IO 和内存的混合。 例如，可以将 Azure SQL 数据库中的数据库从具有 250 DTU 的 P2 扩展到具有 500 DTU 的 P4，以为数据库提供更高吞吐量和容量。
- Azure 应用服务是 Azure 上的 PaaS 网站托管服务。 网站在虚拟服务器场（也称为应用服务计划）上运行。 你可以在层级之间纵向扩展或缩减应用服务计划。 这些层级内也提供了容量选择。 例如，S1 应用服务计划的每个实例具有 1 个 vCPU 和 1.75 GB 的 RAM。 你可以纵向扩展到 S2 应用服务计划，其中每个实例具有 2 个 vCPU 和 3 GB 的 RAM。
若要在本地环境中缩放这些类型的功能，通常必须等待所需硬件采购和安装完毕，才能开始使用新的缩放级别。 在 Azure 中，物理资源已部署并可供使用。 只需选择要使用的备用缩放级别即可。
你可能需要考虑在解决方案中纵向扩展的影响。 你的决定取决于选择的云服务。
例如，如果选择在 Azure SQL 数据库中纵向扩展，则该服务将处理单个节点的纵向扩展并继续运行服务。 更改数据库的服务层或性能级别会在新的性能级别创建原始数据库的副本。 然后将连接切换到副本。 在这个过程中数据不会丢失。 服务切换到副本时，只有短暂的中断。 中断时间通常不到 4 秒。
或者，如果选择纵向扩展或缩减虚拟机，则可通过选择其他实例大小来实现。 在大多数情况下，如果 VM 已在运行，需要重启 VM。 考虑到这一点，预计在缩放 VM 时需要重新启动。 你需要在计划中考虑这种可能性。
最后，始终应查找可纵向缩减的地方。 如果应用程序可在较低的价格层提供足够的性能，则可以减少 Azure 帐单。
什么是横向扩展或缩减？
你现在已了解了纵向扩展和缩放是调整单个实例可用的资源量。 横向扩展和缩减调整实例总数。
- 横向扩展是添加更多实例来支持解决方案负载的过程。 例如，如果你的网站前端托管在虚拟机上，则在负载级别增加时，你可以增加虚拟机数。
- 横向缩减是删除支持解决方案负载不再需要的实例的过程。 如果你的网站前端使用率较低，你可以希望减少实例数以节省成本。
下图显示了更改虚拟机实例数的示例。
下面是横向扩展或横向缩减在 Azure 资源上下文中的含义的一些示例：
- 对于基础结构层，可能会使用虚拟机规模集自动添加和删除额外的实例。
- 使用虚拟机规模集可以创建并管理一组完全相同的、负载均衡的 VM。
- 可以根据需求或定义的计划自动增减 VM 实例的数目。
- 在 Azure SQL 数据库实现中，可以通过分片在数据库实例之间共享负载。 分片是一项可跨许多独立数据库分发大量相同结构数据的技术。
- 在 Azure 应用服务中，应用服务计划是托管应用程序的虚拟 Web 服务器。 以这种方式进行横向扩展意味着要增加服务器场中的虚拟机数。 与虚拟机规模集一样，可以根据特定指标或计划自动增加或减少实例数。
通常可以通过 Azure 门户、命令行工具或 Azure 资源管理器模板轻松进行横向扩展。 在大多数情况下，用户可以无缝过渡。
自动缩放
可以配置其中一些服务，让其使用“自动缩放”功能。 借助自动缩放，无需再为手动缩放服务而费心。 你可以设置实例数的最小和最大阈值。 你可以根据特定指标（如队列长度或 CPU 利用率）进行缩放。 还可以根据计划进行缩放。 例如工作日下午 5:00 至晚上 7:00 之间。 下图显示了自动缩放功能如何管理用于处理负载的实例。
横向扩展和横向缩减注意事项
横向扩展时，应用程序的启动时间可能会影响应用程序缩放的速度。 如果 Web 应用需要 2 分钟才能启动并可供用户使用，这意味着每个实例都将需要 2 分钟才能供用户使用。 在确定缩放速度时，需要考虑该启动时间。
此外，还需要考虑应用程序如何处理状态。 应用程序横向缩减时，存储在从环境中删除的实例上的任何状态都将丢失。 如果用户连接到没有状态的实例，应用程序可能会强制用户登录或重新选择数据。 这会导致用户体验不佳。 一种常见模式是将状态外部化到另一种服务（如 Azure Cache for Redis 或 SQL 数据库），使 Web 服务器变成无状态。 现在，你的 Web 前端是无状态的，你无需担心哪些单个实例可用。 这些实例执行相同的作业，并且部署方式相同。
限制
我们已经确定应用程序的负载会随着时间的推移而变化。 这种变化可能归因于活跃或并发用户数以及正在执行的活动。 可使用自动缩放添加容量，但也可使用限制机制来限制来自数据源的请求数。 你可以通过在应用程序级别设置已知限制来保护性能限制。 这样，可以防止应用程序中断。 限制最常用于公开 API 终结点的应用程序中。
应用程序确定其将违反某条限制后，限制便会开始并确保不违反整体系统 SLA。 例如，如果你公开 API 供客户用于获取数据，则可以将请求数限制为每分钟 100 个。 如果任何一个客户超过此限制，你可以使用 HTTP 429 状态代码进行响应，并显示可成功提交另一个请求前的等待时间。
无服务器
无服务器计算提供云托管执行环境，可运行应用，但会将基础环境完全抽象化。 你创建一个服务实例，并添加代码。 不需要甚至不允许管理或维护基础设施。
可配置无服务器应用以响应事件。 事件可以是 REST 终结点、计时器或从其他 Azure 服务接收的消息。 无服务器应用仅在被事件触发时运行。
使用无服务器应用时，你不用负责基础结构。 系统自动处理缩放和性能。 你仅需为使用的资源付费。 没有必要保留容量。 Azure Functions、Azure 容器实例和 Azure 逻辑应用就是 Azure 上提供的无服务器计算的示例。
容器
容器是一种在虚拟化环境中运行应用程序的方法。 虚拟机在硬件级别进行虚拟化，在该级别，虚拟机监控程序使其可以在一个物理服务器上运行多个虚拟化操作系统。 容器将虚拟化提升了一个级别。 在 OS 级别完成虚拟化，这样就有可能在同一个 OS 中运行多个相同的应用程序实例。
容器是轻量级的，非常适合用于横向扩展场景。 它们被设计为根据环境和需求变化实现动态创建、横向扩展和停止。 使用容器的另一个好处是能够在每个虚拟机上运行多个独立的应用程序。 由于容器在内核级别受到保护和隔离，因此不一定需要单独的 VM 来处理单独的工作负载。
虽然可以在虚拟机上运行容器，但有一些 Azure 服务可简化容器的管理和缩放：
-
Azure Kubernetes 服务 (AKS)
借助 Azure Kubernetes 服务，可设置虚拟机作为节点。 Azure 托管 Kubernetes 管理平面。 仅对在运行的托管容器的工作器节点节点收费。
若要增加 Azure 中的工作器节点数，你可以使用 Azure CLI 手动增加该数量。 撰写本文时，可以使用 AKS 上的群集自动缩放程序来自动缩放工作器节点。 在 Kubernetes 群集上，你可以使用水平 Pod 自动缩放程序对要部署的容器的实例数进行横向扩展。
AKS 还可以使用下一部分中所述的虚拟 Kubelet 进行缩放。
-
Azure 容器实例
Azure 容器实例是无服务器方法，可用于按需创建和执行容器。 仅需为按秒计的执行时间付费。
你可以使用虚拟节点将 Azure 容器实例连接到 Kubernetes 环境，包括 AKS。 AKS 的虚拟节点加载项基于开源虚拟 Kubelet。 对于虚拟节点，当 Kubernetes 群集需要其他容器实例时，可从容器实例满足这些要求。 由于容器实例是无服务器的，因此无需具有保留容量。 你可以利用 Kubernetes 缩放的控制和灵活性，以及无服务器的按秒计费。
知识检查
什么是横向扩展和纵向扩展？
现代应用程序不断变化，随着新要求的发展而发展，并且存在于对资源的不同需求的环境中。扩展应用程序可以根据资源需求适当调整其大小，以确保客户满意并降低基础设施成本。
如果您不知道如何有效地扩展，您不仅会损害您的应用程序，还会给您的运营团队带来不必要的压力。手动尝试确定何时扩大或扩大规模非常困难。如果您购买更多基础设施来适应高峰流量，那么当负载不是高峰时，您可能会超支。如果您以平均负载为目标，流量高峰将影响您的应用程序性能，并且当流量下降时，这些资源将被闲置。
什么是纵向扩展与横向扩展
横向扩展(「Scale-out」)或水平缩放与纵向扩展(「Scale-up」)或垂直缩放形成对比。
扩展云资源的想法可能很直观。随着您的云工作负载发生变化，可能需要增加基础架构以支持增加的负载，或者在需求低时减少基础架构可能是有意义的。“向上或向外”部分可能不太直观。横向扩展是并行添加更多等效功能组件以分散负载。这将从两个负载平衡的 Web 服务器实例变为三个实例。相比之下，扩大规模是使组件更大或更快以处理更大的负载。这会将您的应用程序移动到具有 2 个 CPU 的虚拟服务器 (VM) 到具有 3 个 CPU 的虚拟服务器。缩减则相反。
两个比喻
火车动力
传统火车和动车。传统的存储Scale-up架构的存储就好像传统的火车一样，当后面的磁盘越挂越多的时候，控制器性能以及背板带宽却不能相应提升，因此传统存储在磁盘容量扩容到一定程度时候，往往性能下降。
集群存储就好像新一代的动车组火车一样，当火车车厢增加的时候，前面的火车头动力也随之增加，因此不会发生性能瓶颈。
所谓动车组的设计理念和传统火车设计理念的最大区别在于传统火车主要动力来自于火车头(就像传统模块化阵列的两个控制器)，而动车组则不一样，除了车头配有动力装置外，每一节车厢都配有动力推动装置。集群存储大多都是由一个个节点(X86 服务器)组成，每一个节点添加进去后，不仅能够添加容量，还能够添加整个存储器的整体处理能力。
鱼缸启示
其实我认为Scale-out和Scale-up的概念可以用一个简单的例子来解释。
不知您有没有养过鱼? 当你只有六七条鱼的时候，一个小型鱼缸就够了;可是过一段时间新生了三十多条小鱼，这个小缸显然不够大了。
如果用Scale-up解决方案，那么你就需要去买一个大缸，把所有沙啊、水草啊、布景啊、加热棒、温度计都从小缸里拿出来，重新布置到大缸。这个工程可不简单哦，不是十分钟八分钟能搞得定的，尤其水草，纠在一起很难分开(不过这跟迁移数据的工程复杂度比起来实在是毛毛雨啦，不值一提)。
那么现在换个思路，用Scale-out方案，就相当于是你在这个小缸旁边接了一个同样的小缸，两个缸联通。鱼可以自动分散到两个缸，你也就省掉了上面提到的那一系列挪沙、水草、布景等的折腾了。
回到存储架构。用户在采购之初很难准确预测未来数据增长的速度和总量。用户往往不得不采购比自己目前实际需求容量更大的存储，这就导致两个问题，一是预算的浪费，很多存储空间都是为未来数据增长采购的，花了10TB的钱，但是可能只利用上了5TB，另5TB的资金都白白放在那里。另一个问题是，随着时间推移，数据增长，数据量超过了10TB。
按照过去Scale-up的理念，解决方案就是购买更大容量的存储，那么难免面临数据迁移的问题，用户必须停机迁移数据，意味着服务的中断。而Scale-out架构解决了这个矛盾。用户按需采购存储，一旦容量不够了，再购置一台接到原有存储上就可以了。
举个例子
常见的存储设备扩展案例，下图展示了scale-out存储方案的架构。在图中，系统只能通过增加具有完整功能的节点进行扩展，但一个scale-out系统可以有很多节点，而且节点之间的内部物理互联距离也可以很远。
Scale-up，即纵向扩展架构。从下面的拓扑图我们可见，纵向扩展是利用现有的存储系统，通过不断增加存储容量来满足数据增长的需求。
Scale-up 和 scale-out 并非不能融合在一起，很多存储系统就可以同时实现纵向扩展和横向扩展,下面的示意图就展示了这种方案。
究竟选择scale-up还是scale-out架构,主要考虑以下因素：
| 成本 | Scale-up架构只有容量升级的成本，不会增加控制器或基础设施的开销。如果我们主要衡量每GB存储的单位价格，scale-up的扩展方式无疑更便宜一些 |
|---|---|
| 容量 | 两种解决方案都可以满足容量需求，但scale-up架构也许会有些限制，主要取决於单个系统最大支持多少个磁盘数量和多大的容量 |
| 性能 | Scale-out架构在性能上具有扩展潜力，在多个存储控制器下，IOPS处理能力和吞吐带宽都可以聚合。虽然节点之间的通信会引发延迟，但那是部署时的细节问题 |
| 管理 | Scale-up架构本身就是以单一系统的方式来进行管理的。而Scale-out架构通常有聚合管理的能力，但每个厂商提供的产品可能会有所不同 |
| 复杂性 | Scale-up架构的存储相对简单，而scale-out架构的系统会更复杂一些，毕竟每个节点都需要管理 |
| 可用性 | 多个节点可以提供更好的可用性，假使有一个部件故障或失效，系统也不至于整体宕机。这一点与具体的实施方案也有关系 |
在选择scale-up还是scale-out的时候，我们要考虑大量的因素。而结果往往取决于哪个厂商有比其他人更好的整体方案、实施能力和技术优势。但我们最好从了解最基本的信息起步，了解这两种技术及其之间的差别。