从烟囱到网格：重思数字中国技术架构的破局路径
被忽略的分层适配冲突
过去十年，各地数字化建设大多走的是「先建系统后连网」的路子。条线部门有自己的业务系统，属地政府有自己的便民平台，标准不统一，接口不对接，慢慢就成了一个个数据烟囱。很多地方想拆烟囱，上来就要搞全集中，把所有数据都迁到省级云平台，结果反而出问题。
传统政务烟囱式数字系统分层图
去年我接触过一个苏南的项目，属地开发了一套针对个体工商户的帮扶系统，精准匹配扶持政策，原来运行得很好，省级要求全量迁库，迁完之后，原来毫秒级的政策匹配，变成了十秒级的响应，个体户办事都嫌慢，没人用了。
为什么？核心就是架构分层没搞对。把本该在边缘侧处理的高频低敏业务，硬搬到核心层，不仅拖慢了响应速度，还增加了核心层的安全压力。
很多人默认，越集中越好，越统一越先进。 这是错的。
架构设计本身，就是平衡的艺术。涉及公民核心身份信息、国家关键政务数据的部分，必须集中，必须统一标准，这是底线。但是面向群众的高频创新场景，面向产业的差异化应用，必须给基层留足适配空间。不然就是一放就乱，一收就死。
核心底座的定位不能偏
现在提到底座，很多人的第一反应就是把所有东西都装进去。其实核心底座的核心作用，是给上层业务托底，不是替上层业务做决定。我见过太多项目，把底座做成了大而全的锁，所有应用必须用指定的组件，必须走指定的流程，一点点调整都做不了。说实话，这不是底座，这是紧箍咒。
数字中国核心信任底座架构示意图
今年春天在广州看的一个项目，做得就有意思。核心底座只做三件事：统一身份认证、统一数据信任存证、统一云网调度。剩下的应用开发，只要符合安全规范，用什么技术栈，走什么流程，基层自己定。去年他们推的独居老人上门探视项目，基层技术团队半个月就搭出了原型，上线三个月覆盖了近十万老人，没花一分冤枉钱。
反过来，之前北方某城搞的统一政务平台，要求所有应用必须适配指定的中间件，光适配费就花了近三百万，上线后还频繁出兼容性问题，原来好用的便民小程序反而用不了，你说找哪说理去。
技术架构的好坏，从来不是看PPT上画得有多漂亮，是看能不能解决实际问题。
开放层的演化要留灰度
开放层的演化要留灰度
搞数字化，最终还是要给产业用，给市场留空间。很多地方的架构，一开始就把所有标准定死，所有接口锁死，第三方创新根本进不来。之前共享出行刚起来的时候，很多城市的交通监管系统接不进去，就是因为原来的架构根本没预留第三方场景的接口，只能推倒重来，浪费了几个亿的投入。
现在的做法，其实已经慢慢清晰了。开放层做数据可用不可见的能力输出，不碰原始核心数据，只输出计算能力和接口。长三角现在搞的跨区域企业信用共享，就是这个思路。江苏的企业要去浙江投标，不用把原始工商数据传到浙江，直接通过隐私计算出一个信用结果，双方都能用，数据还不用出域，安全和效率都兼顾了。
不过话说回来，灰度不是无边界。现在很多人喊着要开放，要搞产业创新，就把什么数据都往外放，这是另一个极端。去年有个地方搞智慧城市，把小区的人流监测数据开放给创业公司做精准营销，结果闹出了隐私泄露的问题，被通报整改，项目直接停了。
所以架构设计里，边界必须写死。什么层能出什么数据，能放什么接口，什么数据绝对不能碰，一条一条都理清楚，不能含糊。
现在很多地方一提起搞建设，就忙着上大项目，堆大模型，换架构，其实很多时候，原来的架构只要调一调分层，理一理边界，就能用。别为了赶政策风口，瞎折腾钱。毕竟，能解决真问题的架构，才是有用的。