做过 BTP ABAP Environment 的人应该都有体会Sizing 往往是项目里最玄学、最容易吵架的环节。预算评审时被问“这套自研应用上线后能扛多少并发用户”当场没人敢拍胸脯到了运维阶段块数买多了被财务追着控费买少了业务部门在群里连环吐槽。本地 ABAP 好歹还有 SAPS、CPU、物理内存这些指标可以查到了 ABAP Environment你能选的容量单位几乎只有“几个块Block”这一项单块配额固定、价格固定、实际并发能力还高度依赖业务形态于是所有矛盾最后都集中在“到底买几个块”这个数字上面。这篇文章写给正在做自研 Fiori/BTP 应用、准备做生产环境规划、或者已经上线后不知道怎么验证容量的人。我会从 ABAP Block 这个基础容量单位拆起把业务需求换算成计算需求再给出能够直接抄作业的四步计算法最后附带一个真实的审批类应用 Sizing 案例和一批常见认知误区。内容不装神弄鬼每一条基本都能落回实际操作。1. 先搞清楚ABAP Environment 的 Sizing 和本地版本质区别1.1 本地能测物理资源云上只能选块以前做本地 ABAP Sizing事情相对直接先估算日终处理量查 SAP 发布的 SAPS 参考值再乘上 CPU 主频、内存冗余、磁盘 IOPS最后落到一台可以插进机房的服务器。你甚至能用 SAT、ST03N 量出每个事务平均消耗多少 CPU然后正向推一个完整的硬件清单。BTP ABAP Environment 不是这样。你买的是标准化容器单位就是 ABAP Block。这个 Block 不像服务器规格那样给你任意组装的自由度它把内存、vCPU、文件存储打包成一个固定套餐。这意味着你不需要去纠结采购哪颗 CPU但你也失去了一条随手抄起硬件手册就能算答案的路径。更麻烦的是你很难像以前那样直接登录操作系统看 tops、看内存进程、看 IO 队列容量数据只能通过平台监控和应用级反馈去反推。1.2 自研应用没有“历史基线”才是最痛的如果是给 SAP S/4HANA 或 ECC 标准模块做 Sizing还能参考产品线多年的最佳实践数据但自研应用根本没有现成的基线。一个 Fiori 列表页面可能是轻量 OData 查询也可能在 ABAP 端做了大量循环计算一个批处理任务可能每 5 分钟跑一次也可能月底一次性打平上万条数据。这些都得靠你重新建模。所以在 BTP ABAP Environment 里给自研应用做容量规划核心并不是“我多懂 SAP 参数”而是在业务不可测量之前先做一套可信的需求推演。下面我会把这一套推演拆成理解 Block 底子、建立需求台账、四步计算法、压测验证、避坑清单这几个环节。2. 唯一可调节的杠杆一个 ABAP Block 到底是什么2.1 官方配额表和它没告诉你的潜台词根据 SAP 公开服务描述里比较常见的口径1 个 ABAP Block 大致包含这样的资源区间维度一个 ABAP Block 的大致配额说明计算资源2 个 vCPUABAP 应用运行时与数据库计算共享一般按应用侧视角理解内存1 GB 内存ABAP 应用进程、工作进程、共享内存都算在这块里文件存储10 GB 文件存储应用日志、导出文件、附件缓存等这个配置对应一个很经典的经验值一个 Block 大约能支撑 50 个并发同步用户。但请特别注意“同步”和“并发”这两个词——它指的是同一时刻真正在向服务器发起请求的对话用户而不是系统里挂了 5000 个账号、日活 2000、同时在线 300 的那种“在线数”。50 这个数字也不是随便拍的。一个典型交互式用户在一次操作完成后需要一段时间阅读页面、输入内容、思考下一步这段时间后端工作进程实际上是空闲的。如果平均思考时间在 10 到 30 秒那么 50 个并发用户产生的实际请求压力非常可观地集中在一个较小量级下2 个 vCPU 足以消化。可如果你的应用是机器对机器接口每秒钟都在连续丢请求进来50 并发这个经验值就直接失效了。2.2 免费版、标准版和自研项目怎么选SAP BTP 的 ABAP Environment 目前有免费计划Free Plan和标准计划等形态。免费计划通常只提供一个或极少量 Block适合原型验证和 SAP BTP 学习不适合生产业务。标准计划按块数计费块数可以直接从服务实例的配置里调整。自研项目早期最容易犯的错是先买 1 个 Block 开始开发等要上生产才发现要重排服务计划。我的建议是开发质量Quality环境至少 1 个块起步生产环境最少按 2 个块规划。2 个块的意义不仅是容量还在于给部署、重启、备份、突发流量留出一个基本冗余只买 1 个块任何一个偶发峰值都可能导致整个应用不可用。3. 第一步把业务翻译成容量需求而不是拍脑袋填人数3.1 先给用户分层别把所有账号混在一起算自研应用里“总用户数”几乎没什么参考价值。我更建议按使用行为把用户拆成三层轻量用户偶尔查个数据每天操作 510 次单次操作只读取列表和详情几乎不写数据。标准用户日常业务处理每天操作 50150 次涉及查询、编辑、保存、审批有少量后台触发。重度用户高频录入、批量操作、复杂报表、接口调用每天操作 300 次以上单个请求的数据量比较大。计算并发时不要简单拿“总人数除以固定比例”。一个更靠谱的方法是统计业务高峰时段的实际并发请求数能拿到上线前业务预估更好拿不到就按“大概率低估”来设计。3.2 把你应用的请求结构列成台账要算准容量你得先知道自己的应用在跑哪些类型的请求。我一般让项目组做一张“请求台账”列清楚功能模块名称比如审批列表、单据详情、提交审批前端调用方式是 OData 查询、Fiori 导航、还是自定义 REST API单次请求的预估后端 CPU 耗时比如 50ms、100ms、500ms高峰时段的请求量比如早高峰 9:3010:30 有 1 万次查询每次请求加载的数据量列表页是一屏 20 行还是一个月 5000 行的汇总这张表做出来之后Sizing 就不是“我觉得要买 4 个块”这种玄学了而是“按最重场景算出来的 CPU 需求是 X因此需要 Y 个块”。3.3 后台作业、接口和异步事件都必须进台账自研应用很少只有前端交互。你可能还有后台定期任务每天凌晨同步一次主数据、每小时跑一次告警扫描、用户导入 Excel 后的异步解析。后台任务的 CPU 占用往往比对话框任务高一个量级因为它没有用户思考时间缓冲跑起来就是一整段连续计算。接口也一样。如果是同一个 BTP 环境里另一个应用调你的 OData 接口请求频率是秒级的这种压力更像压力测试工具跑出来的持续负载而不是用户浏览器带来的间歇负载。建议在并发计算之外单独给后台作业和接口调用开一个“持续吞吐量”把这个吞吐量单独折算成 vCPU再叠加到用户并发需求里。3.4 文件存储和数据库从来不是免费的ABAP Block 里的 10 GB 文件存储很容易被忽略。应用日志、导出报表、附件、临时文件都会消耗这块空间而且它和 ABAP 内存不共享。如果你的应用要做大量文件交换或者日志特别冗长光靠 1 个块自带的 10 GB 可能一周就告警。数据库存储还需要单独看。BTP 上 ABAP Environment 的数据库服务有自身的容量逻辑尤其是 HANA 的表数据和日志增长。我的经验是自研应用如果有主数据表、明细表、日志流水数据库存储要按月增长率去做预算不要只按初始数据量算否则半年后你会发现存储不够不是靠加 Block 能解决的。4. 第二步落地 Sizing 的四步计算法可直接抄作业4.1 第一步按并发需求算最低块数先看“同一时刻有多少用户正在操作”。最简单的方法是用并发对话数生产环境最低块数 预计峰值并发用户数 ÷ 50向上取整。举个例子业务高峰期有 180 个用户同时在线其中有 120 个在频繁切换页面这个 120 就是峰值并发数。按 50 并发/块算出来是 2.4取整就是 3 个块。这 3 个块不是拍脑袋而是基于 SAP 参考工作负载模型的基础盘。如果并发数低于 50也不能直接买 1 个块上生产。原因前面说了生产环境最少保留 2 个块用于部署和故障冗余。所以实际公式我会写成生产块数 MAX(2, CEILING(峰值并发 / 50))。4.2 第二步用 CPU 吞吐量做交叉验证并发算出来的块数只是基础线还需要用 CPU 吞吐量来交叉验证特别是有接口和后台任务的场景。公式可以这么理解峰值每秒请求数 × 单请求平均 CPU 耗时 需要的 CPU 每秒量再把“每秒需要的 CPU 量”除以 2 vCPU乘以一个缓冲系数就得到需要的块数。缓冲系数我一般取 1.52因为不能让系统长期跑在 90% 以上 CPU云环境下还要留出突发余量和维护窗口。举例一个 OData 接口高峰期每秒收到 20 个请求平均每个请求消耗 150ms CPU。那每秒需要的 CPU 量 20 × 0.15 3 个虚拟 CPU。除以 2 vCPU 1.5 块乘 1.5 缓冲就是 2.25向上取整 3 块。这条路径算出来的 3 块和前面并发算出来的 3 块只要一致就说明结论是稳固的。4.3 第三步内存和存储校验大多数自研 ABAP 应用内存问题比 CPU 问题更容易翻车。ABAP 应用进程的私有内存、共享内存、HTTP 会话的会话管理都会占用 Block 配额。前面说的“50 并发/块”实际已经把典型内存占用打进了模型但如果你的应用有超大数据的内表缓存或者返回给前端的数据量特别大就得额外加块。一个粗略校验口径预估峰值并发 × 单会话平均内存 150250MB再除以 1GB。如果结果是 1.5 个块而你按并发算出来是 3 个块说明内存不会成为瓶颈如果内存算出来比并发算出来的块数还大那就必须加大块数内存才是你的真实瓶颈。文件存储则独立校验统计每日新增日志量、导出文件量、附件量乘以保留周期看是否超过已购块数的 10GB × 块数。4.4 第四步双上限法确认并留足余量我的落地习惯是不管怎么算最后都做一次“双上限”确认先比较“并发需求”和“CPU 吞吐需求”这两个计算路径取更高的块数作为基数然后叠加峰值波动系数通常再增加 2030%得到最终建议块数。这套方法的核心逻辑是并发描述的是工作进程或会话瓶颈CPU 描述的是计算瓶颈两者不一定同时被触发。取最大值后加余量等于同时防住了会话阻塞和计算打满两种最典型故障。上线之后如果监控显示长期空闲再降块也完全来得及但一开始就给足余量远比被业务骂完再扩容要省心。5. 第三步一个自研审批系统怎么走完整个推演5.1 需求台账长什么样我最近帮一个团队做过一套“门店费用审批”应用面向 2000 个内部员工。系统核心场景是员工提单、部门经理审批、财务复核、导出明细外加每天晚上批量把审批结果同步给下游系统。业务预估下来是这样的日活用户 800 人在线峰值约 180 人其中并发交互用户约 120 人高峰期每秒约 2030 个 OData 请求审批列表平均耗时 60ms审批详情 30ms提交审批 180ms导出报表 800ms每天新增业务表和日志表数据约 200MB文件导出约 500MB夜间批处理每小时跑一轮高峰时 CPU 占用等效约 1.5 个 vCPU5.2 四步法跑出来的结果并发路径120 并发 ÷ 50 2.4向上取整 3生产最少 2所以最低 3 块。CPU 路径高峰期每秒 25 次请求 × 平均 100ms 2.5 个 vCPU。夜间批处理折算成高峰等效后再加 1.5 个 vCPU。合计基础计算量约 4 个 vCPU除 2 2 块再乘 1.5 缓冲 3 块。内存路径120 并发 × 平均单会话 200MB 24GB 理论峰值。这里必须解释一下并发会话不会每时每刻同时占满 200MB实际会更低但这个值用来做安全校验仍然有意义。24GB 对应约 24 个 Block明显远超 3 个块的估算。这个案例真正要警惕的不是 CPU而是大量列表查询把 ABAP 会话内存撑爆。所以我把内存监控列为上线后第一优先级并制定了一个预案如果监控数据持续超限直接把块数从 3 提到 5。最终生产环境建议 5 个块质量环境 2 个块。开发环境 1 个块。一开始团队觉得贵但上线后第一次月度导出报表高峰时CPU 长期压在 70% 附近内存峰值也接近 Block 配额上限团队终于承认 5 个块是合理底线不是销售话术。5.3 这个案例的复盘价值最大的经验是不要只用一个公式走到底。并发算出来 3CPU 算出来 3看似很一致但内存路径暴露了隐藏风险。很多 BTP ABAP 自研应用都不是死在 CPU 上而是死在会话内存和存储上只因为大部分人的 Sizing 习惯还停留在本地物理机时代的“CPU 够用就行”。另一个经验是夜间批处理的 CPU 折算不能按平均值算。批处理和用户请求的叠加时机很关键如果批处理正好撞上白天高峰就需要把批处理折算进日间峰值而不是单独讨论午夜时段。排程时尽量错峰Sizing 压力会小很多。6. 监控与压测上线后必须把估算修正成实测6.1 利用云监控和 ABAP 运维接口看真实水位自研应用上线后第一步就是建立容量水位看板。BTP ABAP Environment 提供项目级运维工具和监控入口你可以通过运维应用查看系统健康状态也能读取工作进程、内存、队列深度和响应时间指标。SAP Cloud ALM 可以把 ABAP 环境的监控集成进来这比在脑子里记数字要靠谱得多。我常用的检查清单包括实时工作进程利用率有没有反复出现工作进程排队ABAP 对话请求的响应时间P95 是否稳定内存使用率是否长期超过 Block 配额 80%文件存储剩余量是否有非预期增长队列深度是否出现批处理和对话互相挣抢资源这些指标不要等用户投诉才去看最好上线前两周每天记录一次建立基线曲线。之后的每一次大版本发布都要拿新数据进行对比。6.2 压测要打在 OData 的“真实路径”上估算毕竟只是估算压测往往是最后一道保险。自研应用大部分通过 OData 或 REST API 暴露给前端或接口调用建议压测直接对准这些 HTTP 端点而不是虚构一堆事务代码。工具方面JMeter、k6 都是实践里常用且相对容易上手的。压测策略可以参考这几步先用 1020 并发跑 10 分钟记录平均响应时间和趟底误差逐步提高到 50、100、150 并发观察 TPS 和错误率拐点把 95 分位响应时间控制在 1 秒以内作为衡量基准压测时同时观察云监控里的 CPU 和内存确认瓶颈是先出现在应用层还是平台层如果你压测出来的 120 并发就已经让某个服务出现工作进程排队而业务预估也是 120 并发那就别犹豫直接按比估算多 2 个块去配置。6.3 用数据修正 Block比挤牙膏式扩容聪明得多上线后的容量管理本质上是一个持续调整的过程。我不建议一开始买满三年需求而是“保守起步 按监控数据增量扩容”。BTP 的服务计划允许根据实际使用量调整块数理论上比本地服务器升级更快但这不代表扩容是没有成本的。服务实例变更、ABAP 环境重启、周边依赖配置都需要时间和变更窗口所以每一次扩容都要提前规划。更推荐的做法是每季度做一次容量回顾把响应时间、TPS、内存、存储四条曲线拉出来对比当初 Sizing 的假设。如果发现业务增速远超预期就提前两个迭代做扩容预算而不是在宕机之后连夜抢修。7. 专家们踩过的坑常见 Sizing 认知误区速查误区实际情况正确姿势“系统有 800 个在线用户所以买 16 个块”在线数和并发请求数是两回事用峰值并发请求数去算而不是总登录数“平均 CPU 只有 20%2 个块就够了”平均掩盖了 5 分钟级峰值接口突发或批处理叠峰时瞬间打满用最大峰值时段核算并加 30% 缓冲“只算前台用户后台批处理不用管”批处理连续占用 CPU等效负载可能比所有前台用户还高把批处理、接口、事件订阅全部折算进路径“加了块文件存储就自动够用”块的文件存储是 10GB/块不等于无限制单独建文件存储趋势监控和日志归档策略“压测没问题上线肯定没问题”压测场景覆盖不到业务真实操作路径压测完毕后仍要保留 12 块冗余继续观察“内存只要 1GB 每块小应用够用了”为什么 50 并发模型不是能力全部正则检查静态数据装填、attachment 缓存和内存表设计这几条里我最想多说一句的是文件存储。BTP ABAP Environment 里应用日志和导出文件往往比数据库涨得更快。很多开发环境配置了全量日志一周下来就有可能把 10GB 配额吃掉。这不需要加大计算内存但你必须在上线前确定日志轮转和归档方案否则会有一天整个系统因为磁盘满而停摆而你还要花时间解释“块数明明是够的”。8. 关于自研应用 Sizing我最后想说的一点个人体会在 SAP BTP ABAP Environment 里给自研应用做容量规划我的整体感受是这已经不是过去那种“对着硬件手册查 SAPS 再下单”的年代了而更像是在做一套持续演进的容量运营。你可以在项目启动时用并发、CPU、内存这三条路径交叉估算也可以用“双上限法”给最终块数留出余量但真正决定容量是否合格的是上线后的监控数据。如果你只能从这篇文章里记住一件事那就是永远不要在 Sizing 里只信一条公式。并发数可能低估计算压力平均 CPU 可能掩盖峰值风险内存路径可能暴露会话问题文件存储则会悄悄拖垮你。拿三条路径交叉验证再挂上持续监控这个容量规划才算真正落了地。过了这个坎之后你会发现BTP ABAP Environment 的自研项目最难的不是写 ABAP而是让业务和财务都相信你报出来的那个块数是算出来、压过测、有根据的。