archive-gh-me/microservices
1
0
Fork 0
mirror of https://github.com/DocsHome/microservices.git synced 2025-12-08 19:25:13 +00:00
Code Issues Projects Releases Wiki Activity

fixed 'AutoScaling -> 自动扩展' to 'AutoScaling -> 自动扩缩'

Browse Source
This commit is contained in:
oopsguy 2017-09-19 01:06:01 +08:00
parent 7ea579bf3f
commit 101fea81e0
3 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
2-using-an-api-gateway.md
View File

@ -102,7 +102,7 @@ API 网关需要知道与其通信的每个微服务的位置（IP 地址和端
基础设施服务（比如消息代理）通常都有一个可以通过系统环境变量来指定的静态位置。但是，要确定应用程序服务的位置并不是那么容易。
应用服务可以动态分配位置。此外，由于自动扩展与升级，一个服务的整组实例可以动态变更。因此，API 网关与系统中的任何其他服务客户端一样，需要使用系统的服务发现机制：[服务端发现](http://microservices.io/patterns/server-side-discovery.html)或[客户端发现](http://microservices.io/patterns/client-side-discovery.html)。 第4章中更详细地描述了服务发现。现在需要注意的是，如果系统使用客户端发现，API 网关必须能够查询[服务注册表](http://microservices.io/patterns/service-registry.html)，该注册表是所有微服务实例及其位置的数据库。
应用服务可以动态分配位置。此外，由于自动扩缩与升级，一个服务的整组实例可以动态变更。因此，API 网关与系统中的任何其他服务客户端一样，需要使用系统的服务发现机制：[服务端发现](http://microservices.io/patterns/server-side-discovery.html)或[客户端发现](http://microservices.io/patterns/client-side-discovery.html)。 第4章中更详细地描述了服务发现。现在需要注意的是，如果系统使用客户端发现，API 网关必须能够查询[服务注册表](http://microservices.io/patterns/service-registry.html)，该注册表是所有微服务实例及其位置的数据库。
### 2.5.5、处理局部故障
实施 API 网关时必须解决的另一个问题是局部故障问题。当一个服务调用另一个响应缓慢或者不可用的服务时，所有分布式系统都会出现此问题。API 网关不应该无限期地等待下游服务。但是，如何处理故障问题取决于特定的方案和哪些服务发生故障。例如，如果推荐服务在获取产品详细信息时没有响应，API 网关应将其余的产品详细信息返回给客户端，因为它们对用户仍然有用。建议可以是空的，也可以用其他代替，例如硬编码的十强名单。然而，如果产品信息服务没有响应，那么 API 网关应该向客户端返回错误。

4
4-service-discovery.md
View File

@ -6,7 +6,7 @@
然而，在现代基于云的微服务应用中，这是一个更难解决的问题，如图 4-1 所示。
服务实例具有动态分配的网络位置。此外，由于自动扩展、故障与升级，整组服务实例会动态变更。因此，您的客户端代码需要使用更精确的服务发现机制。
服务实例具有动态分配的网络位置。此外，由于自动扩缩、故障与升级，整组服务实例会动态变更。因此，您的客户端代码需要使用更精确的服务发现机制。
![图 4-1、需要服务寻找帮助的客户端或 API 网关](resources/4-1.png)
@ -111,7 +111,7 @@ Netflix 通过在每个 Amazon EC2 可用性区域（Availability Zone）中运
by Floyd Smith
在微服务环境中，由于自动扩展、故障和升级，您的后端基础设施可能会不断变化，这些包括了服务的创建，部署和扩展。如本章所述，在动态重新分配服务位置的环境中需要服务发现机制。
在微服务环境中，由于自动扩缩、故障和升级，您的后端基础设施可能会不断变化，这些包括了服务的创建，部署和扩展。如本章所述，在动态重新分配服务位置的环境中需要服务发现机制。
将 NGINX 应用于微服务的一部分好处是，您可以轻松地将其配置为自动响应后端基础设施作出的变更。NGINX 配置不仅简单灵活，而且兼容 [Amazon Web Services](http://docs.aws.amazon.com/cli/latest/reference/elasticbeanstalk/create-configuration-template.html) 使用的模板，可以更轻松地管理特定的服务变更与受负载均衡的变更服务组。

4
6-choosing-deployment-strategy.md
View File

@ -53,13 +53,13 @@
每个虚拟机一个服务实例模式有许多优点。VM 的主要优点是每个服务实例运行是完全隔离的。它有固定数量的 CPU 和内存，且不能从其他服务窃取资源。
将微服务部署为虚拟机的另一个优点是可以利用成熟的云基础架构。如 AWS 之类的云提供了有用的功能，例如负载平衡和自动扩展。
将微服务部署为虚拟机的另一个优点是可以利用成熟的云基础架构。如 AWS 之类的云提供了有用的功能，例如负载平衡和自动扩缩。
将服务部署为虚拟机的另一个好处是它封装了服务的实现技术。一旦服务被打包成一个虚拟机，它就成为一个黑匣子。VM 的管理 API 成为部署服务的 API。部署变得更加简单、可靠。
然而，每个虚拟机一个服务实例模式也有一些缺点。一个缺点是资源利用率较低。每个服务实例都有一整个 VM 开销，包括操作系统。此外，在一个典型的公共 IaaS 中，VM 具有固定大小，并且 VM 可能未被充分利用。
此外，公共 IaaS 中的 VM 通常是收费的，无论它们是处于繁忙还是空闲。如 AWS 之类的 IaaS 虽然提供了自动扩展功能，但[很难快速响应需求变化](http://techblog.netflix.com/2013/11/scryer-netflixs-predictive-auto-scaling.html)。因此，您经常需要过度配置 VM，从而增加部署成本。
此外，公共 IaaS 中的 VM 通常是收费的，无论它们是处于繁忙还是空闲。如 AWS 之类的 IaaS 虽然提供了自动扩缩功能，但[很难快速响应需求变化](http://techblog.netflix.com/2013/11/scryer-netflixs-predictive-auto-scaling.html)。因此，您经常需要过度配置 VM，从而增加部署成本。
这种方法的另一缺点是部署新版本的服务时通常很慢。由于大小原因，VM 镜像通常构建很慢。此外，VM 实例化也很慢，同样是因为它们的大小。而且，操作系统也需要一些时间来启动。但请注意，这并不普遍，因为已经存在由 Boxfuse 构建的轻量级 VM。