Python 和 Zato 的智能 API 集成

图片来源：

Opensource.com

随着在云驱动的世界中连接的应用程序和 API 的数量急剧增加，以优雅的方式集成它们成为一项挑战，这种方式需要在架构清晰度、运行时性能、系统参与的流程复杂性以及保持集成环境运行所需的维护水平方面具有可扩展性。

应用程序随时间有机增长的组织往往会陷入无法管理的依赖关系、未识别的需求和隐藏的信息流的困境，这些信息流无法触及，以免看似无关的部分突然停止运行。这种情况可能发生在任何人身上，而且在某种程度上实际上是可以预期的。

很自然地认为，人们可以轻松地管理这里和那里的几个 API。

It's natural to think that one can easily manage just a couple of APIs here and there .

然而，最初只是对一个系统或另一个系统的几次调用，却有一个有趣的特点，即不可避免地变成一个紧密耦合的参与者网络，其进一步的使用或开发变得几乎不可能

A couple of APIs turns into a closely coupled network of actors

这在当今始终在线的在线 API 环境中变得尤为明显，这些 API 的重要性正在大规模增长。

介绍 IRA 服务

为了应对需求并引入秩序，人们可以关注诸如基于 Python 的 Zato 集成平台之类的软件，该平台在 LGPL 下发布，并且可以从 GitHub 以及一组特定于操作系统的软件包中免费获得。

Zato 提倡对正在集成的系统和 API 进行清晰的分离，并强调从替代点对点通信的 IRA 服务中构建集成。

IRA 服务是在分布式和集群环境中运行的一段功能，具有以下属性：

有趣的
可重用的
原子性的

事实上，这不过是将 Unix 哲学提升到一个更高的层次，即从应用程序和 API 而不是单个系统程序中组合进程。

在最初提出该哲学三十年后，不同的设置，但原则保持不变——可组合而不是将所有内容捆绑到一个整体中。

虽然将软件设计为可重用和原子构建块是可以理解的，但有趣可能会引出一个显而易见的问题——有趣的意味着什么？

答案又是一个双重问题

您真的会接受在未来 10 年或更长时间内每天都亲自使用这样的服务吗？
您能否向非技术利益相关者（最终赞助开发的人员）充分解释该服务的目的，并让他们确认他们可以清楚地理解它为等式带来的价值？

如果利益相关者恰好是技术人员，则第二个问题可以改写为——您能否用一条推文解释该服务的目标，并让您一半具有技术头脑的粉丝转发或收藏它？

从 Unix 哲学的角度和命令行工具来看，这很有趣

您是否可以接受使用 ls 命令？或者您是否强烈认为它是 R'lyeh 的后代，需要尽快替换？
您是否可以向了解目录的人解释 mkdir 命令的目的是什么？

现在，什么是不有趣的

如果所有 shell 命令都具有，例如，仅以数字表示的选项组合，每周更改且每个主机都唯一，您会高兴吗？例如，'ls -21' 而不是 'ls -la'，但 'ls -975' 用于 'ls -latrh'？我知道，人们可以习惯一切，但是您真的会面不改色地真正认可它吗？
您将如何毫不羞愧地向 Linux 新手解释 ls 版本的存在？

集成 API 和系统也是如此——如果您遵循 IRA 原则，您会问自己类似的问题。在此基础上添加可重用性和原子性，您就得到了连接原本断开连接的参与者的好方法。

这样的服务也可以称为微服务。

实施 IRA 服务

现在假设有一个应用程序使用 OpenStack Swift 来存储有关新客户的信息，并且所有这些信息都需要分发给各个方。以下是在考虑 IRA 的同时如何处理它

让生产者将所有内容存储在 Swift 容器中
使用 Zato 的通知来定期下载最新的数据集
让 Zato 使用给定的接收者选择的协议将信息分发给预期的接收者

这里满足了所有 IRA 公设

生产者只负责生成输出，不关心谁真正消费它——如果随着时间的推移有更多的接收者，实际上没有任何改变，因为 Zato 会知道这一点，而不是生产者
同样，接收者可以方便地假设他们被调用意味着新数据已准备就绪。如果随着时间的推移出现新的生产者，那也没关系，他们只会接受来自 Zato 的有效负载。
Zato 负责在各种格式或协议（如 XML、JSON、SOAP、REST、AMQP 或任何其他协议）之间转换信息
因此，通知新客户的服务是
- 有趣的——易于解释
- 可重用的——可以插入各种生产者或消费者
- 原子性的——它只做一件事并且做得很好

from zato.server.service import Service

class CreateCustomer(Service):
    def handle(self):

        # Synchronously call REST recipients as defined in Redis
        for conn_name in self.kvdb.conn.smembers('new.customer'):
            conn = self.outgoing.plain_http[conn_name].conn
            conn.send(self.cid, self.request.raw_request)

        # Async notify all pub/sub recipients
        self.pubsub.publish(self.request.raw_request, '/newcust')

这是在实践中使用 IRA 的又一个例子，因为 Zato 自身的架构允许人们开发不关心其输入来源细节的服务——上面的大部分代码也可以在不同的上下文中重用，代码本身不会改变。

剩下的只是填写一些表格并单击“确定”以在整个 Zato 集群中传播更改。

The rest is a matter of filling out forms