微服务架构:自动扩展简介
在本文中，我们将注意力集中在动态缩放，即自动扩展，以及为什么我们需要可以自动扩展的应用程序。
你将学习
-
什么是自动或动态扩展。
-
为什么动态扩展在微服务环境中很重要。
-
如何在云中实现动态扩展。
应用程序的负载变化
应用程序的负载取决于一天中的某个时间，一个月中的某一天或一年中的某个月。
以www.taobao.com为例。在双11期间它的负荷非常高，高达正常负荷的很多倍。然而，在春节和重大环境灾难期间，负载量可能会少得多 – 因为每个人都在忙着观看春节联欢晚会或者交通不便导致的商品无法快递。
如何为应用程序设置基础架构以管理不同的负载？
基础设施很可能需要处理正常负载的10倍。如果您通过预置的基础架构，则需要一个大型基础架构来处理峰值负载。
在负载较少的时期，许多基础设施将闲置。
及时雨－云计算
这就是为什么架构图中需要添加云。使用云，您可以在负载较高时请求更多资源，并在负载较少时将其返回云端。
这称为Scale Out（在负载增加时创建更多实例）和Scale In（在负载下降时减少实例）
如何构建支持云的应用程序，即在云中运行良好的应用程序？
微服务架构出现在了架构图中。
自动扩展简介
使用微服务构建应用程序使您可以在高负载期间增加微服务实例的数量，并在负载较少的情况下减少它们。
请考虑以下CurrencyConversionService(货币交换服务)示例：
CurrencyConversionService与ForexService进行通信。ForexService关注的是计算1美元可以产生多少人民币，或者1欧元可以产生多少人民币。
CurrencyConversionService获取一袋货币和金额，并以您选择的货币生成总金额。例如，它将表示人民币的总价值为10欧元和25美元。
ForexService也可能来自许多其他微服务。
扩展基础架构以匹配负载
ForexService上的负载可能与CurrencyConversionService上的负载不同。您可能需要具有不同数量的CurrencyConversionService和ForexService实例。例如，可能有两个CurrencyConversionService实例，以及ForexService的五个实例：
在稍后的时间点，CurrencyConversionService上的负载可能很低，只需要两个实例。另一方面，ForexService上的更高负载可能需要50个实例。来自两个CurrencyConversionService实例的请求分布在ForexService的50个实例中。
实质上，这就是自动扩展的要求 – 动态变化的微服务实例数量，并在它们之间均匀分配负载。
实现自动扩展
实现自动扩展涉及一些重要的概念。以下内容将详细讨论它们。
注册中心
注册中心启用称为位置透明的东西。每个微服务都向命名服务注册。任何需要与另一个微服务器通信的微服务都会向注册中心询问其位置。
每当出现CurrencyConversionService或ForexService的新实例时，它都会向命名服务器注册。
当CurrencyConversionService想要与ForexService通信时，它会向命名服务器询问可用的实例。
实施位置透明度
CurrencyConversionService知道有五个ForexService实例。
它如何在所有这些实例中分配负载？
负载均衡器出现在了人们的脑中。
一个流行的客户端负载平衡框架是Ribbon。
让我们看一个图表来了解发生的事情：
只要CurrencyConversionService或ForexService的任何实例出现，它就会向命名服务器注册自己。如果CCSInstance2想知道ForexService实例的URL，它会再次与命名服务器通信。命名服务器响应ForexService的所有实例列表 – FSInstance1和FSinstance2 – 及其相应的URL。
功能区负载均衡器在ForexService实例中进行循环，以平衡实例之间的负载。
Ribbon提供多种负载均衡算法供您选择。
何时增加和减少微服务实例
我们没有真正谈论过一个问题。
我们如何知道何时增加或减少微服务的实例数？
这就是应用程序监视和容器（Docker）编排（使用Kubernetes）需要被考虑。
需要监视应用程序以找出它有多少负载。为此，应用程序必须公开我们的指标以跟踪负载。
您可以使用Docker对每个微服务进行容器化并创建映像。
Kubernetes具有管理容器的能力。可以将Kubernetes配置为基于负载自动缩放。Kubernetes可以识别应用程序实例，监控其负载，并自动向上和向下扩展。