Kubernetes 分布式应用部署实战：以人脸识别应用为例

伙计们，请搬好小板凳坐好，下面将是一段漫长的旅程，期望你能够乐在其中。
我将基于 Kubernetes 部署一个分布式应用。我曾试图编写一个尽可能真实的应用，但由于时间和精力有限，最终砍掉了很多细节。
我将聚焦 Kubernetes 及其部署。
让我们开始吧。

应用

TL;DR

该应用本身由 6 个组件构成。代码可以从如下链接中找到：Kubenetes 集群示例。
这是一个人脸识别服务，通过比较已知个人的图片，识别给定图片对应的个人。前端页面用表格形式简要的展示图片及对应的个人。具体而言，向 接收器 发送请求，请求包含指向一个图片的链接。图片可以位于任何位置。接受器将图片地址存储到数据库 (MySQL) 中，然后向队列发送处理请求，请求中包含已保存图片的 ID。这里我们使用 NSQ 建立队列。
图片处理 服务一直监听处理请求队列，从中获取任务。处理过程包括如下几步：获取图片 ID，读取图片，通过 gRPC 将图片路径发送至 Python 编写的 人脸识别 后端。如果识别成功，后端给出图片对应个人的名字。图片处理器进而根据个人 ID 更新图片记录，将其标记为处理成功。如果识别不成功，图片被标记为待解决。如果图片识别过程中出现错误，图片被标记为失败。
标记为失败的图片可以通过计划任务等方式进行重试。
那么具体是如何工作的呢？我们深入探索一下。

接收器

接收器服务是整个流程的起点，通过如下形式的 API 接收请求：

curl -d '{"path":"/unknown_images/unknown0001.jpg"}' http://127.0.0.1:8000/image/post[/code]
此时，接收器将路径path存储到共享数据库集群中，该实体存储后将从数据库服务收到对应的 ID。本应用采用“实体对象Entity Object的唯一标识由持久层提供”的模型。获得实体 ID 后，接收器向 NSQ 发送消息，至此接收器的工作完成。
图片处理器
从这里开始变得有趣起来。图片处理器首次运行时会创建两个 Go 协程routine，具体为：
Consume
这是一个 NSQ 消费者，需要完成三项必需的任务。首先，监听队列中的消息。其次，当有新消息到达时，将对应的 ID 追加到一个线程安全的 ID 片段中，以供第二个协程处理。最后，告知第二个协程处理新任务，方法为 sync.Condition。
ProcessImages
该协程会处理指定 ID 片段，直到对应片段全部处理完成。当处理完一个片段后，该协程并不是在一个通道上睡眠等待，而是进入悬挂状态。对每个 ID，按如下步骤顺序处理：

与人脸识别服务建立 gRPC 连接，其中人脸识别服务会在人脸识别部分进行介绍
从数据库获取图片对应的实体
为 断路器 准备两个函数
函数 1: 用于 RPC 方法调用的主函数
函数 2: 基于 ping 的断路器健康检查

调用函数 1 将图片路径发送至人脸识别服务，其中路径应该是人脸识别服务可以访问的，最好是共享的，例如 NFS
如果调用失败，将图片实体状态更新为 FAILEDPROCESSING
如果调用成功，返回值是一个图片的名字，对应数据库中的一个个人。通过联合 SQL 查询，获取对应个人的 ID
将数据库中的图片实体状态更新为 PROCESSED，更新图片被识别成的个人的 ID

这个服务可以复制多份同时运行。
断路器
即使对于一个复制资源几乎没有开销的系统，也会有意外的情况发生，例如网络故障或任何两个服务之间的通信存在问题等。我在 gRPC 调用中实现了一个简单的断路器，这十分有趣。
下面给出工作原理：



当出现 5 次不成功的服务调用时，断路器启动并阻断后续的调用请求。经过指定的时间后，它对服务进行健康检查并判断是否恢复。如果问题依然存在，等待时间会进一步增大。如果已经恢复，断路器停止对服务调用的阻断，允许请求流量通过。
前端
前端只包含一个极其简单的表格视图，通过 Go 自身的 html/模板显示一系列图片。
人脸识别
人脸识别是整个识别的关键点。仅因为追求灵活性，我将这个服务设计为基于 gRPC 的服务。最初我使用 Go 编写，但后续发现基于 Python 的实现更加适合。事实上，不算 gRPC 部分的代码，人脸识别部分仅有 7 行代码。我使用的人脸识别库极为出色，它包含 OpenCV 的全部 C 绑定。维护 API 标准意味着只要标准本身不变，实现可以任意改变。
注意：我曾经试图使用 GoCV，这是一个极好的 Go 库，但欠缺所需的 C 绑定。推荐马上了解一下这个库，它会让你大吃一惊，例如编写若干行代码即可实现实时摄像处理。
这个 Python 库的工作方式本质上很简单。准备一些你认识的人的图片，把信息记录下来。对于我而言，我有一个图片文件夹，包含若干图片，名称分别为 
hannibal_1.jpg
、 
hannibal_2.jpg
、 
gergely_1.jpg
、 
john_doe.jpg
。在数据库中，我使用两个表记录信息，分别为 
person
、 
person_images
，具体如下：
+----+----------+| id | name     |+----+----------+|  1 | Gergely  ||  2 | John Doe ||  3 | Hannibal |+----+----------++----+----------------+-----------+| id | image_name     | person_id |+----+----------------+-----------+|  1 | hannibal_1.jpg |         3 ||  2 | hannibal_2.jpg |         3 |+----+----------------+-----------+
人脸识别库识别出未知图片后，返回图片的名字。我们接着使用类似下面的联合查询找到对应的个人。
select person.name, person.id from person inner join person_images as pi on person.id = pi.person_id where image_name = 'hannibal_2.jpg';
gRPC 调用返回的个人 ID 用于更新图片的 
person
 列。
NSQ
NSQ 是 Go 编写的小规模队列，可扩展且占用系统内存较少。NSQ 包含一个查询服务，用于消费者接收消息；包含一个守护进程，用于发送消息。
在 NSQ 的设计理念中，消息发送程序应该与守护进程在同一台主机上，故发送程序仅需发送至 localhost。但守护进程与查询服务相连接，这使其构成了全局队列。
这意味着有多少 NSQ 守护进程就有多少对应的发送程序。但由于其资源消耗极小，不会影响主程序的资源使用。
配置
为了尽可能增加灵活性以及使用 Kubernetes 的 ConfigSet 特性，我在开发过程中使用 
.env
 文件记录配置信息，例如数据库服务的地址以及 NSQ 的查询地址。在生产环境或 Kubernetes 环境中，我将使用环境变量属性配置。
应用小结
这就是待部署应用的全部架构信息。应用的各个组件都是可变更的，他们之间仅通过数据库、消息队列和 gRPC 进行耦合。考虑到更新机制的原理，这是部署分布式应用所必须的；在部署部分我会继续分析。

12345 / 5 页下一页
查看其它分页：