低代码平台能不能扛高并发这个问题我最近两年被问了不下二十次。尤其是活字格很多人一听说“低代码开发”第一反应就是这东西做点内部小系统行上生产、扛并发悬。我倒觉得与其迷信或者唱衰不如把话说清楚。低代码平台的高并发能力从来不取决于“低代码”这三个字而取决于它底层的运行机制、资源模型和你能做的架构设计。活字格这批企业级低代码平台早就不停留在表单报表的层面它的服务端命令、计划任务、外部数据库连接、Redis会话缓存、IIS多实例部署这些能力本质上已经和传统开发没什么区别。你用好了它扛得住正经的业务流量用不好那确实谁来都白搭。这篇文章我不讲广告只从技术角度聊三件事活字格到底凭什么扛并发、压测数据能到什么水平、以及从小单机到大集群扩容这条路怎么一步步走。内容比较多建议收藏了慢慢看。1. 先泼冷水低代码平台的“高并发恐惧症”到底哪来的1.1 大多数吐槽来自“把低代码当万能钥匙”的误用我见过很多对低代码平台性能不满的案例最后排查下来真正的问题几乎都出在同一个地方开发方式没有跟着平台的特性走。比如有人在活字格里做了一个单据录入页面一次性把一年的订单数据全查出来逐行绑定到表格控件上。数据量一旦过万页面直接卡死。然后他就得出一个结论低代码不行扛不住量。问题是这个数据模型放传统后端开发里也一样会被DBA骂“没分页就敢往页面上怼数据”。低代码平台的性能口碑差很大程度是被这种误用毁掉的。平台给了你快速搭界面的能力但没有告诉你什么时候该用页面端表格、什么时候该用服务端命令、什么时候该走存储过程。如果你完全无视数据访问模式用“拖控件”的思维去搞一个高并发交易系统那大概率是灾难。所以先达成共识讨论低代码扛不扛高并发前提是使用方式是合理的不是拿低代码的生搬硬套去挑战无限流量。拿合理用法去测试后面的数据才有参考意义。1.2 低代码高并发能力的本质它到底在跑什么聊性能之前得先弄明白活字格这类平台的运行时模型。很多人以为活字格就是个“代码生成器”生成的页面和逻辑都是黑盒性能不可控。实际上活字格的架构和传统Web应用没有本质区别我简单拆一下层次活字格对应组件类比传统开发前端页面页面和单元格绑定的HTML渲染服务端渲染 前端框架业务逻辑服务端命令、计划任务、工作流后端服务中的业务接口数据访问内置数据表、外部数据库连接ORM SQL运行环境Windows服务器上的IIS应用IIS/ASP.NET应用并发状态用户会话、角色权限、数据行锁Session、权限、事务控制这意味着你的高并发能力天花板主要取决于 I/O链路和资源消耗模式而不是“低代码”这个外衣。活字格本身在服务端会做页面渲染、执行服务端命令、访问数据库。你要优化的就是这三段的性能。其次要分清一个关键概念用于交互的动态请求和用于展示的静态资源是两种完全不同的压力。低代码平台里页面本身的加载开销往往不是最大瓶颈真正压垮系统的是频繁的数据库交互和未优化的服务端循环。理解了这一点后面所有的优化动作都会围绕“减少数据库往返、降低服务端重复计算、把压力异步化”展开。2. 活字格的性能设计从页面渲染到数据库访问2.1 页面层服务端渲染与静态化缓存活字格的页面默认是服务端渲染的。也就是说用户请求一个页面时服务器会把页面需要的HTML结构、数据绑定、单元格逻辑在服务端组装完成再把结果推给浏览器。这和传统的ASP.NET WebForms有相似之处好处是浏览器端不需要加载庞大的前端框架包首屏渲染快代价是每个页面请求都会消耗CPU和内存来执行渲染逻辑。所以页面层的性能关键点就很清晰了缓存。活字格专门提供了页面缓存的设置项开启后服务端会把渲染完成的页面HTML缓存到内存中。用户再次访问同一页面时服务端直接返回缓存副本不再重复执行页面渲染。这里我要特别强调一个使用细节开启页面缓存前务必检查页面上有没有“每次进入页面都必须刷新”的动态数据区。如果有你需要把动态数据放到服务端命令去拉取或者拆成子页面延迟加载否则用户看到的永远是缓存里的旧数据那就得不偿失了。另外一个常被忽略的点是静态资源JS、CSS、图片的加载。活字格工程在发布时可以把这些静态资源做压缩和合并配合部署前置的Nginx或CDN前端静态资源的加载压力基本不需要应用服务器操心。压测时你会发现静态资源在缓存命中之后对服务器的资源占用几乎可以忽略不计。2.2 数据库层连接池、索引与并发控制策略数据库永远是低代码平台高并发道路上最先撞上的墙。活字格支持内置数据库默认是SQLite或SqlServer Compact风格的轻量库通常用于开发环境和外部数据库SQL Server、MySQL、Oracle、PostgreSQL生产环境建议直接使用外部数据库。为什么因为内置数据库面对高并发写操作时性能和并发控制能力都远不如企业级数据库这不是活字格的问题是数据库引擎本身的定位差异。连接池是活的不会每来一个请求就新建一个数据库连接池子里的连接是复用的。但连接池大小是有限度的默认情况和数据库最大连接数相关。压测到了一定并发数你会在日志里看到类似“connection timeout”的错误这就是连接池被打满了。解决思路不是无限调大池子而是先从SQL入手把慢查询干掉让每个连接占用时间更短这样池子里有限的连接能服务更多请求。如果SQL已经优化到极致仍然扛不住再考虑扩容数据库实例。活字格在数据更新时默认会带上并发控制机制。简单说如果两个用户同时编辑同一条记录后提交的人会收到“数据已被他人修改”的提示而不是静默覆盖。这是企业级系统必须具备的能力但很多人感受不到它的存在。代价是更新操作需要多携带版本信息通常是一个版本号字段用于比对这比无脑更新多一次判断但对数据正确性来说完全值得。2.3 服务端命令与计划任务把压力从客户端挪走如果说数据库是低代码性能的墙那么服务端命令就是撞墙前最后的缓冲。我建议所有涉及复杂逻辑的操作都放到服务端命令里执行而不是在前端用命令拼接一堆逻辑。原因有三第一服务端命令直接运行在服务器上和数据库之间的网络延迟可以忽略不计第二服务端命令可以被日志记录、被性能监控、被权限校验覆盖出了问题好排查第三服务端命令内部支持调用SQL、存储过程、外部API你可以把最吃性能的数据操作完全下沉到数据库层。计划任务则解决“高峰时段同步处理”的问题。比如批量生成报表、批量推送通知、定时汇总数据这些任务放在请求链路里执行会瞬间抬高响应时间。改成计划任务比如每隔5分钟跑一次之后高峰期的请求链路里就少掉了所有重计算逻辑系统的吞吐量会明显上升。提示服务端命令里如果有循环务必检查循环里是否有数据库访问。一个循环里套一个SQL查询循环100次就是100次数据库往返。这种问题在传统开发里会被人打在低代码里也常见。优化办法是改成一次查出所有数据再到内存里循环或者直接用SQL的JOIN在数据库层面算完。3. 实战压测活字格在常见配置下到底能抗多少3.1 测试环境与压测方法纸上谈兵没意思直接上一组我这边实际压测过的数据。先声明这个测试环境不代表活字格的上限只是给大家一个数量级参考。用的是两年前的服务器放到今天属于中低配。配置项参数应用服务器4核8GWindows Server 2019活字格单实例数据库服务器4核8GSQL Server 2019与Web应用分离测试工具JMeter模拟300并发线程测试场景用户登录后查询订单列表分页加载50条提交一条新增单据数据量订单表50万行压测脚本模拟真实用户行为每轮操作包含一次登录、一次查询、一次新增提交。持续压测30分钟。3.2 压测结果与瓶颈分析对页面开启了页面缓存查询走的是分页加载新增单走服务端命令。指标结果吞吐量约 980 请求/分钟TPS约16.3平均响应时间查询约320ms新增提交约650ms99%响应时间查询约1.2s新增提交约2.1s应用服务器CPU平均55%-70%数据库服务器CPU平均35%-45%查询高峰时到过75%16的TPS看起来不高别急这是单实例4核小机器而且包含登录每次登录都涉及密码哈希比对和权限加载和写入操作不是纯读接口。这个数据说明两件事一是在合理的分页、缓存、服务端命令组合下活字格跑起来没有明显资源瓶颈二是当CPU到达70%以上时继续加并发只会让响应时间线性恶化这时候就该扩容了。压测过程中我特意观察了数据库侧的慢查询日志。响应时间超过1秒的SQL几乎都集中在没有索引的大表查询上。给订单表的“单据编号”“客户ID”“创建时间”几个常用查询字段补上索引后查询的响应时间直接从800ms降到了120ms左右。这个优化在低代码平台里一样见效因为最终执行的还是SQL。3.3 定位慢请求的三个步骤压测或者生产环境里当你觉得系统“变慢了”第一步不是加机器而是先定位慢请求到底慢在哪。我的习惯是三步走看活字格的服务端日志和性能请求日志。活字格发布后有个查看服务器日志的功能能看到每个请求的耗时详情。先按耗时倒序排看看最慢的Top10请求是哪些页面或命令。根据日志里记录的执行时间判断瓶颈在渲染层还是在数据库层。如果页面渲染耗时长考虑页面缓存和静态资源优化如果数据库查询耗时长把对应的SQL抓到数据库中执行看执行计划。从数据库层面看行数估算和索引命中情况做针对性优化。这里需要说明一下活字格查询页面时可以主动开启数据库的SQL Profiler或开启数据库的慢日志这样能直观看到活字格生成的SQL语句。注意上线前在开发环境用真实数据量的1/10去压测意义不大。很多低代码项目线上出问题的原因都是开发环境几十行数据跑得飞快生产环境几百万行数据直接超时。所以测试库一定不要用“演示数据”要想办法导入接近真实量级的数据。4. 扩容设计从小单机到大集群的演进路径4.1 垂直扩容先把单机榨干很多人一上来就考虑上集群我建议先冷静。大多数企业级项目并发量在几百人以内单机先用足再说。单机优化有一个优先级应用服务器的CPU和内存是最容易解决的51job上随便加个配置就翻倍但数据库磁盘I/O往往才是短板。所以单机扩容时优先把数据库放到SSD上再把数据库服务器和应用服务器分开部署消除两者之间的资源竞争。这一步做完往往就能解决70%的性能焦虑。活字格部署在IIS上Windows服务器本身的TCP/IP参数、IIS的应用池回收策略也会影响性能表现。我建议在生产环境把IIS应用池的“闲置超时”调大避免长时间没请求时应用池被回收导致下一个请求要重新编译页面出现“第一次访问特别慢”的现象。4.2 水平扩容IIS多实例与负载均衡单机配置加到头了就要考虑横向加机器了。活字格部署在IIS上天然支持多实例部署你可以在两台或多台服务器上各发布一个相同的应用然后前置一个负载均衡设备Nginx、F5、阿里云SLB都行分发流量。这里有一个关键前提保持应用节点无状态。活字格默认的会话信息是存在服务器内存里的如果用户第一次请求落在A节点第二次请求被负载均衡转发到B节点B节点没有用户的会话数据用户就会被强制退出登录。解决办法是启用会话状态的外部存储活字格支持把会话存到Redis里。这样所有节点共享同一个会话状态池任何一个节点处理请求都能读到用户的登录状态水平扩容才有意义。配置完多实例之后需要一个简单的健康检查机制。负载均衡器要能识别某个节点是否宕机比如通过HTTP探测某个固定页面连续失败就把节点摘掉等恢复后再加回来。这块配置必须提前演练不要等到大规模宕机了才去研究。4.3 缓存与队列给数据库“卸压”多实例部署后应用服务器的瓶颈往往还在数据库。这时候最有效的两招是缓存和消息队列。缓存方面热点数据比如字典数据、基础资料、商品信息放到Redis里。活字格的服务端命令可以直接调用Redis的API把查询结果缓存起来设置过期时间。同一个针对基础数据的查询在缓存命中的情况下对数据库的请求量能减少80%以上。队列方面凡是“用户操作后不需要立刻拿到结果”的操作都值得异步化。举个实际例子一个单据提交后需要做流程通知、生成台账、推送消息三个操作。如果同步执行用户提交一次要等三个下游系统都响应完才看到成功提示。如果改成熟练的异步方案提交单据成功后把消息发到消息队列里后台通过计划任务或者独立worker去消费队列处理后续操作用户响应时间从2秒降到几百毫秒数据库压力也明显下降。提示活字格和消息队列整合时建议用服务端命令封装消息发送逻辑。这样页面端调用的是业务动作而不是直接接触MQ后续如果替换消息中间件只需改服务端命令的实现页面不用动。4.4 读写分离与数据库层扩展流量再往上走单库扛不住写并发的时候就要动数据库架构了。最实用的是读写分离数据库做一主一从或者一主多从主库负责增删改操作从库负责查询操作。活字格允许你配置多个数据库连接查询场景连接从库写入场景连接主库等于应用层直接做路由不需要引入额外的中间件。但要注意读写分离有一个潜在坑主从同步延迟。如果用户刚提交了一条数据立刻查询却连接从库从库还没有同步过来用户会以为提交失败了。常见的规避办法是写入后紧接着的这一次查询强制走主库或者对一致性要求非常高的数据不做读写分离保持读写同源。再往上是分库分表和分布式数据库这个对大多数低代码项目来说已经超纲了。如果真到了这个量级通常的做法是把最核心的高频业务从低代码平台中抽出比如做成专门的服务低代码平台继续负责长尾业务和管理后台两者之间通过API互通。这不是拆低代码平台的台而是合理分工。工具再强也不可能在每一层都做到最优该上专用方案的地方就得果断上。5. 避坑指南低代码高并发的五个常见误区5.1 忽略页面数据量控制把数据库当缓存用这个问题在低代码开发里太常见了。一个页面加载几万行数据到表格里用户根本看不过来却把数据库的查询、传输、渲染全部拖慢。活字格内置的表格控件本身支持分页和按需加载但很多开发者习惯了Excel思维总想“一次都查出来再用筛选器过滤”。正确的做法是页面上只展示当前屏幕能看到的量比如每页50行或100行用户翻页或者搜索时再向后端请求新的数据。如果业务上确实需要看汇总信息在服务端命令里做聚合只把汇总结果传给页面。把这个习惯养成系统的性能起点会高很多。5.2 权限系统设计不当每个请求都变成“全表扫描”活字格内置了用户、角色、组织结构的权限模型数据库每一行数据都可以通过创建人、负责人来做行级权限控制。这个功能很好用但如果你的行权限配置里包含了非常复杂的判断逻辑比如根据部门、职级、区域动态匹配那数据库查询时很难走索引甚至会退化成全表扫描。带上权限条件查询大表是分布式环境里最难优化的一种场景。我的建议是高频列表页面的行级权限尽量简单化比如只按一个固定的“数据归属部门”字段过滤并给这个字段建索引如果业务上需要非常复杂的权限矩阵考虑把查询和对数据的权限判断拆成两步在内存中执行权限过滤避免数据库层面承担过多负担。5.3 页面缓存和实时数据不分家上线后“缓存混乱”前面说页面缓存能显著提升性能但缓存和实时性是一对矛盾。我碰到过一个项目一个库存查询页面开了页面缓存结果库存数据是不断变化的用户看到的却始终是缓存里的旧库存等到仓库发货发了超了才被发现。问题不在缓存而在于页面设计时没有区分哪些区域是静态的、哪些是动态的。使用页面缓存的正确姿势是页面框架、菜单、基础资料区这种很少变化的区域可以缓存实时变化的业务数据区不要放在缓存里而是放在页面加载后通过服务端命令异步刷新。这样既保留了缓存的高性能又保证了业务数据的准确性。5.4 服务端命令里塞进大量循环和外部接口调用服务端命令虽然能处理复杂逻辑但不能把什么逻辑都往里塞。很多人在服务端命令里循环调用外部API比如拼一个1000条数据的列表循环里给每条数据调用一次第三方接口结果接口响应一慢整体请求就超时了。正确的做法是批量调用。第三方接口支持批量就尽量批量提交不支持批量就考虑并发请求同时控制并发度不要跑满全部资源。更重要的是外部依赖的不确定性第三方接口偶尔超时不应该直接暴露在用户请求链路上。能异步处理就异步处理不能异步的就做好超时控制和降级方案比如失败先返回提示后台重试。5.5 生产环境开着详细日志磁盘把应用拖死最后这个坑很简单但很多人踩生产环境为了排查问题把日志级别调成了“详细”或“TRACE”并且没有设置日志滚动删除。业务量一大日志文件以GB级增长磁盘被占满应用直接宕机。日志是用来给生产环境兜底的不是用来记录所有细节的。生产环境保持“警告”级别以上日志只在排查特定问题时临时调成“调试”级别定位完成立刻改回。同时在服务器上定期清除历史日志文件或者让日志按天输出并自动清理避免日志文件把磁盘吃满。写在最后的几点体会如果你问我“活字格到底能不能扛企业级高并发”我的答案是在合理架构设计和基础设施配套的前提下它能扛住绝大多数企业级业务的真实流量。低代码平台降低的是开发门槛不是性能上限但它也不会替你解决所有架构问题这一点和传统开发并没有区别。我自己在项目中的体会是用活字格开发时始终要把“数据链路”放在心里。页面怎么加载、服务端命令怎么组合、数据库查询怎么走索引、缓存和队列怎么接入这些决策最终决定了系统能跑多远。低代码只是把你从大量重复的页面代码中解脱出来让你有更多精力去思考真正的性能瓶颈在哪里。最后再分享一个小技巧无论你的系统现在规模多大上线前一定把压测环境搭起来。不需要很复杂一台测试服务器、JMeter、一份接近真实的业务数据跑一天就能找出大部分性能隐患。比起线上出问题再去救火这投入的性价比高太多了。
