mirror of
https://github.com/DocsHome/microservices.git
synced 2025-12-08 19:25:13 +00:00
update content
This commit is contained in:
oopsguy
parent
7b5811c4cd
commit
ccb79ad053
@ -84,7 +84,7 @@
|
||||
## 1.5、微服务的缺点
|
||||
就像 Fred Brooks 近 30 年前写的[《人月神话》](https://en.wikipedia.org/wiki/The_Mythical_Man-Month)说的，没有银弹。像其他技术一样，微服务架构模式也是如此，存在着缺点。其中一个缺点就是名称本身。微服务这个术语的重点过多偏向于服务的规模。事实上，有些开发者主张构建极细粒度的 10-100 LOC（代码行） 服务虽然小型服务可能比较好，但重要的是要记住，小型服务只是一种手段，而不是主要目标。微服务的目标在于充分分解应用程序以方便应用敏捷开发和部署。
|
||||
|
||||
微服务另一个主要的缺点是由于微服务是一个分布式系统而变得复杂。开发者需要选择和实现基于消息或者 RPC 的进程间通信机制。此外，由于目标请求可能很慢或者不可用，他们还必须编写代码来处理部分故障。虽然这些都不是很复杂高深的事，但模块间通过语言级方法/过程调用相互调用，这比单体应用要复杂得多。
|
||||
微服务另一个主要的缺点是由于微服务是一个分布式系统而变得复杂。开发者需要选择和实现基于消息或者 RPC 的进程间通信机制。此外，由于目标请求可能很慢或者不可用，他们还必须编写代码来处理局部故障。虽然这些都不是很复杂高深的事，但模块间通过语言级方法/过程调用相互调用，这比单体应用要复杂得多。
|
||||
|
||||
微服务的另一个挑战是分区数据库架构。更多多个业务实体的业务事务是相当普遍的。这些事务在单体应用中的实现显得微不足道，因为只有一个单独的数据库。在基于微服务的应用程序中，您需要更新不同服务所有用的数据库。通常不会选择分布式事务，不仅仅是因为 [CAP 定理](https://en.wikipedia.org/wiki/CAP_theorem)。他们根本不支持如今高度可扩展的 NoSQL 数据库和消息代理。您最后不得不使用最终基于一致性的方法，这对于开发人员来说更具挑战性。
|
||||
|
||||
|
||||
@ -6,7 +6,7 @@
|
||||
然而，在微服务架构中，每个微服务都暴露一组通常比较细颗粒的端点。在本文中，我们将研究如何改进客户端通信，并提出一个使用 API 网关的方案。
|
||||
|
||||
## 2.1、简介
|
||||
我们假设您正在为一个购物应用开发一个本地（native）移动客户端。您可能需要实现一个产品详细信息页面，用于展示给定商品的信息。
|
||||
我们假设您正在为一个购物应用开发一个本地原生移动客户端。您可能需要实现一个产品详细信息页面，用于展示给定商品的信息。
|
||||
|
||||
例如，图 2-1 展示了在 Amazon 的 Android 移动应用中的滚动产品信息时所看的内容。
|
||||
|
||||
@ -104,8 +104,8 @@ 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)，该注册表是所有微服务实例及其位置的数据库。
|
||||
|
||||
### 2.5.5、处理部分故障
|
||||
实施 API 网关时必须解决的另一个问题是部分故障问题。当一个服务调用另一个响应缓慢或者不可用的服务时，所有分布式系统都会出现此问题。API 网关不应该无限期地等待下游服务。但是，如何处理故障问题取决于特定的方案和哪些服务发生故障。例如，如果推荐服务在获取产品详细信息时没有响应，API 网关应将其余的产品详细信息返回给客户端，因为它们对用户仍然有用。建议可以是空的，也可以用其他代替，例如硬编码的十强名单。然而，如果产品信息服务没有响应，那么 API 网关应该向客户端返回错误。
|
||||
### 2.5.5、处理局部故障
|
||||
实施 API 网关时必须解决的另一个问题是局部故障问题。当一个服务调用另一个响应缓慢或者不可用的服务时，所有分布式系统都会出现此问题。API 网关不应该无限期地等待下游服务。但是，如何处理故障问题取决于特定的方案和哪些服务发生故障。例如，如果推荐服务在获取产品详细信息时没有响应，API 网关应将其余的产品详细信息返回给客户端，因为它们对用户仍然有用。建议可以是空的，也可以用其他代替，例如硬编码的十强名单。然而，如果产品信息服务没有响应，那么 API 网关应该向客户端返回错误。
|
||||
|
||||
如果可以，API 网关还可以返回缓存数据。例如，由于产品价格变化不大，如果价格服务不可用，API 网关可以返回被缓存的价格数据。数据可以由 API 网关缓存或存储在外部缓存中，如 Redis 或者 Memcached。API 网关通过返回默认数据或缓存数据，确保了系统发生故障时最小程度上影响到用户体验。
|
||||
|
||||
|
||||
@ -23,7 +23,7 @@
|
||||
|
||||
下表展示了各种交互方式。
|
||||
|
||||
|-|一对一|一对多
|
||||
-|一对一|一对多
|
||||
---|---|---|---
|
||||
同步 | 请求/相应 | ——
|
||||
异步 | 通知 | 发布/订阅
|
||||
@ -64,14 +64,14 @@
|
||||
|
||||
但有时候，您必须对 API 作出重大不兼容的更改。由于您无法强制客户端立即升级，服务也必须支持较旧版本的 API 一段时间。如果您使用了基于 HTTP 的机制（如 REST），则一种方法是将版本号嵌入 URL 中。每个服务实例可能同时处理多个版本。或者，您可以部署每个用于处理特定版本的不同实例。
|
||||
|
||||
## 3.5、处理部分故障
|
||||
正如第二章中关于 API 网关所述，在分布式系统中存在着部分故障风险。由于客户端进程和服务进程是分开的，服务可能无法及时响应客户端的请求。由于故障或者维护，服务可能会关闭。也有可能因服务过载，响应速度变得极慢。
|
||||
## 3.5、处理局部故障
|
||||
正如第二章中关于 API 网关所述，在分布式系统中存在着局部故障风险。由于客户端进程和服务进程是分开的，服务可能无法及时响应客户端的请求。由于故障或者维护，服务可能会关闭。也有可能因服务过载，响应速度变得极慢。
|
||||
|
||||
例如，请考虑第二章中的产品详细信息场景。我们假设 Recommendation Service 没有反应。客户端天真的实现可能会无限期地阻塞以等待响应。这不仅会导致用户体验糟糕，而且在许多应用程序中，它将消耗诸如线程等宝贵资源。以致最终，运行时将线程用完，造成无法响应，如图 3-3 所示。
|
||||
|
||||
|
||||
|
||||
为了防止这个问题出现，您必须设计您的服务来处理部分故障。以下是一个由 [Netflix 给出的好方法](http://techblog.netflix.com/2012/02/fault-tolerance-in-high-volume.html)。处理部分故障的策略包括：
|
||||
为了防止这个问题出现，您必须设计您的服务来处理局部故障。以下是一个由 [Netflix 给出的好方法](http://techblog.netflix.com/2012/02/fault-tolerance-in-high-volume.html)。处理局部故障的策略包括：
|
||||
|
||||
- **网络超时** - 在等待响应时，不要无限期地阻塞，始终使用超时方案。使用超时方案确保资源不被无限地消耗。
|
||||
|
||||
|
||||
@ -26,7 +26,7 @@
|
||||
- [2.5.2、使用响应式编程模型](https://github.com/oopsguy/microservices-from-design-to-deployment-chinese/blob/master/2-using-an-api-gateway.md#252使用响应式编程模型)
|
||||
- [2.5.3、服务调用](https://github.com/oopsguy/microservices-from-design-to-deployment-chinese/blob/master/2-using-an-api-gateway.md#253服务调用)
|
||||
- [2.5.4、服务发现](https://github.com/oopsguy/microservices-from-design-to-deployment-chinese/blob/master/2-using-an-api-gateway.md#254服务发现)
|
||||
- [2.5.5、处理部分故障](https://github.com/oopsguy/microservices-from-design-to-deployment-chinese/blob/master/2-using-an-api-gateway.md#255处理部分故障)
|
||||
- [2.5.5、处理局部故障](https://github.com/oopsguy/microservices-from-design-to-deployment-chinese/blob/master/2-using-an-api-gateway.md#255处理局部故障)
|
||||
- [2.6、总结](https://github.com/oopsguy/microservices-from-design-to-deployment-chinese/blob/master/2-using-an-api-gateway.md#26总结)
|
||||
- [微服务实战：NGINX Plus 作为 API 网关](https://github.com/oopsguy/microservices-from-design-to-deployment-chinese/blob/master/2-using-an-api-gateway.md#微服务实战nginx-plus-作为-api-网关)
|
||||
|
||||
@ -35,7 +35,7 @@
|
||||
- [3.2、交互方式](https://github.com/oopsguy/microservices-from-design-to-deployment-chinese/blob/master/3-inter-process-communication.md#32交互方式)
|
||||
- [3.3、定义 API](https://github.com/oopsguy/microservices-from-design-to-deployment-chinese/blob/master/3-inter-process-communication.md#33定义api)
|
||||
- [3.4、演化 API](https://github.com/oopsguy/microservices-from-design-to-deployment-chinese/blob/master/3-inter-process-communication.md#34演化api)
|
||||
- [3.5、处理部分故障](https://github.com/oopsguy/microservices-from-design-to-deployment-chinese/blob/master/3-inter-process-communication.md#35处理部分故障)
|
||||
- [3.5、处理局部故障](https://github.com/oopsguy/microservices-from-design-to-deployment-chinese/blob/master/3-inter-process-communication.md#35处理局部故障)
|
||||
- 3.6、IPC 技术
|
||||
- 3.7、异步，基于消息通信
|
||||
- 3.8、同步，请求/响应 IPC
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user