mirror of
https://github.com/DocsHome/microservices.git
synced 2025-12-08 19:25:13 +00:00
used relative path
This commit is contained in:
oopsguy
parent
bac4a94c98
commit
d66638f8d0
@ -10,7 +10,7 @@
|
||||
|
||||
这个新应用是一个模块化的六边形架构，如图 1-1 所示：
|
||||
|
||||
|
||||
|
||||
|
||||
应用程序的核心是由模块实现的业务逻辑，它定义了服务、领域对象和事件。围绕核心的是与外部世界接口对接的适配器。适配器示例包括了数据库访问组件、生产和消费消息的消息组件和 web 组件，它们暴露了 API 或者实现了一个 UI。
|
||||
|
||||
@ -46,13 +46,13 @@
|
||||
|
||||
例如，前面描述的系统可能分解成如图 1-2 所示：
|
||||
|
||||
|
||||
|
||||
|
||||
应用程序的每个功能区域现在都由自己的微服务实现。此外，Web 应用程序被分为一组更简单的 Web 应用程序。例如，以我们的出粗车为例，一个专门是乘客的，一个专门是司机的。这使得它更容易地为特定的用户、司机、设备或者专门的用例部署不同的场景。每个后端服务暴露一个 REST API，大部分的服务消费由其他服务提供的 API。例如，司机管理使用了通知服务器来告知一个可用司机关于一个潜在路程。UI 服务调用了其他服务来渲染页面。服务也可以使用异步、基于消息的通信。本电子书后面将会详细介绍服务间的通信。
|
||||
|
||||
一些 REST API 也暴露给移动端应用供司机和乘客使用。然而，应用不能直接访问后端服务。相反，他们之间的通信是由一个称为 [API 网关](http://microservices.io/patterns/apigateway.html)（API Cateway）的中介负责。API 网关负责负载均衡、缓存、访问控制、API计量和监控，[可以通过使用 NGINX 来实现](http://www.nginx.com/solutions/api-gateway/)。第 2 章详细讨论 API 网关。
|
||||
|
||||
|
||||
|
||||
|
||||
微服务架构模式相当于此缩放立方的 Y 轴坐标，此立方是一个来自[《架构即未来》](http://theartofscalability.com/)的三维伸缩模型。另外两个坐标轴是由运行多个相同应用程序副本的负载均衡器组成的 X 轴缩放和 Z 轴坐标（或者数据分区），其中请求的属性（例如，一行记录的主键或者客户标识）用于将请求路由到特定的服务器。
|
||||
|
||||
@ -60,7 +60,7 @@
|
||||
|
||||
在运行时，X 坐标轴上运行着服务的多个实例，每一个服务配合负载均衡器以满足吞吐量和可用性。某些应用程序也有可能使用 Z 坐标轴来进行分区服务。图 1-4 展示了如何用 Docker 将旅途管理（Trip Management）服务部署到 Amazon EC2 上运行。
|
||||
|
||||
|
||||
|
||||
|
||||
在运行时，旅途管理服务由多个服务实例组成，每个服务实例是一个 Docker 容器。为了实现高可用，容器是在多个云虚拟机上运行的。服务实例的前方是一个[如 NGINX 的负载均衡器](http://www.nginx.com/solutions/load-balancing/)，用于跨实例分发请求。负载均衡器也可以处理其他问题，如[缓存](http://www.nginx.com/resources/admin-guide/content-caching/)、[访问控制](http://www.nginx.com/resources/admin-guide/restricting-access/)、[API 度量](http://www.nginx.com/solutions/api-gateway/)和[监控](http://www.nginx.com/products/live-activity-monitoring/)。
|
||||
|
||||
@ -68,7 +68,7 @@
|
||||
|
||||
每个服务都有自己的数据库。而且，服务可以使用一种最适合其需求、号称多语言持久架构（polyglot persistence architecture）的数据库。例如，司机管理，找到与潜在乘客接近的司机必须使用支持高效地理查询的数据库。
|
||||
|
||||
|
||||
|
||||
|
||||
从表面上看，微服务架构模式类似于 SOA。微服务是由一组服务组成。然而，换另一种方式去思考微服务架构模式，它是没有商业化的 SOA，没有集成 [Web 服务规范](http://en.wikipedia.org/wiki/List_of_web_service_specifications)（WS-\*）和企业服务总线（Enterprise Service Bus，ESB）。基于微服务的应用支持更简单、轻量级的协议，例如，REST，而不是 WS-\*。他们也尽量避免使用 ESB，而是实现微服务本身具有类似 ESB 的功能。微服务架构也拒绝了 SOA 的其他部分，例如，数据访问[规范模式](https://en.wikipedia.org/wiki/Canonical_schema_pattern)概念。
|
||||
|
||||
|
||||
@ -10,7 +10,7 @@
|
||||
|
||||
例如，图 2-1 展示了在 Amazon 的 Android 移动应用中的滚动产品信息时所看的内容。
|
||||
|
||||
|
||||
|
||||
|
||||
即使这是一个智能手机应用，产品详细信息页面展示了很多信息。例如，不仅有基本的产品信息，如名称、描述和价格，页面还展示了：
|
||||
|
||||
@ -37,7 +37,7 @@ GET api.company.com/productdetails/productId
|
||||
- **配送服务** - 配送选项、期限和费用，由配送方的 API 单独提供
|
||||
- **推荐服务** - 推荐类目
|
||||
|
||||
|
||||
|
||||
|
||||
我们需要决定移动客户端如何访问这些服务。让我们来看看有哪些方式。
|
||||
|
||||
@ -62,7 +62,7 @@ https://serviceName.api.company.name
|
||||
|
||||
图 2-3 展示了 API 通常如何整合架构
|
||||
|
||||
|
||||
|
||||
|
||||
API 网关负责请求路由、组合和协议转换。所有的客户端请求首先通过 API 网关，之后请求被路由到适当的服务。API 网关通常会通过调用多个微服务和聚合结果来处理一个请求。它可以在 Web 协议（如 HTTP 和 WebSocket）和用于内部的非 Web 友好协议之间进行转换。
|
||||
|
||||
|
||||
@ -8,7 +8,7 @@
|
||||
|
||||
稍后我们将了解到多种 IPC 技术，但在此之前，我们先来探讨一下涉及到的各种设计问题。
|
||||
|
||||
|
||||
|
||||
|
||||
## 3.2、交互方式
|
||||
当为服务选择一种 IPC 机制时，首先需要考虑服务如何交互。有很多种客户端-服务交互方式。它们可以分为两个类。第一类是一对一交互与一对多交互：
|
||||
@ -46,7 +46,7 @@
|
||||
|
||||
图 3-2 显示了当用户请求打车时，打车应用中的服务可能会发生交互。
|
||||
|
||||
|
||||
|
||||
|
||||
服务使用了通知、请求/响应和发布/订阅组合。例如，乘客的智能手机向 Trip Management 微服务发送一条通知以请求一辆车。Trip Management 服务通过使用请求/响应来调用 Passenger Management 服务以验证乘客的帐户是否可用。之后，Trip Management 服务创建路线，并使用发布/订阅通知其他服务，包括用于定位可用司机的 Dispatcher。
|
||||
|
||||
@ -69,7 +69,7 @@
|
||||
|
||||
例如，请回想第二章中的产品详细信息场景。我们假设 Recommendation Service 没有响应。客户端天真般的实现可能会无限期地阻塞以等待响应。这不仅会导致用户体验糟糕，而且在许多应用程序中，它将消耗如线程之类等宝贵资源。以致最终，在运行时将线程用完，造成无法响应，如图 3-3 所示。
|
||||
|
||||
|
||||
|
||||
|
||||
为了防止这个问题出现，您必须设计您的服务以处理局部故障。以下是一个由 [Netflix 给出的好方法](http://techblog.netflix.com/2012/02/fault-tolerance-in-high-volume.html)。处理局部故障的策略包括：
|
||||
|
||||
@ -98,7 +98,7 @@
|
||||
|
||||
图 3-4 展示了打车应用程序如何使用发布订阅通道。
|
||||
|
||||
|
||||
|
||||
|
||||
Trip Management 服务通过向发布订阅通道写入 Trip Created 消息来通知已订阅的服务，如 Dispatcher。 Dispatcher 找到可用的司机并通过向发布订阅通道写入 Driver Proposed 消息来通知其他服务。
|
||||
|
||||
@ -140,7 +140,7 @@ Trip Management 服务通过向发布订阅通道写入 Trip Created 消息来
|
||||
|
||||
图 3-5 展示了打车应用程序可能使用 REST 的方式之一。
|
||||
|
||||
|
||||
|
||||
|
||||
乘客的智能手机通过向 Trip Management 服务的 `/trips` 资源发出一个 POST 请求来请求旅程。该服务通过向 Passenger Management 服务发送一个获取乘客信息的 GET 请求来处理该请求。在验证乘客被授权创建旅程后，Trip Management 服务将创建旅程，并向智能手机返回 201 响应。
|
||||
|
||||
|
||||
@ -8,7 +8,7 @@
|
||||
|
||||
服务实例具有动态分配的网络位置。此外，由于自动扩展、故障与升级，整组服务实例会动态变更。因此，您的客户端代码需要使用更精确的服务发现机制。
|
||||
|
||||
|
||||
|
||||
|
||||
有两种主要的服务发现模式：客户端发现（client-side discovery）与服务端发现（server-side discovery）。让我们先来看看客户端发现。
|
||||
|
||||
@ -17,7 +17,7 @@
|
||||
|
||||
图 4-2 展示了该模式的结构
|
||||
|
||||
|
||||
|
||||
|
||||
服务实例的网络位置在服务注册中心启动时被注册。当实例终止时，它将从服务注册中心中移除。通常使用心跳机制周期性地刷新服务实例的注册信息。
|
||||
|
||||
@ -30,7 +30,7 @@
|
||||
## 4.3、服务端发现模式
|
||||
服务发现的另一种方式是服务端发现模式。图 4-3 展示了该模式的结构：
|
||||
|
||||
|
||||
|
||||
|
||||
客户端通过负载均衡器向服务发出请求。负载均衡器查询服务注册中心并将每个请求路由到可用的服务实例。与客户端发现一样，服务实例由服务注册中心注册与销毁。
|
||||
|
||||
@ -69,7 +69,7 @@ Netflix 通过在每个 Amazon EC2 可用性区域（Availability Zone）中运
|
||||
|
||||
图 4-4 展示了该模式的结构。
|
||||
|
||||
|
||||
|
||||
|
||||
该方式的一个很好的范例就是 [Netflix OSS Eureka 客户端](https://github.com/Netflix/eureka)。Eureka 客户端负责处理服务实例注册与注销的所有方面。实现了包括服务发现在内的多种模式的 [Spring Cloud 项目](http://projects.spring.io/spring-cloud/)可以轻松地使用 Eureka 自动注册服务实例。您只需在Java Configuration类应用 `@EnableEurekaClient` 注解即可。
|
||||
|
||||
@ -82,7 +82,7 @@ Netflix 通过在每个 Amazon EC2 可用性区域（Availability Zone）中运
|
||||
|
||||
图 4-5 展示了该模式的结构：
|
||||
|
||||
|
||||
|
||||
|
||||
服务注册器的一个例子是开源的 [Registrator](https://github.com/gliderlabs/registrator) 项目。它可以自动注册和注销作为 Docker 容器部署的服务实例。注册器支持多个服务注册中心，包括 etcd 和 Consul。
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user