10、构建Runnerly：从单体应用到微服务架构

构建Runnerly：从单体应用到微服务架构

1. 单体应用缺失的关键要素

要构建完整的单体解决方案，Runnerly还缺少两个关键部分：
- 后台任务 ：实现定期从Strava获取跑步数据并生成月度报告的代码。
- 认证与授权 ：让用户能够登录，并限制用户只能编辑自己的信息。

2. 后台任务的实现

从Strava获取新跑步数据并添加到Runnerly数据库的代码可以定期轮询Strava，例如每小时一次。月度报告也可以每月调用一次，生成报告并通过电子邮件发送给用户。这些功能都是Flask应用的一部分，并使用SQLAlchemy模型来完成工作。

与用户请求不同，这些是后台任务，需要在HTTP请求/响应周期之外独立运行。如果不使用简单的cron作业，在Python Web应用中运行重复性后台任务的一种流行方法是使用Celery（http://docs.celeryproject.org），它是一个分布式任务队列，可以在独立进程中执行某些工作。

要实现这一点，需要一个名为消息代理的中间件，负责在应用程序和Celery之间来回传递消息。例如，如果应用程序希望Celery运行某个任务，它会在代理中添加一条消息，Celery会轮询该消息并执行任务。

消息代理可以是任何能够存储消息并提供检索方式的服务。Celery项目可以直接与Redis（http://redis.io）、RabbitMQ（http://www.rabbitmq.com）和Amazon SQS（https://aws.amazon.com/sqs/）一起使用，并为Pyt