1. 先别急着下结论低代码和高并发的账该怎么算1.1 大家唱衰低代码性能唱衰的其实是哪一环做低代码选型时技术圈最容易出现的对话就是低代码根本扛不住高并发。说这话的人多半没见过企业应用的真实流量模型或者默认了低代码平台就是自动生成一堆烂代码的代码生成器。但活字格这类企业级低代码平台底层根本不是网页爬虫式的代码生成而是运行时的元数据引擎加服务端执行框架。你拖拽出来的页面、命令、数据表结构在服务器端跑的是一套解释执行加编译缓存的运行时。这个结构和传统.NET应用的差距比你想象的小得多。真正对性能产生影响的其实不是低代码这个帽子而是三层东西平台运行时自身的开销包括元数据解析、权限校验、引擎分发数据访问层的封装程度包括SQL生成策略、连接池管理、事务控制应用设计者的设计水平比如有没有在页面上直接拉全表数据、有没有在循环里反复写数据库操作。前两层是平台决定的最后一层是你决定的。实际压过活字格的人会发现第一层和第二层的开销完全可控真正的性能瓶颈几乎都出在第三层。所以讨论活字格能不能扛高并发本质上是在讨论你用它搭出来的那套应用是不是按高并发的方式设计的。1.2 先定义企业应用的高并发到底是什么量级讨论性能最怕张口就来。电商大促的每秒十万级请求叫高并发一个制造业ERP在月末结算时的几百并发也经常被称为高并发这俩根本不是一个物种。企业级应用通常的流量模型是用户量几千到几万但活跃并发往往只有几百流量集中在月初月末盘点、月末关账、销售下单高峰这些时间窗口单请求是典型的数据密集型加轻计算比如查一张跨部门汇总报表或者提交一个包含几十个字段的工单。所以企业级低代码要扛的高并发和互联网ToC产品的每秒请求数是两码事。企业应用真正要解决的是三件事大量用户同时打开系统时页面不卡批量任务提交时数据库不锁死月底报表高峰时集群能顶住。明白这一点再来看活字格的设计思路会清楚很多。1.3 平台与应用设计的责任边界出问题别甩锅给低代码我在给客户做性能排查时最常遇到的情况是一出现卡顿大家第一反应是低代码平台不行。结果一查页面加载时一次性查了五万行数据还在表格里逐行做条件格式或者某个服务端命令在循环里调了五百次数据库更新。这锅真不该平台背。活字格解决了开发效率但没承诺替你设计出高性能应用。它给你的每个页面组件、每种命令执行方式背后都有对应的资源开销。理解了平台做了什么、没做什么你才知道哪些地方需要自己动手调优哪些地方平台已经替你扛了这就是接下来要拆的东西。2. 活字格架构拆解性能底子到底行不行2.1 一条完整请求在活字格里是怎么走的先看一条最简单的请求路径用户在浏览器里打开一个活字格页面输入查询条件点击查询页面表格刷新。整个流程是这样的浏览器把请求发给Web服务器活字格的服务端引擎收到请求后先做身份验证和权限校验确认这个用户有没有对应数据表的查看权限然后根据页面元数据动态组装数据查询逻辑生成数据库查询语句数据库执行查询把结果集返回给服务端引擎引擎再把结果序列化成Json回传给浏览器端的页面组件进行渲染。整个过程平台在请求路径上额外做的事情主要是权限校验、元数据解析和结果序列化这三件。从性能角度看这三件事的量级都很轻。权限校验走的是内存缓存元数据解析在首次加载后会有缓存Json序列化在.NET里本身效率就很高。真正耗时间的还是那条数据库查询语句执行本身。所以理解活字格性能核心一句话平台的开销是固定的数据库的查询是不可控的优化空间全在后者。2.2 数据访问层的封装与开销平台帮你做了什么活字格的数据访问层封装得比较厚这是它和原生开发的本质区别。你拖一个表格绑定数据表平台会根据页面上的筛选条件、排序规则、分页设置自动生成查询语句。这个过程有几个值得注意的点。第一是连接池管理。平台默认维护了一个连接池应用启动时建立一批数据库连接请求时从池里取用完归还。这意味着你的数据库不用承受反复建立和销毁连接的开销连接数的峰值也相对可控。实际部署中SQL Server默认最大连接数通常是32767活字格一个应用节点的连接池默认也就是几十到几百完全够用。第二是分页查询。活字格表格组件支持服务器端分页查询时只在数据库层面取当前页的数据而不是把全表拉到内存再翻页。这个机制非常重要。很多人用低代码平台觉得慢就是因为没启用分页或者用了不支持分页的页面容器。一个十万行的表如果前端拿到全量数据再快的机器也会卡如果每次只取20行那压力小到可以忽略。第三是SQL生成的策略。平台生成查询时会根据筛选项动态拼接Where条件这个过程的效率取决于你绑定的查询逻辑。如果你在一个页面上绑定了大量无索引字段的筛选条件那生成的SQL就会走全表扫描。这不是平台的问题是数据库设计的问题后面优化部分会细说。2.3 缓存、静态资源与会话管理的默认表现活字格对静态资源JS、CSS、图片有默认的浏览器缓存策略。首次打开页面时浏览器会把资源下载到本地后续访问直接用缓存减少了很多网络请求。服务端这边页面元数据、用户权限、数据字典等内容也有内存缓存不会每次请求都去数据库读一遍配置。会话管理方面活字格默认在单机部署下会把会话状态放在应用进程内。这个设计的性能最好因为不走外部存储读写都是内存操作。但有个前提一旦你要搞多台服务器的集群部署就得考虑会话保持的问题。最简单的做法是负载均衡器上配置粘性会话让同一个用户的请求始终打到同一台服务器上如果你不想依赖粘性会话那就需要自己处理会话状态的共享这块在扩容章节里详细展开。还有一个容易被忽视的点是上传文件的存储位置。活字格的文件上传默认存在服务器本地磁盘单机部署没问题但多节点部署时必须把文件存储目录改成共享目录比如NAS或者对象存储否则用户上传的文件只存在其中一台节点上负载均衡一转发文件就消失了。这个坑我在实际项目里踩过后面也会提到。3. 高并发场景下的性能优化实操从页面到数据库逐个抠3.1 页面端数据加载量是性能的命门在活字格里做性能优化第一个要盯死的就是一个页面到底加载了多少数据。我见过太多低代码项目页面一打开表格直接把整张业务表的数据全拉出来少则几千行多则几十万行。不管平台多优化浏览器渲染几千行表格DOM加上每行的格式计算、事件绑定不卡才怪。正确的做法很明确所有列表页必须开启分页。活字格表格的分页设置里你可以指定每页行数平台会自动把分页条件下推到数据库。对于用户需要搜索的场景一定要加上查询条件区域让用户先输入筛选条件再查询而不是打开页面就全量加载。查询条件字段要尽量落在有索引的列上比如单号、日期、客户编号而不是备注这种又没有索引又容易重复的字段。除了表格本身页面上常见的性能杀手还有两类。一类是模板命令里做了大量前端循环比如在表格的每一行上执行状态判断、格式转换数据多时会显著拖慢页面交互另一类是页面上放了太多隐藏的OData查询或统计文本每次页面加载时这些查询都会默默执行一遍。排查方法很简单浏览器F12打开开发者工具看网络面板里每个请求的耗时和返回体积哪个请求返回了几MB的数据干掉A它性能提升立竿见影。3.2 服务端命令与事务把重量级逻辑留在服务器上执行活字格支持前端命令和服务端命令两种执行方式。前端命令在浏览器里跑适合页面交互逻辑比如弹出对话框、隐藏显示某个区域服务端命令在服务器上执行适合数据处理、业务逻辑、集成调用这类重量级操作。性能优化的一个核心原则是凡是涉及多个数据表操作、批量数据更新、外部系统调用的逻辑都应该放到服务端命令里执行。原因有三个方面。第一服务端命令和数据库在同一个网络环境内省去了浏览器到服务器的往返延迟。一个前端命令如果要更新一条数据需要先把数据送过去再等服务器返回结果但如果十个更新操作放到一个服务端命令里浏览器只发一次请求服务器上依次执行十条更新性能差别非常大。第二服务端命令支持事务控制。批量更新场景下你可以把多条数据库操作包在一个事务里要么全部成功要么全部回滚。这不仅仅是数据一致性的问题也直接影响数据库锁的持有时间。事务范围越小、执行时间越短表锁和行锁的竞争就越低系统在高并发下的吞吐量就越高。第三服务端命令可以做数据库层面的批量操作。比如要更新一千条记录的状态正确做法是用一条 Update 语句按条件批量更新而不是在前端循环一千次每次都发一条请求。活字格的数据表操作命令支持批量更新模式你可以给更新命令设置条件让它一次处理一整批数据这个在月底批量处理的场景下能省掉大量的数据库往返开销。3.3 数据库层索引、锁与连接池一个都不能少活字格把业务数据存在数据库里性能的地基终究还是数据库。不管平台怎么优化数据库设计不合理一切都是白搭。这里有几个关键动作。索引设计是第一优先级。对于所有高频查询的筛选字段、排序字段、关联字段都要建索引。比如订单表按订单日期查询就必须在订单日期列上建索引如果经常按状态加创建时间来筛选就要考虑建组合索引。判断哪些字段需要索引最简单的办法是把活字格里常用的查询条件列出来对号入座。注意索引不是越多越好每个索引都会拖慢插入和更新操作这个度要把握。锁机制的理解也很重要。SQL Server默认的隔离级别是读已提交在高并发下可能会遇到锁等待甚至死锁。如果你的应用里有大量用户同时修改同一张表的同一批数据建议做两件事一是给频繁并发修改的表加上合理的聚集索引让数据物理存储有序减少页拆分的概率二是在服务端命令里控制事务时间事务内尽量不要做外部接口调用或者长时间计算。把事务时间压到毫秒级锁等待自然就少了。连接池这块活字格默认的数据库连接配置一般不用改。但要注意一个场景如果你的数据库和应用服务器之间的网络延迟很高或者数据库服务经常重启连接池里的连接可能过期失效。这种情况下建议在连接串里针对数据库类型配置合理的连接超时和重连参数避免一堆请求同时拿到失效连接然后集体报错。另外多个活字格节点共用同一个数据库时连接池会在每个节点上各自维护数据库这一侧的连接数上限要留够余量。4. 扩容设计从单机到集群的完整路径4.1 扩容时机与路径选择先垂直还是先水平活字格应用上线后随着用户量增长性能会先经历一个平稳期然后开始出现拐点。判断是否需要扩容不要等到用户投诉了再做。有个实用的办法是持续观察两个指标应用服务器CPU使用率以及数据库服务器CPU使用率的浪涌情况。如果应用服务器CPU长时间超过70%或者数据库服务器在业务高峰时的CPU峰值反复冲到90%以上就说明该考虑扩容了。扩容的第一选择永远是垂直扩容也就是给服务器加CPU、加内存。这样做的好处是改动最小不用动架构不用处理会话共享、文件共享这些分布式带来的复杂度。活字格应用服务器是.NET运行时对多核CPU的利用是比较充分的你从4核升到8核性能几乎能线性翻倍。数据库服务器也是同理大多数企业应用是数据库单点瓶颈加内存、换快的NVMe固态硬盘往往就能顶住下一轮增长。垂直扩容扛不住的时候才轮到水平扩容。水平扩容不等于简单的再买一台服务器装上活字格它意味着你要处理负载均衡、会话保持、文件共享、数据库压力分散这一整套问题。下面逐一展开。4.2 多节点部署与负载均衡实操活字格支持多台应用服务器节点组成一个集群对外通过负载均衡器分发请求。负载均衡器可以用Nginx也可以用IIS的ARR模块或者直接用云厂商的负载均衡产品。我在项目中用Nginx比较多配置逻辑很简单把活字格应用的请求代理到后端的多个节点上节点之间做健康检查有节点挂掉就自动摘除。多节点部署有几个必须处理的细节。第一个是会话保持。前面提到默认会话在进程内负载均衡层需要配置粘性会话也就是基于用户IP或者Cookie把同一个用户的请求固定转发到同一台节点。这能避免用户操作到一半被切到另一台节点导致登录态丢失。如果你不想依赖粘性会话那就需要把会话状态改造成外部存储这个改造成本比较高一般企业项目没必要做粘性会话完全够用。第二个是文件共享。用户上传的附件、导出的文件默认存在各节点本地磁盘多节点情况下必须统一存储位置。实践中我一般用NAS挂载共享目录让所有节点指向同一个存储路径如果部署在云上直接用对象存储更省心。这一步不做好用户上传的文件会随机消失是集群上线后最容易翻车的地方。第三个是活字格服务器管理控制台的节点管理。官方管理界面里可以添加节点信息让主节点知道有哪些从节点在提供服务这样计划任务、定时报表这类功能也只会在主节点执行一遍不会多个节点重复跑任务把数据库打爆。4.3 数据库高可用与读写分离的落地做法集群扩容解决了应用层的压力但数据库仍然只有一个。高并发场景下应用层的请求量翻倍数据库的查询量也跟着翻倍最终瓶颈还是会回到数据库。这就是为什么扩容设计的后半场一定是数据库的高可用和读写分离。最简单的数据库高可用方案是主从复制。SQL Server用Always On可用性组或者镜像MySQL用主从复制或者Group Replication。主库负责写从库负责读应用层配合读写分离把查询类的流量分流到从库上。活字格的数据连接配置可以单独指定不同的数据源实践中的做法是在活字格里配置一个主数据源用于业务写入和核心查询配置一个只读数据源用于大量报表查询然后通过服务端命令或者页面的数据源设置把重查询指向只读副本。这里有个细节要注意主从复制有延迟。如果你的应用对数据实时性要求很高比如用户刚提交的订单立刻要在另一张汇总表里看到那就不能无脑走从库否则会出现数据还没同步过来的体验问题。我的经验是把实时强一致的操作全部走主库允许延迟的统计报表类查询走从库这样既减轻了主库压力又不会产生业务数据不一致的投诉。另外数据库服务器的硬件配置永远要高于应用服务器。你可以在应用层堆好几台便宜机器做水平扩展但数据库一定要用好机器磁盘走企业级固态内存配大一点这是个基本的投入原则。数据库一旦成为瓶颈应用层加多少台节点都白搭。5. 常见性能问题与排查技巧实录踩过的坑挨个说5.1 五个最典型的高并发症状速查表我把自己做活字格项目过程中遇到的高频性能问题整理成了下面这张速查表遇到类似情况可以直接对照排查。症状可能原因优先排查方向页面加载非常慢网络面板显示单个请求返回几百KB页面绑定表格未分页或者OData查询拉取了全量数据开启分页检查页面上所有的OData查询和统计文本某个按钮点击后要等好几秒才有响应前端命令里循环操作数据库或者服务端命令事务范围过大把循环里的数据库操作改成批量更新压缩事务时间高峰期所有用户同时卡顿数据库CPU飙升数据库缺索引大量查询走全表扫描抓取慢查询日志针对高频筛选字段补索引集群上线后偶发性登录失效负载均衡未配置粘性会话在Nginx或云负载均衡上开启基于IP或Cookie的会话保持用户上传的附件时有时无多节点部署但文件存储未做统一共享把附件目录改为NAS共享存储或对象存储5.2 压测方法论自己动手摸清系统底线很多项目上线前不做压测上线后被突来的并发打懵了。实际上用活字格搭好系统后完全可以自己做一轮简单压测不用上复杂的压测平台一台测试机装个JMeter就够了。压测的核心不是追求能扛多少并发这个数字而是要找出两个东西系统的最佳工作点和崩溃临界点。我的做法是分三档来测先模拟日常平均负载比如50个并发用户同时进行查询、录入操作看响应时间是否稳定再模拟业务高峰比如200个并发用户看CPU和数据库的指标变化最后模拟极端冲击看看系统在多大并发下出现明显劣化比如响应时间从几百毫秒飙升到几秒。压测过程中要同时观察三个层面。应用服务器看CPU、内存、线程数数据库看CPU、连接数、锁等待时间网络看带宽占用。哪个先到瓶颈就是当前系统的最短板优先解决它。我压测过的一个中大型项目应用服务器在有缓存支撑的情况下能轻松扛住数百并发但数据库侧的锁等待在高并发写入场景下明显上涨最后通过优化索引和拆分事务才把这块降下来。对你来说压测的价值不是验证平台行不行而是为扩容计划提供数据依据什么时间点该扩容、先扩哪一层压测数据都能给出明确答案。5.3 一个真实案例的完整复盘去年我做了一个制造业订单管理系统的性能优化项目系统是用活字格搭建的上线三个月后销售部门集中反馈月末下单特别卡。我到现场排查后发现问题集中在订单录入页面页面有一张表格绑定了订单明细表另一个区域展示了当月的订单汇总金额。第一层问题出在汇总金额的实现方式上。最初开发在这里放了一个统计字段页面上绑定了一个OData查询每次页面加载都对当月整张订单表做一次Sum聚合计算。订单表当时已经有十几万条记录这个聚合查询要扫描大量行。更糟的是表格分页虽然开了但这个汇总查询没有缓存每个用户打开页面都会触发一次月末大家同时报单时数据库瞬间收到几十个全表聚合请求CPU直接打满。我的处理分三步。第一步把当月订单汇总从实时查询改成定时汇总用一个计划任务每五分钟把汇总结果写入一张统计表页面直接读取统计表的数据数据库压力立刻降了下来。第二步给订单表的订单日期列和客户编号列补上组合索引让高频查询走索引而不是全表扫描。第三步把当月新增订单的录入命令改成服务端命令执行服务端命令里用批量插入模式提交数据而不是前端逐行提交。这三步做完月末高峰时段的数据库CPU使用率从之前的90%以上降到了40%左右页面加载时间从三到五秒降到了秒开。整个过程没有动架构、没有加服务器纯粹靠应用设计和数据库优化就把问题解决了。这也验证了我前面的判断企业级低代码平台的性能问题八成出在设计层而不是平台层。6. 什么场景真的不适合活字格别硬推6.1 低代码平台的硬伤这三个场景要谨慎实事求是地讲活字格不是万能的有几个场景我建议选型时直接劝退省得后面双方都难受。第一个是高频实时计算场景。比如设备物联网平台里每一秒都要接收大量传感器数据并立刻计算展示这种场景本质上是流式计算适合用专门的时序数据库加流处理引擎来做。低代码平台的强项是业务数据的管理和流转硬让它去扛每秒上千条的实时写入和计算纯属用错工具。第二个是超大规模的数据分析。一张表几千万甚至上亿行需要做复杂的多表关联分析、大数据量聚合报表这种活应该交给数据仓库和分析型数据库活字格更适合做结果数据的展示和业务操作而不是直接在业务库上跑重型分析。第三个是极度依赖复杂算法逻辑的场景比如复杂的排产算法、路径规划、大规模规则引擎。这些逻辑写成自定义代码更合适虽然活字格支持通过服务端命令调用外部API或者自定义扩展但如果核心业务就是重算法硬套低代码平台会非常别扭。6.2 混合架构让专业的东西干专业的事上面说的这些场景并不意味着你要放弃整个低代码平台而是要学会做混合架构。我见过不少成熟的落地案例都是活字格做业务端负责单据录入、流程审批、权限管理、报表展示这些企业日常管理的核心场景同时把高性能的后端服务独立部署用消息队列、缓存、专门的中间件来处理高吞吐的数据流转和计算任务活字格通过HTTP调用这些外部服务完成数据的双向同步。这种混合架构的好处是既保住了低代码带来的开发效率又避免了平台边界之外的能力短板。你在选型时跟客户和技术团队讲清楚这个边界大家对低代码的信心反而更足因为知道什么活它干得好、什么活该交给别的工具。性能设计本质上就是一场匹配游戏把每个请求放到它该去的层让每个组件做它擅长的事系统的整体能力上限自然就上来了。最后再分享一个我自己的体会在做活字格项目的性能规划时别把时间浪费在和原生开发能不能跑得更好这种问题上争对错。真实场景里一套系统能不能扛住并发取决于你在架构上做了多少正确的取舍而不是用了什么开发工具。我见过太多原生开发写出来的系统因为设计粗糙照样被并发压垮也见过认真做分页、缓存、索引、集群的低代码系统在几百上千并发下跑得稳稳当当。工具只是起点设计才是上限。做企业级应用踏踏实实把每个环节的功课做足比纠结平台的帽子重要得多。