대규모 웹 애플리케이션의 구조를 구축하기 위한 Python의 Flask 프레임워크

Flask는 경량으로 알려진 프레임워크이지만 단위 테스트, 데이터베이스 마이그레이션 등 대규모 웹 애플리케이션에 편리한 기능도 많이 제공합니다. 여기서는 Python의 Flask 프레임워크를 사용하여 대규모 웹을 구축하는 방법을 살펴보겠습니다. 프로그램 구조의 예:

단일 스크립트는 소규모 웹 애플리케이션에 편리할 수 있지만 이 접근 방식은 확장성이 좋지 않습니다. 애플리케이션이 더욱 복잡해짐에 따라 단일 대용량 소스 파일 내에서 처리하는 것이 문제가 될 수 있습니다.

대부분의 다른 웹 프레임워크와 달리 Flask에는 대규모 프로젝트를 구성하는 구체적인 방법이 없습니다. 애플리케이션 구조는 전적으로 개발자에게 달려 있습니다. 이 장에서는 대규모 애플리케이션의 패키지와 모듈을 구성하고 관리하는 가능한 방법을 제시합니다. 이 구조는 이 책의 나머지 예제에서도 사용됩니다.

1. 프로젝트 구조

기본 다중 파일 Flask 응용 프로그램 구조 예시

rree

이것 구조 4개의 최상위 디렉터리가 있습니다.

• Flask 애플리케이션은 일반적으로 app이라는 디렉터리에 배치됩니다.

• migrations 디렉토리에는 앞서 언급한 것과 동일한 데이터베이스 마이그레이션 스크립트가 포함되어 있습니다.

• 단위 테스트는 테스트 디렉터리에 위치합니다.

• venv 디렉터리에는 앞서 언급한 것과 동일한 Python 가상 환경이 포함되어 있습니다.

몇 가지 새로운 파일도 있습니다.

• requirements.txt에는 다른 컴퓨터에 쉽게 설치할 수 있도록 일부 종속 패키지가 나열되어 있습니다. 동일한 가상 환경

• config.py는 일부 구성 설정을 저장합니다.

• manage.py는 애플리케이션 및 기타 애플리케이션 작업을 시작하는 데 사용됩니다.

이 구조에 대한 완전한 이해를 돕기 위해 다음에서는 이 구조에 맞게 hello.py 애플리케이션을 변경하는 전체 과정을 설명합니다.

2. 구성 옵션
애플리케이션에는 일반적으로 여러 구성 설정이 필요합니다. 가장 좋은 예는 개발 프로세스 중에 서로 간섭할 수 없도록 서로 다른 데이터베이스, 테스트 및 프로덕션 환경을 사용해야 한다는 것입니다.

hello.py에서 단순한 사전과 같은 구조 구성 대신 구성 클래스의 계층 구조를 사용할 수 있습니다. config.py 파일은 아래와 같습니다.

config.py: 애플리케이션 구성

|-flasky
 |-app/
  |-templates/
  |-static/
  |-main/
   |-__init__.py
   |-errors.py
   |-forms.py
   |-views.py
  |-__init__.py
  |-email.py
  |-models.py
 |-migrations/
 |-tests/
  |-__init__.py
  |-test*.py
 |-venv/
 |-requirements.txt
 |-config.py
 |-manage.py

Config 기본 클래스에는 일부 동일한 구성이 포함되어 있으며, 서로 다른 하위 클래스는 서로 다른 구성을 정의합니다. 필요한 경우 추가 구성을 추가할 수 있습니다.

보다 유연하고 안전한 구성을 위해 환경 변수에서 일부 설정을 가져올 수 있습니다. 예를 들어 SECRET_KEY는 민감도 때문에 환경에서 설정할 수 있지만 환경에서 정의되지 않은 경우 기본값을 제공해야 합니다.

SQLALCHEMY_DATABASE_URI 변수는 세 가지 구성에서 서로 다른 값을 할당할 수 있습니다. 이런 방식으로 애플리케이션은 각기 다른 데이터베이스를 사용하는 다양한 구성으로 실행될 수 있습니다.

구성 클래스는 애플리케이션 인스턴스를 매개변수로 사용하는 init_app() 정적 메서드를 정의할 수 있습니다. 여기에서 구성별 초기화가 가능합니다. 여기서 Config 기본 클래스는 빈 init_app() 메서드를 구현합니다.

구성 스크립트 하단에는 이러한 다양한 구성이 구성 사전에 등록되어 있습니다. 구성(개발 구성) 중 하나를 기본 구성으로 등록합니다.

3. 애플리케이션 패키지
애플리케이션 패키지에는 모든 애플리케이션 코드, 템플릿 및 정적 파일이 들어 있습니다. 간단히 app이라고 부르거나 원하는 경우 애플리케이션별 이름을 지정할 수 있습니다. 템플릿과 정적 디렉터리는 애플리케이션의 일부이므로 이 두 디렉터리는 앱에 배치되어야 합니다. 데이터베이스 모델 및 이메일 지원도 이 패키지에 내장되어 있으며 각각 app/models.py 및 app/email.py 형식의 자체 모듈에 있습니다.

3.1. 애플리케이션 팩토리 사용

단일 파일로 애플리케이션을 만드는 것은 매우 편리하지만 큰 단점이 있습니다. 애플리케이션은 전역 범위에서 생성되기 때문에 애플리케이션 구성의 변경 사항에 동적으로 적응할 수 있는 방법이 없습니다. 스크립트가 실행될 때 애플리케이션 인스턴스가 이미 생성되었으므로 구성을 변경하기에는 너무 늦습니다. 이는 단위 테스트에 특히 중요합니다. 때로는 더 나은 테스트 적용 범위를 얻기 위해 다양한 구성에서 애플리케이션을 실행해야 하기 때문입니다.

이 문제에 대한 해결책은 애플리케이션을 팩토리 함수에 넣어 생성을 연기하여 스크립트에서 명시적으로 호출할 수 있도록 하는 것입니다.

이는 스크립트에 구성을 설정하는 데 충분한 시간을 제공할 뿐만 아니라 애플리케이션의 여러 인스턴스를 생성하는 데에도 사용할 수 있어 테스트 중에 매우 유용합니다. 앱 패키지의 생성자에 정의된 애플리케이션 팩토리 함수는 예제 7-3에 나와 있습니다.

이 생성자는 현재 사용해야 하는 대부분의 확장을 가져오지만 이를 초기화할 애플리케이션 인스턴스가 없기 때문에 생성할 수는 있지만 생성자에 인수를 전달하지 않고도 초기화할 수는 없습니다. create_app()은 애플리케이션 팩토리 함수이며 애플리케이션에 사용되는 구성 이름을 전달해야 합니다. 구성의 설정은 config.py의 클래스에 저장되며 Flask app.config 구성 개체의 from_object() 메서드를 사용하여 직접 가져올 수 있습니다. 구성 개체는 개체 이름별로 구성 사전에서 선택할 수 있습니다. 애플리케이션이 생성되고 구성되면 확장을 초기화할 수 있습니다. 확장에서 init_app()을 호출하기 전에 초기화 작업을 생성하고 완료합니다.

app/ _init__.py：应用程序包构造函数_

from flask import Flask, render_template 
from flask.ext.bootstrap import Bootstrap 
from flask.ext.mail import Mail
from flask.ext.moment import Moment
from flask.ext.sqlalchemy import SQLAlchemy 
from config import config

bootstrap = Bootstrap()
mail = Mail()
moment = Moment()
db = SQLAlchemy()

def create_app(config_name):
  app = Flask(__name__) 
  app.config.from_object(config[config_name]) 
  config[config_name].init_app(app)
  
  bootstrap.init_app(app)
  mail.init_app(app)
  moment.init_app(app)
  db.init_app(app)

  # attach routes and custom error pages here
  
  return app

工厂函数返回创建的应用程序实例，但是请注意，在当前状态下使用工厂函数创建的应用程序是不完整的，因为它们没有路由和自定义错误页面处理程序。这是下一节的主题。

3.2、在蓝图中实现应用程序的功能

应用程序工厂的转化工作引出了路由的复杂化。在单脚本应用中，应用程序实例是全局的，所以可以很容易地使用app.route装饰器定义路由。但是现在应用程序在运行时创建，app.route装饰器只有在create_app()调用后才开始存在，这就太迟了。就像路由那样，这些通过app.errorhandler装饰器定义的自定义错误页面处理程序也存在同样的问题。

幸运的是Flask使用蓝图来提供一个更好的解决方案。一个蓝图就类似于一个可以定义路由的应用程序。不同的是，和路由相关联的蓝图都在休眠状态，只有当蓝图在应用中被注册后，此时的路由才会成为它的一部分。使用定义在全局作用域下的蓝图，定义应用程序的路由就几乎可以和单脚本应用程序一样简单了。

和应用程序一样，蓝图可以定义在一个文件或一个包中与多个模块一起创建更结构化的方式。为了追求最大的灵活性，可以在应用程序包中创建子包来持有蓝图。下面展示了创建蓝图的构造函数。

app/main/ _init__.py：创建蓝图_

from flask import Blueprint

main = Blueprint('main', __name__) 

from . import views, errors

蓝图是通过实例化Blueprint类对象来创建的。这个类的构造函数接收两个参数：蓝图名和蓝图所在的模块或包的位置。与应用程序一样，在大多数情况下，对于第二个参数值使用Python的__name__变量是正确的。

应用程序的路由都保存在app/main/views.py模块内部，而错误处理程序则保存在app/main/errors.py中。导入这些模块可以使路由、错误处理与蓝图相关联。重要的是要注意，在app/init.py脚本的底部导入模块要避免循环依赖，因为view.py和errors.py都需要导入main蓝图。

蓝图和应用程序一样注册在create_app()工厂函数中，如下所示。

示例 app/ _init__.py：蓝图注册_

def create_app(config_name): 
  # ...
  from .main import main as main_blueprint 
  app.register_blueprint(main_blueprint)

  return app

下面则展示了错误处理。

app/main/errors.py：蓝图的错误处理

from flask import render_template 
from . import main

@main.app_errorhandler(404) 
def page_not_found(e):
  return render_template('404.html'), 404

@main.app_errorhandler(500) 
def internal_server_error(e):
  return render_template('500.html'), 500

在蓝图中写错误处理的不同之处是，如果使用了errorhandler装饰器，则只会调用在蓝图中引起的错误处理。而应用程序范围内的错误处理则必须使用app_errorhandler。

这里展示了被更新在蓝图中的应用程序路由。

app/main/views.py：带有蓝图的应用程序路由

from datetime import datetime
from flask import render_template, session, redirect, url_for

from . import main
from .forms import NameForm 
from .. import db
from ..models import User

@main.route('/', methods=['GET', 'POST']) 
def index():
  form = NameForm()
  if form.validate_on_submit():
    # ...
    return redirect(url_for('.index')) 
  return render_template('index.html',
              form=form, name=session.get('name'),
              known=session.get('known', False),
              current_time=datetime.utcnow())

在蓝图中写视图函数有两大不同点。第一，正如之前的错误处理一样，路由装饰器来自于蓝图。第二个不同是url_for()函数的使用。你可能会回想，该函数的第一个参数为路由节点名，它给基于应用程序的路由指定默认视图函数。例如，单脚本应用程序中的index()视图函数的URL可以通过url_for('index')来获得。

不同的是Flask名称空间适用于来自蓝图的所有节点，这样多个蓝图可以使用相同节点定义视图函数而不会产生冲突。名称空间就是蓝图名（Blueprint构造函数中的第一个参数），所以index()视图函数注册为main.index且它的URL可以通过url_for('main.index')获得。

在蓝图中，url_for()函数同样支持更短格式的节点，省略蓝图名，例如url_for('.index')。有了这个，就可以这样使用当前请求的蓝图了。这实际意味着相同蓝图内的重定向可以使用更短的形式，如果重定向跨蓝图则必须使用带名称空间的节点名。

完成了应用程序页面更改，表单对象也保存在app/main/forms.py模块中的蓝图里面。

4、启动脚本
顶层目录中的manage.py文件用于启动应用。

manage.py：启动脚本

#!/usr/bin/env python
import os
from app import create_app, db
from app.models import User, Role
from flask.ext.script import Manager, Shell
from flask.ext.migrate import Migrate, MigrateCommand

app = create_app(os.getenv('FLASK_CONFIG') or 'default') 
manager = Manager(app)
migrate = Migrate(app, db)

def make_shell_context():
  return dict(app=app, db=db, User=User, Role=Role)

manager.add_command("shell", Shell(make_context=make_shell_context))
manager.add_command('db', MigrateCommand)

if __name__ == '__main__': 
  manager.run()

这个脚本开始于创建应用程序。使用环境变量FLASK_CONFIG，若它已经定义了则从中获取配置；如果没有，则是用默认配置。然后用于Python shell的Flask-Script、Flask-Migrate以及自定义上下文会被初始化。

为了方便，会增加一行执行环境，这样在基于Unix的操作系统上可以通过./manage.py来执行脚本来替代冗长的python manage.py。

5、需求文件
应用程序必须包含requirements.txt文件来记录所有依赖包，包括精确的版本号。这很重要，因为可以在不同的机器上重新生成虚拟环境，例如在生产环境的机器上部署应用程序。这个文件可以通过下面的pip命令自动生成：

(venv) $ pip freeze >requirements.txt

当安装或更新一个包之后最好再更新一下这个文件。以下展示了一个需求文件示例：

Flask==0.10.1
Flask-Bootstrap==3.0.3.1
Flask-Mail==0.9.0
Flask-Migrate==1.1.0
Flask-Moment==0.2.0
Flask-SQLAlchemy==1.0
Flask-Script==0.6.6
Flask-WTF==0.9.4
Jinja2==2.7.1
Mako==0.9.1
MarkupSafe==0.18
SQLAlchemy==0.8.4
WTForms==1.0.5
Werkzeug==0.9.4
alembic==0.6.2
blinker==1.3
itsdangerous==0.23

当你需要完美复制一个虚拟环境的时候，你可以运行以下命令创建一个新的虚拟环境：

(venv) $ pip install -r requirements.txt

当你读到这时，示例requirements.txt文件中的版本号可能已经过时了。如果喜欢你可以尝试用最近发布的包。如果遇到任何问题，你可以随时回退到需求文件中与应用兼容的指定版本。

6、单元测试
这个应用非常小以至于不需要太多的测试，但是作为示例会在示例中展示两个简单的测试定义。

示例：tests/test_basics.py：单元测试

import unittest
from flask import current_app 
from app import create_app, db

class BasicsTestCase(unittest.TestCase): 
  def setUp(self):
    self.app = create_app('testing')
    self.app_context = self.app.app_context()
    self.app_context.push()
    db.create_all()

  def tearDown(self): 
    db.session.remove() 
    db.drop_all() 
    self.app_context.pop()

  def test_app_exists(self): 
    self.assertFalse(current_app is None)

  def test_app_is_testing(self): 
    self.assertTrue(current_app.config['TESTING'])

编写好的测试使用的是来自于Python标准库中标准的unittest包。setUp()和tearDown()方法在每个测试之前和之后运行，且任何一个方法必须以test_开头作为测试来执行。

建议：如果你想要学习更多使用Python的unittest包来写单元测试的内容，请参阅官方文档。
setUp()方法尝试创建一个测试环境，类似于运行应用程序。首先它创建应用程序配置用于测试并激活上下文。这一步确保测试可以和常规请求一样访问current_app。然后，当需要的时候，可以创建一个供测试使用的全新数据库。数据库和应用程序上下文会在tearDown()方法中被移除。

第一个测试确保应用程序实例存在。第二个测试确保应用程序在测试配置下运行。为了确保tests目录有效，需要在tests目录下增加__init__.py文件，不过该文件可以为空，这样unittest包可以扫描所有模块并定位测试。

建议：如果你有克隆在GitHub上的应用程序，你现在可以运行git checkout 7a来切换到这个版本的应用程序。为了确保你已经安装了所有依赖集，需要运行pip install -r requirements.txt。
为了运行单元测试，可以在manage.py脚本中增加一个自定义的命令。

下面展示如何添加测试命令。

示例：manage.pyt：单元测试启动脚本

@manager.command
def test():
  """Run the unit tests."""
  import unittest
  tests = unittest.TestLoader().discover('tests') 
  unittest.TextTestRunner(verbosity=2).run(tests)

manager.command装饰器使得它可以很容易的实现自定义命令。被装饰的函数名可以被当做命令名使用，且函数的文档字符串会显示帮助信息。test()函数的执行会调用unittest包中的测试运行器。

单元测试可以像下面这样执行：

(venv) $ python manage.py test

test_app_exists (test_basics.BasicsTestCase) ... ok
test_app_is_testing (test_basics.BasicsTestCase) ... ok

.----------------------------------------------------------------------
Ran 2 tests in 0.001s

OK

7、数据库启动
与单脚本的应用相比，重构后的应用使用不同数据库。

从环境变量中获取的数据库URL作为首选，默认SQLite数据库作为可选。三个配置中的环境变量和SQLite数据库文件名是不一样的。例如，开发配置的URL是从DEV_DATABASE_URL环境变量中获取，如果没有定义则会使用名为data-dev.sqlite的SQLite数据库。

无论数据库URL源的是哪一个，都必须为新的数据库创建数据库表。如果使用了Flask-Migrate来保持迁移跟踪，数据库表可以被创建或更新到最近的版本通过下面的命令：

(venv) $ python manage.py db upgrade

相信与否，已经到了第一部分结束的地方。你现在已经学到了Flask必要的基本要素，但是你不确定如何将这些零散的知识组合在一起形成一个真正的应用程序。第二部分的目的是通过开发一个完整的应用程序来带领你继续前行。

更多Python的Flask框架构建大型Web应用程序的结构相关文章请关注PHP中文网！