简介本资源是一份面向云原生开发者、架构师及技术决策者的Serverless架构深度实践指南聚焦解决方案落地系统梳理其在实时数据处理、微服务、事件驱动、IoT与AI/ML等典型场景中的应用逻辑与实施路径。文档完整覆盖FaaS平台选型、函数粒度设计、事件驱动建模、Serverless数据库集成、监控日志体系构建等五大核心最佳实践并针对性指出状态管理、安全合规等关键风险点与应对策略。资源为单文件PDF格式共1个1.85MB的高质量技术文档内容结构清晰、术语规范适合作为架构演进参考手册或团队内部技术分享材料。目前已有216人学习下载读者可直接获取开箱即用的架构方法论、主流云厂商AWS/Azure/GCP服务对照要点及可复用的设计原则清单。1. Serverless 架构不是“不用服务器”而是把资源调度权交给平台它真正解决的是「冷启动抖动、突发流量压垮实例、运维成本吃掉 30% 开发工时」这三类高频翻车现场你写完一个用户注册接口本地跑通、测试通过、CI/CD 流水线绿了——结果上线第一天凌晨两点营销活动推送触发百万级并发注册请求K8s 集群自动扩到 42 个 Pod但其中 17 个因内存超限被 OOMKilled运维半夜爬起来调 HPA 参数开发在 Slack 里疯狂 SRE 查日志而业务方只问一句“注册失败率怎么又飙到 12%”Serverless 架构不是魔法但它把这类问题的解法从「人盯指标 手动扩缩容 猜阈值」变成「声明式定义函数入口 平台自动伸缩 按毫秒计费」。它不适用于长时任务如视频转码超过 15 分钟、强状态依赖如需共享内存缓存、或对冷启动延迟敏感的实时交易系统如高频期权报价但对事件驱动型场景——Webhook 接收、IoT 设备上报解析、定时数据清洗、API 网关后端聚合、甚至 CI/CD 中的构建触发器——它能砍掉 60% 以上的基础设施维护时间。本文面向已用过 Docker 和基础云服务如 AWS EC2 / 阿里云 ECS的中级开发者不讲 FaaS 抽象概念只拆什么场景必须上 Serverless、怎么用 Terraform 在阿里云 FC 上 5 分钟搭出可监控的 HTTP 函数、为什么你的函数总在第 3 次调用才热、以及如何用本地 Mock 绕过平台黑匣子调试。所有命令、配置、参数均基于 2024 年主流云厂商阿里云函数计算 FC、AWS Lambda、腾讯云 SCF当前稳定版实测无虚构版本号。2. 选型不是比哪家控制台好看而是看「事件源绑定能力」「运行时生命周期控制粒度」和「VPC 内网穿透成本」Serverless 不是银弹但它是特定问题的手术刀。很多团队踩坑源于把「能跑通 Hello World」等同于「适合生产」。我见过三个典型误判用 Lambda 处理单次耗时 8 分钟的 PDF 合并任务超时失败在 FC 上部署含require(child_process)的 Python 函数调用 FFmpeg沙箱禁用 fork为一个日均 200 次调用的内部审批 API 上 Serverless固定成本反超 ECS这些都不是技术不行而是没对齐架构约束。下面按真实落地优先级拆解选型核心维度。2.1 事件源决定架构生死别让函数卡在「等消息」上Serverless 的价值起点是「事件驱动」。函数本身无状态它的生命周期由事件触发——HTTP 请求、对象存储上传、消息队列投递、定时器唤醒。事件源的可靠性、延迟、重试机制直接决定函数是否可用。例如事件源类型阿里云 FC 支持AWS Lambda 支持腾讯云 SCF 支持关键约束说明HTTP API✅FC 自带✅API Gateway✅API 网关FC 默认 60s 超时Lambda 最长 15mSCF 为 300s超时需拆成异步链路OSS 对象创建事件✅原生✅S3 Event✅COS 通知FC 支持前缀/后缀过滤Lambda 需 S3 事件规则SCF 需 COS Topic 订阅Kafka 消息⚠️需 FCMSK✅MSK 触发器⚠️需 SCFCKafkaFC 原生不支持 Kafka需通过 MSK消息队列 Kafka 版桥接Lambda 可直连 MSK但需 VPC 配置定时任务Cron✅FC Timer✅EventBridge✅SCF TimerFC Timer 精度为分钟级Lambda EventBridge 支持秒级SCF Timer 最小间隔 1 分钟MQTT 主题消息❌不原生⚠️IoT Core 触发❌不原生FC 无 MQTT 原生触发器需 IoT 平台转发至 FC HTTP 入口Lambda 可直连 IoT Core 规则引擎提示如果你的系统重度依赖 RabbitMQ 或自建 RocketMQ别硬套 Serverless。先评估消息中间件能否升级为云托管服务如阿里云 MNS、AWS SQS再考虑函数消费。强行用轮询拉取消息既浪费调用次数又增加冷启动频率。2.2 运行时生命周期不是所有语言都能“热”起来Serverless 平台对运行时有严格管控。以阿里云 FC 为例其 Python 运行时python3.9默认限制如下最大执行时间同步调用 60 秒异步调用 600 秒需显式开启异步模式内存范围128MB ~ 3008MB按 64MB 步进内存越大CPU 配额线性提升非线性128MB 时 CPU ≈ 0.1 核1024MB 时 ≈ 0.5 核临时磁盘空间/tmp目录最大 512MB函数退出即清空环境变量大小单个 ≤ 4KB总量 ≤ 16KB启动超时函数初始化import global code必须在 10 秒内完成否则报FunctionInitializationTimeout。这意味着若你用pandasnumpy做数据清洗不要import pandas as pd放在 handler 内——每次调用都重载冷启动飙升应提至模块顶层若需加载 200MB 模型文件别放/tmp会爆应存 OSS首次调用下载到/tmp并os.path.exists()缓存判断若用multiprocessingFC 会静默忽略沙箱无 fork 权限改用concurrent.futures.ThreadPoolExecutor。2.3 VPC 内网穿透不是加个 VPC ID 就能连 RDS这是 Serverless 最隐蔽的成本黑洞。函数默认在平台 VPC 内运行要访问企业内网数据库如 RDS、Redis必须配置 VPC 绑定。但不同厂商实现差异极大阿里云 FC需指定vpcId、vSwitchIds交换机、securityGroupIds函数启动后分配私网 IP走 ENI弹性网卡接入 VPC注意每个函数独立 ENI若同时起 100 个实例会占用 100 个私网 IP 和 100 条路由表项AWS Lambda需配置subnetIds和securityGroupIdsLambda 实例复用 ENI但高并发下仍可能触发VPCResourceLimitExceeded错误腾讯云 SCFVPC 绑定后函数通过 NAT 网关访问内网不分配私网 IP但所有流量经 NAT带宽成为瓶颈。实测对比连接同一 RDS 实例100 并发FC平均延迟 42ms峰值时 RDS 连接数达 120ENI 独立连接Lambda平均延迟 38ms但第 3 次扩容时出现 5% 调用超时ENI 创建延迟SCF平均延迟 67msNAT 带宽打满后丢包率 18%。血泪经验VPC 场景下务必在函数内实现连接池复用如 Python 的pymysql.connections.Connection复用而非每次connect()。FC 提供fc_runtimeSDK 的get_instance_id()可用于区分实例做本地缓存但别依赖——实例可能随时销毁。3. 用 Terraform 在阿里云 FC 上 5 分钟搭出可监控的 HTTP 函数从零到告警闭环别信“点点鼠标就上线”。生产级 Serverless 必须 IaCInfrastructure as Code化否则无法审计、回滚、复现。以下是以阿里云函数计算FC为例用 Terraform v1.5 搭建一个带日志、监控、API 网关的 Python 函数全流程。所有代码均可直接terraform apply运行需提前配置阿里云 AccessKey。3.1 初始化项目结构与 Provider 配置# main.tf terraform { required_version 1.5.0 required_providers { alicloud { source aliyun/alicloud version ~ 1.220.0 # 2024 Q2 稳定版 } } } provider alicloud { region cn-shanghai access_key var.access_key secret_key var.secret_key }# variables.tf variable access_key { description Aliyun AccessKey ID type string } variable secret_key { description Aliyun AccessKey Secret type string sensitive true } variable function_name { description Function name, e.g. user-register-handler type string default user-register-handler }逻辑说明Terraform Provider 版本锁死是关键。阿里云 FC 的alicloud_fc_function资源在 v1.210.0 后新增timeout字段校验旧版会忽略导致超时失败。sensitive true防止密钥打印到 stdout。3.2 创建函数服务、角色与执行权限# fc.tf resource alicloud_fc_service default { name ${var.function_name}-service description Service for ${var.function_name} # 日志服务集成自动创建 Logstore 并投递函数日志 log_config { project_name fc-logs log_store_name function-execution } } # 创建函数执行角色RAM Role授予写入日志、访问 OSS、RDS 等权限 resource alicloud_ram_role fc_role { name ${var.function_name}-role document data.alicloud_ram_role_policy_document.fc_assume_role_policy.json description RAM role for FC function execution } data alicloud_ram_role_policy_document fc_assume_role_policy { statement { effect Allow principals { service [fc.aliyuncs.com] } } } # 附加权限策略最小权限原则 resource alicloud_ram_role_policy_attachment fc_log_write { policy_name AliyunLogFullAccess policy_type System role_name alicloud_ram_role.fc_role.name } resource alicloud_ram_role_policy_attachment fc_oss_read { policy_name AliyunOSSReadOnlyAccess policy_type System role_name alicloud_ram_role.fc_role.name }参数说明log_config是 Serverless 监控的生命线。不配此块函数日志将丢失排查等于盲人摸象AliyunLogFullAccess是必要权限但生产环境应替换为自定义策略仅允许写入指定 Project/LogstoreAliyunOSSReadOnlyAccess仅为示例实际按需附加AliyunRDSReadOnlyAccess或自定义策略。3.3 定义函数代码、触发器与 API 网关# 函数代码打包为 zip本地路径 resource alicloud_fc_function handler { service_name alicloud_fc_service.default.name name var.function_name description Handle user registration event runtime python3.9 handler index.handler # 入口函数index.py 中的 handler 方法 memory_size 512 # 单位 MB平衡性能与成本 timeout 30 # 单位秒HTTP 场景建议 ≤ 30s initializer index.initializer # 初始化函数只在实例冷启动时执行一次 initialization_timeout 10 # 初始化超时必须 ≤ 10s oss_bucket my-code-bucket oss_key functions/${var.function_name}.zip # 代码包存 OSSFC 从 OSS 拉取 role alicloud_ram_role.fc_role.arn environment_variables { DB_HOST rm-xxxxxx.mysql.rds.aliyuncs.com DB_NAME user_db } } # HTTP 触发器绑定 API 网关 resource alicloud_fc_trigger http_trigger { service_name alicloud_fc_service.default.name function_name alicloud_fc_function.handler.name trigger_type http trigger_name http-trigger invocation_role alicloud_ram_role.fc_role.arn trigger_config jsonencode({ authType ANONYMOUS methods [POST] }) } # API 网关暴露公网 URL resource alicloud_api_gateway_api register_api { name ${var.function_name}-api description User registration API visibility PUBLIC request_config { method POST path /v1/register } service_config { service_type FUNCTION_COMPUTE function_compute { region_id cn-shanghai service_name alicloud_fc_service.default.name function_name alicloud_fc_function.handler.name version LATEST } } # 启用流控防止突发流量打垮函数 throttling { max_calls_per_minute 1000 } }逻辑说明initializer是冷启动优化核心。把数据库连接、模型加载、配置解析等一次性操作放这里避免每次 handler 都重复oss_bucketoss_key强制要求代码包存 OSS而非 inline code —— FC 对 inline 代码大小限制为 3MB而实际项目常超throttling是防雪崩底线。不设流控营销活动瞬间 10 万 QPS函数会因并发超限返回 429而非优雅降级。3.4 部署后验证与监控配置部署完成后Terraform 输出 API 网关地址$ terraform output api_endpoint https://xxxxxx.cn-shanghai.alicloudapi.com/v1/register用 curl 测试curl -X POST \ https://xxxxxx.cn-shanghai.alicloudapi.com/v1/register \ -H Content-Type: application/json \ -d {username:test,email:testexample.com}监控必须立刻跟上登录 阿里云日志服务 SLS 进入fc-logsProject →function-executionLogstore创建仪表盘添加关键指标status: 5xx错误率duration 2000慢调用毫秒invocationCount每分钟调用数观察波峰设置告警当5xx error rate 1%持续 5 分钟通知钉钉群。避坑初学者常忽略initializer的异常捕获。若 initializer 报错如 DB 连接失败函数实例会直接销毁后续调用全部FunctionInitializationTimeout。务必在 initializer 中try...except并打日志# index.py def initializer(context): import logging logger logging.getLogger() try: # 初始化 DB 连接 global db_conn db_conn create_db_connection() logger.info(DB connection initialized successfully) except Exception as e: logger.error(fInitializer failed: {str(e)}) raise e # 必须抛出让 FC 重建实例4. 冷启动为什么总在第 3 次调用才“热”—— 解析实例复用、预热与预留实例的底层逻辑冷启动不是 Bug是 Serverless 的物理定律。但很多人把它当成玄学调大内存、换语言、加缓存都试了还是“第一次慢、第二次快、第三次又慢”。这不是你的代码问题是没理解平台实例调度的三层机制实例复用窗口、预热触发时机、预留实例的保活逻辑。4.1 实例复用窗口不是“一直热”而是“热 10 分钟”Serverless 平台不会永久保留函数实例。FC/Lambda/SCF 均采用“空闲超时”策略FC实例空闲 10 分钟后回收不可配置Lambda空闲 15 分钟后回收不可配置SCF空闲 5 分钟后回收不可配置。这意味着若函数每 8 分钟被调用一次实例永远不回收全程“热”若调用间隔为 12 分钟每次都是冷启动若调用呈脉冲式如每小时整点触发则整点前 10 分钟内调用是热的之后全冷。验证方法在函数中打印context.invoked_function_arn和time.time()import time def handler(event, context): print(fInstance ARN: {context.invoked_function_arn}) print(fTimestamp: {time.time()}) return {status: ok}连续调用 3 次观察 ARN 是否变化。若变化说明实例已回收。4.2 预热不是“提前调用”而是“维持心跳”很多团队用 Cron 每 5 分钟调用一次函数“保持热态”。这看似有效实则危险每次预热调用都产生费用哪怕返回 200若预热请求未覆盖所有函数版本如灰度发布新版本老版本实例仍会回收预热请求若失败网络抖动实例照样凉。正确做法是用平台原生预热FC 支持Provisioned Concurrency预留并发指定 N 个实例常驻不随空闲超时回收Lambda 支持Provisioned Concurrency和SnapStart仅 JavaSCF 支持Reserved Instances预留实例。以 FC 为例配置 3 个预留实例# provision.tf resource alicloud_fc_provision_config default { service_name alicloud_fc_service.default.name function_name alicloud_fc_function.handler.name qualifier LATEST # 或指定版本 $LATEST / alias target 3 # 保持 3 个实例常驻 }参数说明qualifier必须指定否则预热无效LATEST指向最新版本alias指向别名如prod推荐用别名避免误触target 3表示 FC 保证至少 3 个实例处于 ready 状态即使 10 分钟空闲也不回收预留实例按小时计费FC 为 0.00012 元/实例/小时远低于冷启动失败带来的业务损失。4.3 预留实例 ≠ 100% 热启动还有“初始化延迟”这一关即使开了预留实例首次调用仍可能慢——因为实例虽在但initializer还没执行。FC 的预留实例流程是实例创建分配内存、网络加载代码包从 OSS 下载 ZIP解压执行initializer此时才建立 DB 连接、加载模型等待 handler 调用。步骤 3 是串行阻塞的。若initializer耗时 8 秒预留实例的“热”要从第 8 秒开始算。优化方案把initializer拆成两阶段第一阶段快速返回如只做环境检查第二阶段异步加载用threading.Thread启动后台加载handler 中while not loaded: time.sleep(0.1)等待或用fc_runtimeSDK 的get_remaining_time_in_millis()动态判断剩余时间超时则跳过加载走降级逻辑。import threading import time loaded False load_lock threading.Lock() def background_loader(): global loaded try: # 模拟耗时加载 time.sleep(5) with load_lock: loaded True except Exception as e: print(fBackground load failed: {e}) def initializer(context): # 启动后台加载不阻塞 initializer t threading.Thread(targetbackground_loader) t.daemon True t.start() def handler(event, context): # 等待加载完成最多等 3 秒 start time.time() while not loaded and time.time() - start 3: time.sleep(0.1) if not loaded: return {error: model not ready, using fallback} return {result: processed}避坑现象开了预留实例但监控显示Duration仍有 2000ms 波动原因initializer中做了同步网络请求如调用 Config Center该请求超时或慢拖慢整个实例就绪解决initializer内所有网络请求必须设timeout2并try...except捕获失败则记录 warn 日志不中断初始化现象预留实例数设为 5但高峰期仍有冷启动日志原因预留数 峰值并发超出部分仍需冷启动解决用alicloud_fc_provision_config的target结合历史InvocationCount曲线设置target peak_qps * 1.2预留 20% 冗余现象函数在 VPC 内预留实例启动后无法连接 RDS原因VPC ENI 创建需时间预留实例启动时 ENI 未就绪解决在initializer中加time.sleep(2)等待网络就绪或用socket.create_connection((host, port), timeout5)主动探测。5. 本地 Mock 调试绕过平台黑匣子用fun local invoke和sam local invoke实现 90% 真实环境复现线上函数报错日志只有一行Runtime exited abnormally你不可能登录 FC 控制台 debug。Serverless 的调试困境在于你写的代码在黑匣子里跑而黑匣子不给你 shell。解决方案不是放弃本地调试而是用云厂商提供的 CLI 工具在本地模拟运行时环境。这不是“伪调试”而是生产级验证闭环。5.1 阿里云 FC用funCLI 模拟完整生命周期fun是阿里云官方工具支持local invoke本地调用、local start本地启 HTTP 服务、build构建部署包。安装与初始化# 安装 fun需 Node.js 14 npm install -g alicloud/fun # 初始化项目生成 template.yml fun init --runtime python3.9 --name user-register # 目录结构 . ├── index.py # 函数代码 ├── requirements.txt # 依赖 ├── template.yml # Fun 配置类似 serverless.yml └── events/ # 测试事件 └── http.json # HTTP 触发事件样例template.yml关键配置ROSTemplateFormatVersion: 2015-09-01 Transform: Aliyun::Serverless-2018-04-03 Resources: RegisterService: Type: Aliyun::Serverless::Service Properties: Description: User registration service RegisterFunction: Type: Aliyun::Serverless::Function Properties: Handler: index.handler Runtime: python3.9 CodeUri: ./ EnvironmentVariables: DB_HOST: localhost # 本地用 Docker Compose 启 RDS Timeout: 30本地调用 HTTP 函数模拟 API 网关触发# 准备本地测试事件events/http.json { path: /v1/register, httpMethod: POST, headers: {Content-Type: application/json}, body: {\username\:\test\,\email\:\testexample.com\} } # 执行本地调用 fun local invoke RegisterService/RegisterFunction -e events/http.jsonfun会自动安装requirements.txt依赖到.fun/python/lib启动一个轻量沙箱注入context对象含get_remaining_time_in_millis()模拟initializer→handler生命周期输出完整日志包括initializer报错堆栈。逻辑说明fun local invoke不是简单python index.py它复现了 FC 的运行时约束sys.path包含/code代码根目录和/code/.fun/python/lib依赖目录os.environ注入FC_ACCESS_KEY_ID等环境变量若配置了~/.fcli/configcontext对象提供function_name、memory_limit_in_mb、remaining_time_in_millis等字段与线上一致。5.2 AWS Lambda用sam local invoke复现 IAM 权限与 VPC 行为SAMServerless Application Model是 AWS 官方框架。sam local invoke可模拟 Lambda 运行时且支持--docker-network连接本地 Docker 网络完美测试 VPC 场景。# sam init 创建项目 sam init --runtime python3.9 --name user-register # 修改 template.yaml添加 VPC 配置 Resources: RegisterFunction: Type: AWS::Serverless::Function Properties: CodeUri: hello_world/ Handler: index.handler Runtime: python3.9 VpcConfig: SecurityGroupIds: [sg-0abcdef1234567890] SubnetIds: [subnet-0123456789abcdef0, subnet-0123456789abcdef1]启动本地 Docker 网络模拟 VPC# 创建自定义网络模拟 Lambda VPC docker network create lambda-vpc # 启动本地 MySQL模拟 RDS docker run -d \ --name mysql-local \ --network lambda-vpc \ -e MYSQL_ROOT_PASSWORDpass \ -p 3306:3306 \ -d mysql:8.0 # 本地调用指定网络并传入事件 sam local invoke RegisterFunction \ --event events/register.json \ --docker-network lambda-vpc \ --env-vars env.jsonenv.json定义本地环境变量{ RegisterFunction: { DB_HOST: mysql-local, DB_USER: root, DB_PASS: pass } }参数说明--docker-network lambda-vpc让 SAM 容器加入同一网络函数内socket.gethostbyname(mysql-local)能解析--env-vars注入环境变量覆盖template.yaml中的Environmentsam local invoke使用lambci/lambda:python3.9镜像与线上 Lambda 运行时完全一致包括 glibc 版本、openssl。5.3 腾讯云 SCF用tencent-scf-clidocker-compose构建最小闭环腾讯云 SCF CLI (scf) 功能较弱不支持本地 invoke。但我们可用docker-compose模拟 SCF 运行时# docker-compose.yml version: 3.8 services: scf-runtime: image: registry.cn-shanghai.aliyuncs.com/aliyunfc/runtime-python3.9:latest volumes: - ./code:/code - ./events:/events working_dir: /code command: python index.py environment: - DB_HOSTmysql-local - DB_NAMEuser_db depends_on: - mysql-local mysql-local: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: pass MYSQL_DATABASE: user_db ports: - 3306:3306运行docker-compose up --build避坑现象fun local invoke报错ModuleNotFoundError: No module named pandas原因requirements.txt中pandas1.5.3与本地 Python 版本不兼容如本地 Python 3.11pandas 1.5.3 仅支持 ≤3.10解决在template.yml中指定BuildMethod: makefile用make build在容器内构建确保依赖与 FC 环境一致现象sam local invoke连接本地 MySQL 超时原因Docker 网络 DNS 解析失败mysql-local无法 resolve解决在docker-compose.yml中为scf-runtime添加extra_hosts: [mysql-local:host.docker.internal]现象本地调试通过线上仍报FunctionInitializationTimeout原因本地网络好initializer中的 OSS 下载、RDS 连接快线上因跨 AZ、安全组策略连接慢解决在initializer中加print(Start init at, time.time())和print(Init done at, time.time())对比本地与线上日志时间差针对性优化网络等待逻辑。6. 生产环境必须做的三件事函数粒度监控埋点、错误自动降级、以及用git tag锁定部署版本Serverless 不是甩手掌柜。它把服务器运维交给了云厂商但把可观测性、容错设计、版本治理这三座大山更沉重地压在了开发者肩上。我见过太多团队函数上线后靠“祈祷”运行——直到某天凌晨三点老板电话响起“用户注册失败率 40%快看看” 你打开控制台发现日志里只有Task timed out而initializer的报错早被滚动日志覆盖。这不是技术问题是工程习惯缺失。6.1 函数粒度监控不只看Duration要埋DB Query Time、Model Load Time、Cache Hit Rate云厂商的默认监控调用数、错误率、延迟是宏观仪表盘但定位根因需要微观探针。我在每个函数的handler开头和结尾强制插入统一埋点import time import logging from opentelemetry import trace from opentelemetry.sdk.trace import TracerProvider from opentelemetry.sdk.trace.export import ConsoleSpanExporter from opentelemetry.trace import SpanKind # 初始化 tracer生产环境对接阿里云 ARMS 或 AWS X-Ray provider TracerProvider() provider.add_span_processor(ConsoleSpanExporter()) trace.set_tracer_provider(provider) tracer trace.get_tracer(__name__) def handler(event, context): # 1. 开始 trace with tracer.start_as_current_span(user_register_handler, kindSpanKind.SERVER) as span: span.set_attribute(function_name, context.function_name) span.set_attribute(request_id, context.request_id) # 2. 埋 DB 查询时间 start_db time.time() try: result db.execute(INSERT INTO users ...) db_duration time.time() - start_db span.set_attribute(db_duration_ms, int(db_duration * 1000)) span.set p a hrefhttps://download.csdn.net/download/njbaige/32998779 stylecolor:#ec7500;font-size:14px; 本文还有配套的精品资源点击获取 /a img altmenu-r.4af5f7ec.gif srchttps://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif stylewidth:16px;margin-left:4px;vertical-align:text-bottom;cursor:text; /p