微服务实践

最新推荐文章于 2023-04-14 23:30:25 发布

weixin_33877885

最新推荐文章于 2023-04-14 23:30:25 发布

阅读量98

点赞数

文章标签：数据库 python 设计模式

原文链接：https://my.oschina.net/u/3421984/blog/1797491

版权

2019独角兽企业重金招聘Python工程师标准>>>

采用一个API Gateway

API Gateway是一个服务器，也可以说是进入系统的唯一节点。这跟面向对象设计模式中的Facade模式很像。API Gateway封装内部系统的架构，并且提供API给各个客户端。它还可能有其他功能，如授权、监控、负载均衡、缓存、请求分片和管理、静态响应处理等。下图展示了一个适应当前架构的API Gateway。

输入图片说明

API Gateway的优点和缺点

优点

API Gateway的一个最大好处是封装应用内部结构。相比起来调用指定的服务，客户端直接跟gatway交互更简单点。API Gateway提供给每一个客户端一个特定API，这样减少了客户端与服务器端的通信次数，也简化了客户端代码。

缺点

它是一个高可用的组件，必须要开发、部署和管理。还有一个问题，它可能成为开发的一个瓶颈。开发者必须更新API Gateway来提供新服务提供点来支持新暴露的微服务。更新API Gateway时必须越轻量级越好。否则，开发者将因为更新Gateway而排队列。但是，除了这些缺点，对于大部分的应用，采用API Gateway的方式都是有效的。

深入微服务架构的进程间通信

交互模式

当为某一个服务选择IPC时，首先需要考虑服务之间如何交互。客户端和服务器之间有很多的交互模式，我们可以从两个维度进行归类。第一个维度是一对一还是一对多：

• 一对一：每个客户端请求有一个服务实例来响应。
• 一对多：每个客户端请求有多个服务实例来响应

第二个维度是这些交互式同步还是异步：

• 同步模式：客户端请求需要服务端即时响应，甚至可能由于等待而阻塞。
• 异步模式：客户端请求不会阻塞进程，服务端的响应可以是非即时的。

下表显示了不同交互模式：输入图片说明

一对一的交互模式有以下几种方式：

• 请求/响应：一个客户端向服务器端发起请求，等待响应。客户端期望此响应即时到达。在一个基于线程的应用中，等待过程可能造成线程阻塞。
• 通知（也就是常说的单向请求）：一个客户端请求发送到服务端，但是并不期望服务端响应。
• 请求/异步响应：客户端发送请求到服务端，服务端异步响应请求。客户端不会阻塞，而且被设计成默认响应不会立刻到达。

一对多的交互模式有以下几种方式：

• 发布/ 订阅模式：客户端发布通知消息，被零个或者多个感兴趣的服务消费。
• 发布/异步响应模式：客户端发布请求消息，然后等待从感兴趣服务发回的响应。

服务发现的可行方案

客户端发现模式

当使用客户端发现模式时，客户端负责决定相应服务实例的网络位置，并且对请求实现负载均衡。客户端从一个服务注册服务中查询，其中是所有可用服务实例的库。客户端使用负载均衡算法从多个服务实例中选择出一个，然后发出请求。

下图显示的是这种模式的架构图：

输入图片说明

客户端发现模式也是优缺点分明。这种模式相对比较直接，而且除了服务注册表，没有其它改变的因素。除此之外，因为客户端知道可用服务注册表信息，因此客户端可以通过使用哈希一致性（hashing consistently）变得更加聪明，更加有效的负载均衡。

而这种模式一个最大的缺点是需要针对不同的编程语言注册不同的服务，在客户端需要为每种语言开发不同的服务发现逻辑。

服务端发现模式

另外一种服务发现的模式是服务端发现模式（server-side discovery pattern），下图展现了这种模式的架构图：

输入图片说明

服务注册表

服务注册表是服务发现很重要的部分，它是包含服务实例网络地址的数据库。服务注册表需要高可用而且随时更新。客户端可以缓存从服务注册表获得的网络地址。然而，这些信息最终会变得过时，客户端也无法发现服务实例。因此，服务注册表由若干使用复制协议保持同步的服务器构成。

服务注册选项

如前所述，服务实例必须向注册表中注册和注销，如何注册和注销也有一些不同的方式。一种方式是服务实例自己注册，也叫自注册模式（self-registration pattern）；另外一种方式是为其它系统提供服务实例管理的，也叫第三方注册模式（third party registration pattern）。我们来看看自注册模式。