如何重新思考包含多异步接口的Python项目的体系结构
我正在开发一个大约一年的Twitch。随着时间的推移，机器人变得越来越大，以增加功能。现在，机器人可以管理多个接口，包括不和谐，Twitch，Twitch，Streamlabs.并有一个web接口来接收来自OAuth身份验证API的所有回调，并将一些统计数据显示在HTML页面上。
然而，机器人越大，我遇到的问题就越多。事实上，我不认为我现在的架构是好的。这是目前的做法：
首先，实例化一个Core类，这个类将包含所有机器人和接口的实例，并存储它们之间共享的变量。它还包含数据库的全局异步锁(因为整个bot运行在一个异步循环上，我需要确保只有一个接口同时与数据库对话)。
class Core:
def __init__(self):
# Define session lock for database access
self.session_lock: asyncio.locks.Lock = asyncio.Lock()
# Store bots & API access
self.discord_bot: Optional[discord.Client] = None
self.twitch_bot: Optional[twitchio.ext.commands.Bot] = None # Manage Twitch IRC chat
self.twitch_api: TwitchApi = None # Manage Twitch API
# Other interfaces ...
# Some shared attributes which are read by all interfaces ...然后，通过传递核心，实例化所有接口。当实例化时，每个接口都将自己注册到核心中。这是接口初始化的一个例子(此处不一致)：
class DiscordBot(commands.Bot):
def __init__(self, core: Core, **options):
super().__init__(**options)
self.core: Core = core
self.core.discord_bot = self以及我的主要脚本中的实例化阶段：
core = Core()
discord_bot = DiscordBot(core)
twitch_bot = TwitchChatBot(core, os.environ['TWITCH_BOT_TMI_TOKEN'], [os.environ['TWITCH_CHANNEL_NAME']])
loop = asyncio.get_event_loop()
loop.create_task(twitch_bot.connect())
loop.create_task(discord_bot.start(os.environ["DISCORD_BOT_TOKEN"]))
loop.run_forever()下面是我的体系结构的全局图，以及如何管理它：
这个体系结构非常方便，因为它允许我在接口之间建立一个非常简单的桥梁。例如，如果我想发布来自我的Twitch的不和谐消息，我可以简单地调用self.core.discord_bot.get_channel(...).send()。另一个方向也是一样的。
但我觉得这个建筑已经不能持续了。目前，Core类包含超过5000行代码和在所有接口之间共享的60多个方法。我想把它炸成多个文件，但它太乱了。而且，从长远来看，我越来越认为在同一个异步循环上运行所有接口不是一个好主意。
我想到了解决方案，比如将所有接口分离成不同的过程。但是，如何管理这些进程之间的同步，而不需要做一些复杂的事情(我的例子是发布来自Twitch的不和谐消息)。我也研究过像Redis这样的同步解决方案，但我不知道它是否能回答我所有的担忧…我还考虑过使用python导入模块直接导入Core实例(因此不必在每个接口中注册Core )，但我不确定它是否工作，以及它是否是一个良好的实践。
我以另一个例子为例，在Core类中实例化了一个处理bot和社区之间交互的类。它用于改变与用户的交互(一种原始聊天机器人)。这个类必须在我的所有接口之间共享，因为我希望这个不和谐的机器人的反应能够根据在Twitch上发生的事情做出反应。
不管怎样，我想听听你对这件事的专家意见。你是怎么组织这一切的？谢谢:)
回答 1
Stack Overflow用户
发布于 2022-08-21 14:11:22
从你的描述中有些不清楚的地方，我认为这可能很重要：
是图底部的机器人，连接外部服务，然后提供API接口到核心，或者是驱动来完成工作？
企业说:业务逻辑在哪里？
我想我已经建立了一个类似的系统。
在我的：
- 有一小部分服务：(我不确定这些服务是否类似于您的机器人)。
- An interface to Twitch chat.
- An interface to Twitch redemptions.
- An interface to KoFi (so I am can react to donations in real time)
- Arguably the logging system could be considered one.
- I don't have a database, but if I did, the service would go here.
- I don't use YouTube, but if I did, the service would go here.
- I've considered putting my StreamLabs Desktop API interface here [via [PySLOBS](https://github.com/Julian-O/PySLOBS)] but I haven't bothered yet.
- I've considered putting an common asynchio loop here, but I haven't bothered yet.- 有一个框架：
- It instantiates and owns the survives.
- It registers, starts and stops the plugins (below).- 有一组更大的插件。
- Each plugin only does one thing.
- e.g. if someone redeems the TextToSpeech reward, it plays the speech. The plugin subscribes to redemptions via the service, and acts when triggered.
- e.g. if someone types "GG" in chat, it plays an animation on stream. The plugin subscribes to chat via the service, and connects to StreamLabs when triggered.- Some plugins are pretty passive; they act when called back by the main app.
- Some plugins have separate threads, so they can act independently.
- Some plugins have threads that spawn asyncio loops (especially because PySLOBS using asyncio).
- Some plugins have separate processes (especially so that Kivy or PyGame windows can be spawned by them).在我看来，你似乎把我放进单独的、独立的、松散耦合的插件中的所有代码放到了Core中的一个地方，它变得很难处理。
考虑将其分解为具有相同接口的各个部分(启动、停止，以及监控状态)，但只负责一项功能。大多数人可能只会与一到两个服务交谈，而且非常简单。
https://stackoverflow.com/questions/72239892
复制相似问题
腾讯云开发者
