为何选择了 FastAPI 和 gRPC？
我们团队内部早期使用的 Django 开发的海外金融产品，后续考虑转型到微服务架构，做了一些调研之后，决定选择 FastAPI 和 gRPC。
FastAPI
完全从异步IO思维整合出来的框架，在 Web 领域异步IO的意义比较大。基于 Encode 团队（开发过大名鼎鼎的 Django REST Framework）的新作品：Starlette。
gRPC
在 RPC 之块，Python 还有一个有名的框架 nameko，团队之前使用过，由于国内使用率不高，遇到问题时，难以解决方案，虽然 nameko 的 API 非常优雅，最终还是求稳地选择了 gRPC。gRPC 在云原生时代也是一个标配，流行度上有保证。
落地实践
简单地了解了一些 DDD 思维后，团队就拍着脑袋开始拆分服务啦。总共拆分了 8 个服务，每个服务同时提供 HTTP/RPC 服务。
类 Flask 框架的 FastAPI，拥有微框架的灵活性，但也是这种灵活性，让团队技术水平并不统一的开发者写出了各式各式的项目结构，交叉维护项目的时候，非常头痛。于是团队内部为了统一及简化 FastAPI & gRPC 的开发，迭代出了一个整合的框架：bali，业务代码分布为在两个层次：Model 层和 Resource 层。Model 层是一个 Fat Model 模型，除了字段定义，还有与 Model 相关的一些逻辑；Resource 层提供同时兼容 HTTP/RPC 的资源服务。遵循 RESTful 及 gRPC 的开发指南定义了几个标准方法。
# 注意 bali 框架在 pipy 仓库里面的名称是：bali-core
pip install bali-core
项目结构
这里只涂两个服务作为实践例子，用户服务（user）和订单服务（order），每个服务都是一个独立的 repo，有个独立的 proto repo 专门用来存放 gRPC 需要使用的 protobuf。
# user repo
├── user
│ ├── Dockerfile
│ ├── README.md
│ ├── clients
│ │ ├── __init__.py
│ │ ├── _config.py
│ │ ├── _utils.py
│ │ ├── intermediates
│ ├── core
│ │ ├── config.py
│ │ ├── constants
│ │ ├── environment.py
│ │ ├── logging.py
│ ├── main.py
│ ├── models
│ │ ├── __init__.py
│ │ ├── user.py
│ ├── requirements.txt
│ ├── requirements_dev.txt
│ ├── resources
│ │ ├── __init__.py
│ │ ├── user.py
│ ├── schemas
│ │ ├── __init__.py
│ │ ├── user.py
│ ├── services
│ │ ├── __init__.py
│ │ ├── db.py
│ │ ├── http
│ │ │ ├── users.py
│ │ └── rpc
│ │ ├── service.py
│ ├── tests
│ │ ├── __init__.py
│ │ ├── test_models
│ │ ├── test_resources
│ │ └── test_services
# order repo
├── user
│ ├── Dockerfile
│ ├── README.md
│ ├── clients
│ │ ├── __init__.py
│ │ ├── _config.py
│ │ ├── _utils.py
│ │ ├── intermediates
│ ├── core
│ │ ├── config.py
│ │ ├── constants
│ │ ├── environment.py
│ │ ├── logging.py
│ ├── main.py
│ ├── models
│ │ ├── __init__.py
│ │ ├── user.py
│ ├── requirements.txt
│ ├── requirements_dev.txt
│ ├── resources
│ │ ├── __init__.py
│ │ ├── user.py
│ ├── schemas
│ │ ├── __init__.py
│ │ ├── user.py
│ ├── services
│ │ ├── __init__.py
│ │ ├── db.py
│ │ ├── http
│ │ │ ├── users.py
│ │ └── rpc
│ │ ├── service.py
│ ├── tests
│ │ ├── __init__.py
│ │ ├── test_models
│ │ ├── test_resources
│ │ └── test_services
# proto repo
proto
├── order
│ └── order.proto
└── user
└── user.proto
可以看出，微服务的结构是基本一致的，user 服务和 order 服务的业务主要存放在 Models 和 Resources。
HTTP 服务
# user/services/http/users.py
@router.get("/users/", response_model=UserSchema)
def get_users(
*,
channel : str = Header(None),
) -> Any:
return User.get_users()
这是 FastAPI 的自带的 route 定义方式，bali 是兼容的。
# user/resources/user.py
class UserResource(Resource):
schema = UserSchema
@action()
def custome_users(self, schema_in):
User.get_customer_users()
Resouce 的方式，同时支持 HTTP、RPC。通用的 action 比如 GetUsers 不需要在 Resource 里面定义，已经在 Resource 基类里面实现了。
启动 HTTP 服务：
python main.py --http
RPC 服务
- 定义 protobuf 文件
# user/services/rpc/user.proto
编译 proto 文件，按 gRPC 官方提供的方法：
$ python -m grpc_tools.protoc -I../../protos --python_out=. --grpc_python_out=. ../../protos/user.proto
而使用 bali-cli（bali 框架配套的 cli 工具），只需要在项目根目录执行：
pip install bali-cli
bali build
再配合 CI/CD，user 服务的 user.proto 会自动添加到 proto repo 里面。
- gRPC 实现服务
# user/services/rpc/service.py
class UserService(user_pb2_grpc.UserServiceServicer):
def GetUsers(self, request, context):
return UserResource(request, context, pb2.UserResponse).get_users()
def serve():
port = 5000
server = grpc.server(
futures.ThreadPoolExecutor(max_workers=50),
interceptors=[ProcessInterceptor()],
)
user_pb2_grpc.add_UserServiceServicer_to_server(UserService(), server)
server.add_insecure_port(f'[::]:{port}')
server.start()
logger.info("Service started on port: %s (env: %s)", port, ENV)
server.wait_for_termination()
由于 get_users 是一个标准通用的 action，所以在 Resource 里面都不用自己实现，定义好 Model、Schema 就可以直接使用了。
启动 RPC 服务：
python main.py --rpc
- gRPC 实现服务
在 order 服务里面调用 user 服务，只需要使用 bali add {service} 命令即可在 order 项目，创建一个 clients 需要的所有文件。
bali add user
在代码里面调用
from clients import UserClient
users = UserClient().get_users()
项目总结
gRPC 确实是未来一个方向，简单、跨语言。而且云原生的 service mesh 都默认支持 gRPC，比如 Linkerd。微服务场景下的网关产品也都对 gRPC 默认支持。
业务代码放哪里这个问题在所有项目里面都会成为一个话题，bali 框架只有两层，Model 和 Resource，开发微服务就不用思考太多东西，效率会高。一套代码，同时兼容 HTTP 和 RPC 服务。
