From 85939b33aec6ba4d0b5d916548b0c3cddcdbc412 Mon Sep 17 00:00:00 2001 From: HexToString <506181616@qq.com> Date: Tue, 18 May 2021 12:52:13 +0000 Subject: [PATCH] add doc CREATE --- doc/CREATING.md | 395 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 doc/CREATING.md diff --git a/doc/CREATING.md b/doc/CREATING.md new file mode 100644 index 00000000..4c54d6dc --- /dev/null +++ b/doc/CREATING.md @@ -0,0 +1,395 @@ +# 从零开始写一个预测服务 + +## 1. 示例说明 + +图像分类是根据图像的语义信息将不同类别图像区分开来,是计算机视觉中重要的基本问题,也是图像检测、图像分割、物体跟踪、行为分析等其他高层视觉任务的基础。图像分类在很多领域有广泛应用,包括安防领域的人脸识别和智能视频分析等,交通领域的交通场景识别,互联网领域基于内容的图像检索和相册自动归类,医学领域的图像识别等。 + +本文接下来以图像分类任务为例,介绍从零搭建一个模型预测服务的步骤。 + +**本文件仅供参考,部分接口内容已经变动** + + +## 2. Serving端 + +### 2.1 定义预测接口 + +**添加文件:serving/proto/image_class.proto** +Paddle Serving服务端与客户端通过brpc进行通信,通信协议和格式可以自定,我们选择baidu_std协议。这是一种以protobuf为基本数据交换格式的协议,其说明可参考[BRPC文档: baidu_std](https://github.com/apache/incubator-brpc/blob/master/docs/cn/baidu_std.md)。 + + +我们编写图像分类任务预测接口的protobuf如下: + +```c++ +syntax="proto2"; +import "pds_option.proto"; +import "builtin_format.proto"; +package baidu.paddle_serving.predictor.image_classification; +option cc_generic_services = true; + +message ClassifyResponse { + repeated baidu.paddle_serving.predictor.format.DensePrediction predictions = 1; +}; + +message Request { + repeated baidu.paddle_serving.predictor.format.XImageReqInstance instances = 1; +}; + +message Response { + // Each json string is serialized from ClassifyResponse predictions + repeated baidu.paddle_serving.predictor.format.XImageResInstance predictions = 1; +}; + +service ImageClassifyService { + rpc inference(Request) returns (Response); + rpc debug(Request) returns (Response); + option (pds.options).generate_impl = true; +}; +``` + +其中: +`service ImageClassifiyService`定义一个RPC Service,并声明2个RPC接口:`inference`和`debug`,分别接受`Reqeust`类型请求参数,并返回`Response`类型结果。 + +`DensePrediction`, `XImageReqInstance`和`XImageResInstance`类型的消息分别在其他.proto文件中定义,因此要通过`import 'builtin_format.proto'`语句将需要的类型引入。 + +`generate_impl = true`: 告诉protobuf编译器,生成RPC service的实现 (在client端,此处为`generate_stub = true`,告诉protobuf编译器生成RPC的stub) + +### 2.2 Server端实现 + +图像分类任务的处理,设计分为3个阶段,对应3个OP +- 读请求:从Request消息解出请求样例数据 +- 调用Paddle预测lib的接口,对样例进行预测,并保存 +- 预测结果写到Response + +此后,框架将负责将Response回传给client端 + +#### 2.2.1 定制Op算子 + +**在serving/op/目录下添加reader_op.cpp, classify_op.cpp, write_json_op.cpp** + +- 预处理算子(ReaderOp, serving/op/reader_op.cpp):从Request中读取图像字节流,通过opencv解码,填充tensor对象并输出到channel; +- 预测调用算子(ClassifyOp, serving/op/classify_op.cpp):从ImageReaderOp的channel获得输入tensor,临时申请输出tensor,调用ModelToolkit进行预测,并将输出tensor写入channel +- 后处理算子(WriteJsonOp, serving/op/write_json.cpp):从ImageClassifyop的channel获得输出tensor,将其序列化为json字符串,写入作为rpc的output + +具体实现可参考demo中的源代码 + + +#### 2.2.2 示例配置 + +关于Serving端的配置的详细信息,可以参考[Serving端配置](SERVING_CONFIGURE.md) + +以下配置文件将ReaderOP, ClassifyOP和WriteJsonOP串联成一个workflow (关于OP/workflow等概念,可参考[设计文档](DESIGN_CN.md)) + +- 配置文件示例: + +**添加文件 serving/conf/service.prototxt** + +```shell +services { + name: "ImageClassifyService" + workflows: "workflow1" +} +``` + +**添加文件 serving/conf/workflow.prototxt** + +```shell +workflows { + name: "workflow1" + workflow_type: "Sequence" + nodes { + name: "image_reader_op" + type: "ReaderOp" + } + nodes { + name: "image_classify_op" + type: "ClassifyOp" + dependencies { + name: "image_reader_op" + mode: "RO" + } + } + nodes { + name: "write_json_op" + type: "WriteJsonOp" + dependencies { + name: "image_classify_op" + mode: "RO" + } + } +} +``` + +以下配置文件为模型加载配置 + +**添加文件 serving/conf/resource.prototxt** + +```shell +model_manager_path: ./conf +model_manager_file: model_toolkit.prototxt +``` + +**添加文件 serving/conf/model_toolkit.prototxt** + +```shell +engines { + name: "image_classification_resnet" + type: "FLUID_CPU_NATIVE_DIR" + reloadable_meta: "./data/model/paddle/fluid_time_file" + reloadable_type: "timestamp_ne" + model_data_path: "./data/model/paddle/fluid/SE_ResNeXt50_32x4d" + runtime_thread_num: 0 + batch_infer_size: 0 + enable_batch_align: 0 +} +``` + + +#### 2.2.3 代码编译 + +Serving端代码包含如下部分: +- protobuf接口文件,需要编译成.pb.cc及.pb.h文件并链接到最终可执行文件 +- OP算子实现,需要链接到最终可执行文件 +- Paddle serving框架代码,封装在libpdserving.a中,需要链接到最终可执行文件 +- Paddle serving封装paddle-fluid预测库的代码,在inferencer-fluid-cpu/目录产出的libfluid_cpu_engine.a中 +- 其他第三方依赖库:paddle预测库,brpc, opencv等 + +1) protobuf接口文件编译: 不能用protoc默认插件编译,需要编译成paddle serving定制的.pb.cc及.pb.h文件。具体命令是 +```shell +$ protoc --cpp_out=/path/to/paddle-serving/build/serving/ --pdcodegen_out=/path/to/paddle-serving/ --plugin=protoc-gen-pdcodegen=/path/to/paddle-serving/build/predictor/pdcodegen --proto_path=/path/to/paddle-serving/predictor/proto +``` +其中 +`pdcodegen`是由predictor/src/pdcodegen.cpp编译成的protobuf编译插件, --proto_path用来指定去哪里寻找`import`语句需要的protobuf文件 + +predictor/proto目录下有serving端和client端都要包含的builtin_format.proto和pds_option.proto + +**NOTE** +上述protoc命令在Paddle serving编译系统中被封装成一个CMake函数了,在cmake/generic.cmake::PROTOBUF_GENERATE_SERVING_CPP +CMakeLists.txt中调用函数的方法为: +```shell +PROTOBUF_GENERATE_SERVING_CPP(PROTO_SRCS PROTO_HDRS xxx.proto) +``` + +2) OP +serving/op/目录下OP对应的.cpp文件 + +3) Paddle Serving框架代码,封装在predictor目录产出的libpdserving.a中 + +4) Paddle Serving封装paddle-fluid预测库的代码,在inference-fluid-cpu/目录产出的libfluid_cpu_engine.a中 + +5) serving端main函数 + +为简化用户编写初始化代码的工作量,serving端必须的初始化过程已经由paddle Serving框架提供,请参考predictor/src/pdserving.cpp。该文件中包含了完整的初始化过程,用户只需提供合适的配置文件列表即可(请参考2.2.2节),不必编写main函数 + +6) 第三方依赖库 + +brpc, paddle-fluid, opencv等第三方库, + +7) 链接 + +整个链接过程在CMakeLists.txt中写法如下: +```shell +target_link_libraries(serving opencv_imgcodecs + ${opencv_depend_libs} -Wl,--whole-archive fluid_cpu_engine + -Wl,--no-whole-archive pdserving paddle_fluid ${paddle_depend_libs} + ${MKLML_LIB} ${MKLML_IOMP_LIB} -lpthread -lcrypto -lm -lrt -lssl -ldl -lz) + +``` + +### 2.3 gflags配置项 + +以下是serving端支持的gflag配置选项列表,并提供了默认值。 + +| name | 默认值 | 含义 | +|------|--------|------| +|workflow_path|./conf|workflow配置目录名| +|workflow_file|workflow.prototxt|workflow配置文件名| +|inferservice_path|./conf|service配置目录名| +|inferservice_file|service.prototxt|service配置文件名| +|resource_path|./conf|资源管理器目录名| +|resource_file|resource.prototxt|资源管理器文件名| +|reload_interval_s|10|重载线程间隔时间(s)| +|enable_model_toolkit|true|模型管理| +|enable_protocol_list|baidu_std|brpc 通信协议列表| +|log_dir|./log|log dir| +|num_threads|brpc server使用的系统线程数,默认为CPU核数| +|max_concurrency|并发处理的请求数,设为<=0则为不予限制,若大于0则限定brpc server端同时处理的请求数上限| + +可以通过在serving/conf/gflags.conf覆盖默认值,例如 +``` +--log_dir=./serving_log/ +``` +将指定日志目录到./serving_log目录下 + + +## 3. Client端 + +### 3.1 定义预测接口 + +**在sdk-cpp/proto添加image_class.proto** + +与serving端预测接口protobuf文件基本一致,只要将`generate_impl=true`改为`generate_stub=true` + +```c++ +import "pds_option.proto"; +... +service ImageClassifyService { + rpc inference(Request) returns (Response); + rpc debug(Request) returns (Response); + // 改动:打开generate_stub开关(以支持配置驱动) + option (pds.options).generate_stub = true; +}; +``` + +### 3.2 Client端逻辑 + +Paddle Serving提供的C++ SDK在sdk-cpp/目录中,入口为sdk-cpp/include/predictor_sdk.h中的`class PredictorApi`类。 + +该类的主要接口: +```C++ +class PredictroApi { + // 创建PredictorApi句柄,输入为client端配置文件predictor.prototxt的目录和文件名 + int create(const char *path, const char *file); + + // 线程级初始化 + int thrd_initialize(); + + // 根据名称获取Predictor句柄; ep_name对应predictor.prototxt中predictors的name字段 + Predictor *fetch_predictor(std::string ep_name); +}; + +class Predictor { + // 预测 + int inference(google::protobuf::Message *req, google::protobuf::Message *res); + + // Debug模式 + int debug(google::protobuf::Message *req, + google::protobuf::Message *res, + buitl::IOBufBuilder *debug_os); +}; +``` + +#### 3.2.1 请求逻辑 + +**增加sdk-cpp/demo/ximage.cpp** + +```c++ +// 进程级初始化 +PredictorApi api; + +if (api.create("./conf/", "predictors.prototxt") == 0) { + return -1; +} + +// 线程级预测调用: +Request req; +Response res; + +api.thrd_initialize(); + +// Call this before every request +api.thrd_clear(); + +create_req(&req); + +Predictor* predictor = api.fetch_predictor("ximage"); +if (predictor == NULL) { + return -1; +} + +if (predictor->inference(req, res) != 0) { + return -1; +} + +// parse response +print_res(res); + +// 线程级销毁 +api.thrd_finalize(); + +// 进程级销毁 +api.destroy(); +``` + +具体实现可参考paddle Serving提供的例子sdk-cpp/demo/ximage.cpp + +### 3.3 链接 + +Client端可执行文件包含的代码有: +- protobuf接口文件,需要编译成.pb.cc及.pb.h文件并链接到最终可执行文件 +- main函数,以及调用SDK接口访问预测服务的逻辑,见3.2.1节 +- Client端读取并维护predictor信息列表的代码,在sdk-cpp/目录产出的libsdk-cpp.a +- 因为protobuf接口文件用到了predictor/proto/目录下的builtin_format.proto和pds_option.proto,因此还需要联编libpdserving.a + +1) protobuf接口文件,同serving端,需要用predictor/src/pdcodegen.cpp产出的pdcodegen插件,配合protoc使用,具体命令为 +```shell +$ protoc --cpp_out=/path/to/paddle-serving/build/serving/ --pdcodegen_out=/path/to/paddle-serving/ --plugin=protoc-gen-pdcodegen=/path/to/paddle-serving/build/predictor/pdcodegen --proto_path=/path/to/paddle-serving/predictor/proto +``` +其中 +`pdcodegen`是由predictor/src/pdcodegen.cpp编译成的protobuf编译插件, --proto_path用来指定去哪里寻找`import`语句需要的protobuf文件 + +**NOTE** +上述protoc命令在Paddle Serving编译系统中被封装成一个CMake函数了,在cmake/generic.cmake::PROTOBUF_GENERATE_SERVING_CPP +CMakeLists.txt中调用函数的方法为: +```shell +PROTOBUF_GENERATE_SERVING_CPP(PROTO_SRCS PROTO_HDRS xxx.proto) +``` +2) main函数,以及调用SDK接口访问预测服务的逻辑 + +3) Client端读取并维护predictor信息列表的代码,在sdk-cpp/目录产出的libsdk-cpp.a + +4) predictor/目录产出的libpdserving.a + +最终链接命令如下: + +```shell +add_executable(ximage ${CMAKE_CURRENT_LIST_DIR}/demo/ximage.cpp) +target_link_libraries(ximage -Wl,--whole-archive sdk-cpp + -Wl,--no-whole-archive pdserving -lpthread -lcrypto -lm -lrt -lssl -ldl + -lz) + +``` + +### 3.4 连接配置 + +**增加配置文件sdk/conf/predictors.prototxt** + +```shell +## 默认配置共享 +default_variant_conf { + tag: "default" + connection_conf { + connect_timeout_ms: 2000 + rpc_timeout_ms: 20000 + connect_retry_count: 2 + max_connection_per_host: 100 + hedge_request_timeout_ms: -1 + hedge_fetch_retry_count: 2 + connection_type: "pooled" + } + naming_conf { + cluster_filter_strategy: "Default" + load_balance_strategy: "la" + } + rpc_parameter { + compress_type: 0 + package_size: 20 + protocol: "baidu_std" + max_channel_per_request: 3 + } +} +predictors { + name: "ximage" + service_name: "baidu.paddle_serving.predictor.image_classification.ImageClassifyService" + endpoint_router: "WeightedRandomRender" + weighted_random_render_conf { + variant_weight_list: "50" + } + variants { + tag: "var1" + naming_conf { + cluster: "list://127.0.0.1:8010" + } + } +} +``` +关于客户端的详细配置选项,可参考[CLIENT CONFIGURATION](CLIENT_CONFIGURE.md) -- GitLab