[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"consumer-news-detail-945":3,"consumer-news-interaction-945":38,"consumer-news-related-945":41},{"detail":4,"item":34},{"card":5,"schemaVersion":21,"fields":22,"content":28},{"id":6,"kind":7,"targetType":8,"targetId":9,"subtype":7,"typeLabel":10,"title":11,"subtitle":12,"summary":13,"coverUrl":14,"badgeText":14,"href":15,"sourceName":12,"meta":16,"metrics":18,"tags":19,"resolved":20},"NEWS_ARTICLE:945","news","NEWS_ARTICLE",945,"资讯","CURD系统怎样做出技术含量：微内核改造","博客园","建「中心」还是「平台」？ 10年前在一个公司，公司里经常需要做线上活动。对开发来说，就是通过不同的活动页面进行注册、登录，之后会有一些个性化的小活动：领取小礼物、领取红包或者参加抽奖。 前端和后端疲于天天做各种换汤不换药的注册、登录。开发方式基本是把上次的代码拷贝一份，在此基础上做修改，来支撑新活动","","\u002Fnews\u002F945",[17],"2026",{},[],true,"consumer-content-detail-v1",{"sourceName":12,"authorName":23,"summary":13,"description":13,"publishTime":24,"updateTime":25,"sourceUrl":26,"language":27},"编程一生","2026-09-10T10:38","2026-09-11T15:21:59","https:\u002F\u002Fwww.cnblogs.com\u002Fxiexj\u002Fp\u002F22917411","中文",{"format":29,"policy":30,"normalized":20,"html":31,"text":32,"wordCount":33,"hasBody":20},"HTML","NEWS_CONTENT_V1","\u003Cp>建「中心」还是「平台」？\u003C\u002Fp>\n\u003Cp>10年前在一个公司，公司里经常需要做线上活动。对开发来说，就是通过不同的活动页面进行注册、登录，之后会有一些个性化的小活动：领取小礼物、领取红包或者参加抽奖。\u003C\u002Fp>\n\u003Cp>前端和后端疲于天天做各种换汤不换药的注册、登录。开发方式基本是把上次的代码拷贝一份，在此基础上做修改，来支撑新活动。大家就开会一起想解决办法解决重复开发的问题。大龄前端架构师说：「可以做工具自动生成注册、登录代码。」新生代的架构师说：「这个意义不是很大，应该做平台来解决。」10年过去了，现在我再回头想想。觉得当初应该建「中心」来解决。\u003C\u002Fp>\n\u003Cp>首先明确一下「平台」和「中心」的区别。中心是个点，平台是个面。一般来讲，平台更大。中心是为了解决复用的问题，一般用在公司内部进行统一开发、统一管理、统一维护。比如业务上有「活动中心」；技术上有「配置中心」。平台可以对内也可以对外，按咱们「编程一生」群友的说法：是SaaS的。比如各种开放平台，还有网联清算等业务平台，各种交易平台。一般需要一些配套：用户注册、登录、权限控制等。\u003C\u002Fp>\n\u003Cp>下面截图出于对群友信息的保护，隐藏了昵称和头像。\u003C\u002Fp>\n\u003Cp>我们当时面临的问题，是要解决公司内部复用的问题，建立「中心」是合适的。当然，如果系统演进的好，以后把能力开发出去做成「平台」也未可知。但首先要是「中心」。\u003C\u002Fp>\n\u003Cp>用「微内核架构」解决问题\u003C\u002Fp>\n\u003Cp>我们当时遇到的问题，后端之所以每次都要参与开发是因为当时还是前后端不分离的架构。后端在注册、登录部分的修改主要是跳转的页面不同。现在都是前后端分离的架构了。后端只提供数据，流程之间的串联基本靠前端实现。所以后端只要有真正新功能的时候才需要开发，重复开发并不多。\u003C\u002Fp>\n\u003Cp>前端对应每一个需求都是有一定的开发量的。但是对于这种重复工作多的，页面可以通过配置出来，而不用真正意义的开发。甚至可以通过低代码或者零代码的方式拖拖拽拽就把功能实现了。核心就是把原来的功能分成一个个小组件。\u003C\u002Fp>\n\u003Cp>这听起来好像当下很多项目就是这么做的。怎样改造成微内核架构呢？\u003C\u002Fp>\n\u003Cp>不需要再做什么了。这已经是一个微内核架构的项目了。不管对于前端还是后端，核心服务(内核)是注册、登录和做活动。具体产品和运营那边的奇思妙想，新的活动类型，可以视为插件。需要的时候开发出来插上，如果发现效果不好，要彻底弃用就拔下来。微小的核心服务+可插拔的插件，就是一个标准的微内核架构。\u003C\u002Fp>\n\u003Cp>受到的质疑\u003C\u002Fp>\n\u003Cp>之前和别人聊的时候，人家质疑时我说：你这样，安装插件的时候，服务需要重新发布，需要重启吗？\u003C\u002Fp>\n\u003Cp>我说：需要开发，也需要重新发布上线。\u003C\u002Fp>\n\u003Cp>人家说：需要重启就不是一个微内核的架构。\u003C\u002Fp>\n\u003Cp>我心里知道他理解的不对，但一时没有想清楚他问题的本质，当时没有做任何的回应。现在想想应该这么来思考：\u003C\u002Fp>\n\u003Cp>先看看标准的微内核架构代表：eclipse\\Intelij idea这样的IDE(IDE,即Integrated Development Environment,是\"集成开发环境\"的英文缩写,可以辅助开发程序的应用软件 )工具。如果需要的插件是现在应用市场上没有的，也是需要重新开发的吧？开发出来就要上线吧？上线的方式可能只是打个包放到外部可以访问的平台上。但是IDE要集成插件引入之后也需要重启IDE吧？连微内核架构的经典代表IDE都是需要重启的，所以从是否需要重启来作为是否是微内核架构的标准是有失偏颇的。\u003C\u002Fp>\n\u003Cp>微内核的本质是核心逻辑是有限的，可以维持相对稳定。其他功能可以方便的集成和拆除。它是一种思想，符合这种思想的都是微内核架构。面试时或者其他场景，你完全可以大胆的去说。\u003C\u002Fp>","建「中心」还是「平台」？ 10年前在一个公司，公司里经常需要做线上活动。对开发来说，就是通过不同的活动页面进行注册、登录，之后会有一些个性化的小活动：领取小礼物、领取红包或者参加抽奖。 前端和后端疲于天天做各种换汤不换药的注册、登录。开发方式基本是把上次的代码拷贝一份，在此基础上做修改，来支撑新活动。大家就开会一起想解决办法解决重复开发的问题。大龄前端架构师说：「可以做工具自动生成注册、登录代码。」新生代的架构师说：「这个意义不是很大，应该做平台来解决。」10年过去了，现在我再回头想想。觉得当初应该建「中心」来解决。 首先明确一下「平台」和「中心」的区别。中心是个点，平台是个面。一般来讲，平台更大。中心是为了解决复用的问题，一般用在公司内部进行统一开发、统一管理、统一维护。比如业务上有「活动中心」；技术上有「配置中心」。平台可以对内也可以对外，按咱们「编程一生」群友的说法：是SaaS的。比如各种开放平台，还有网联清算等业务平台，各种交易平台。一般需要一些配套：用户注册、登录、权限控制等。 下面截图出于对群友信息的保护，隐藏了昵称和头像。 我们当时面临的问题，是要解决公司内部复用的问题，建立「中心」是合适的。当然，如果系统演进的好，以后把能力开发出去做成「平台」也未可知。但首先要是「中心」。 用「微内核架构」解决问题 我们当时遇到的问题，后端之所以每次都要参与开发是因为当时还是前后端不分离的架构。后端在注册、登录部分的修改主要是跳转的页面不同。现在都是前后端分离的架构了。后端只提供数据，流程之间的串联基本靠前端实现。所以后端只要有真正新功能的时候才需要开发，重复开发并不多。 前端对应每一个需求都是有一定的开发量的。但是对于这种重复工作多的，页面可以通过配置出来，而不用真正意义的开发。甚至可以通过低代码或者零代码的方式拖拖拽拽就把功能实现了。核心就是把原来的功能分成一个个小组件。 这听起来好像当下很多项目就是这么做的。怎样改造成微内核架构呢？ 不需要再做什么了。这已经是一个微内核架构的项目了。不管对于前端还是后端，核心服务(内核)是注册、登录和做活动。具体产品和运营那边的奇思妙想，新的活动类型，可以视为插件。需要的时候开发出来插上，如果发现效果不好，要彻底弃用就拔下来。微小的核心服务+可插拔的插件，就是一个标准的微内核架构。 受到的质疑 之前和别人聊的时候，人家质疑时我说：你这样，安装插件的时候，服务需要重新发布，需要重启吗？ 我说：需要开发，也需要重新发布上线。 人家说：需要重启就不是一个微内核的架构。 我心里知道他理解的不对，但一时没有想清楚他问题的本质，当时没有做任何的回应。现在想想应该这么来思考： 先看看标准的微内核架构代表：eclipse\\Intelij idea这样的IDE(IDE,即Integrated Development Environment,是\"集成开发环境\"的英文缩写,可以辅助开发程序的应用软件 )工具。如果需要的插件是现在应用市场上没有的，也是需要重新开发的吧？开发出来就要上线吧？上线的方式可能只是打个包放到外部可以访问的平台上。但是IDE要集成插件引入之后也需要重启IDE吧？连微内核架构的经典代表IDE都是需要重启的，所以从是否需要重启来作为是否是微内核架构的标准是有失偏颇的。 微内核的本质是核心逻辑是有限的，可以维持相对稳定。其他功能可以方便的集成和拆除。它是一种思想，符合这种思想的都是微内核架构。面试时或者其他场景，你完全可以大胆的去说。",1439,{"id":6,"kind":7,"title":11,"summary":13,"image":14,"href":15,"meta":17,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":37},"#2563eb","16 \u002F 10",[7,8],{"targetType":8,"targetId":9,"likedByMe":39,"likeCount":40,"commentCount":40,"contentLikeCount":40,"contentCommentCount":40,"sourceLikeCount":40,"sourceCommentCount":40},false,0,[42,51,57,63,72,79,85,92],{"id":43,"kind":7,"title":44,"summary":45,"image":46,"href":47,"meta":48,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":49},"NEWS_ARTICLE:927","HelloCrab - 短视频开源爬虫，仅供学习参考","HelloCrab 基于 Avalonia、Playwright、AI与 FFmpeg 的跨平台桌面采集器，支持9大平台，以及 Android、iOS、Browser 远程控制端。 Made By ChatGPT & Vincent with ❤ 平台 是否接入 哔哩哔哩 ✅ 抖音 ✅ 快手","https:\u002F\u002Fwww.cnblogs.com\u002Fhupo376787\u002Fp\u002FScreenshot\u002FWindows.jpg","\u002Fnews\u002F927","2026 · 软件开发",[50],"软件开发",{"id":52,"kind":7,"title":53,"summary":54,"image":14,"href":55,"meta":48,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":56},"NEWS_ARTICLE:929",".NET 异常处理的\"暗门\"：代码里写满 catch，你依然能抓住它——从一个 AI Agent 运行时的源码说起","一个健壮的系统，必然到处都是有意的 catch；异常被消化不等于问题不存在。 观测与韧性，是一个硬币的两面——降级逻辑保证系统不崩，FirstChance 保证你能看见它为什么降级。","\u002Fnews\u002F929",[50],{"id":58,"kind":7,"title":59,"summary":60,"image":14,"href":61,"meta":17,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":62},"NEWS_ARTICLE:928","架构师化繁为简，执行者化简为繁","新手改三天，你改三行——反而是你显得更不重要。因为化繁为简做得越纯熟，产出看起来越小。这篇聊聊两种能力的辩证关系，以及为什么'看不见'的那部分工作，恰恰是最难的部分。","\u002Fnews\u002F928",[7,8],{"id":64,"kind":7,"title":65,"summary":66,"image":67,"href":68,"meta":69,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":70},"NEWS_ARTICLE:930","基于 vLLM+Nginx 构建负载均衡推理集群","企业内部私有环境部署大模型推理集群时，很容易遇到流量调度混乱、节点负载失衡、会话上下文丢失、接口缺少鉴权防护等一系列问题，单 vLLM 推理节点难以支撑并发请求。本文基于 Ubuntu 22.04 系统环境，搭建 Nginx + vLLM-Semantic-Router + vLLM-Router","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F1379525\u002F202609\u002F1379525-20260910165534385-2022408098.png","\u002Fnews\u002F930","2026 · 人工智能",[71],"人工智能",{"id":73,"kind":7,"title":74,"summary":75,"image":76,"href":77,"meta":69,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":78},"NEWS_ARTICLE:932","2026年AI编程工具大全，33个主流工具一次看懂","事情是这样的，前两天看到一张图，是某个社区官网的「支持的工具」清单，我数了数，整整31个AI编程工具。 两年前这份清单撑死5个，现在直接31个，而且我居然每一个都认识。。。 干脆整理成一篇，顺手把最近字节的TraeWork和豆包工作也补了进来，凑成33个。 今天给大家推荐一遍，每个工具说说它是干什么","https:\u002F\u002Fimage.kjdaohang.com\u002Fimg\u002F20260909210838518.png","\u002Fnews\u002F932",[71],{"id":80,"kind":7,"title":81,"summary":82,"image":14,"href":83,"meta":17,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":84},"NEWS_ARTICLE:931","SH 中文化样例数据使用手册","在数据库演示与 PoC 场景中，Oracle 自带的 SH 示例模式虽然经典，但英文维度数据往往让国内演示效果打折扣。笔者整理了一套方案：保留 SH 标准英文对象名，同时装载中文化维度数据，并按参数生成可复现的销售历史数据，方便个人测试与概念验证。 01 | 环境准备 使用前请确认满足以下条件： O","\u002Fnews\u002F931",[7,8],{"id":86,"kind":7,"title":87,"summary":88,"image":89,"href":90,"meta":48,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":91},"NEWS_ARTICLE:933","写给 C++ 工程师的 OpenClaw.NET 上手指南：用你熟悉的 C++ 思维，跑起一个生产级 AI Agent","它像一个「基于 boost.asio + REST 端点的常驻服务」——对外是 HTTP \u002F WebSocket \u002F 各 IM 的 webhook，对内跑着一个能调工具、读写记忆、跨渠道对话的 AI Agent——只不过协程不用你手写 promise_type，内存不用你管 new\u002Fdelete。","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F510\u002F202609\u002F510-20260905070811424-1837144874.jpg","\u002Fnews\u002F933",[50],{"id":93,"kind":7,"title":94,"summary":95,"image":96,"href":97,"meta":69,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":98},"NEWS_ARTICLE:935","[Agent Memory \u002F 强化学习] MemPO源码学习笔记 ---（1）--- 总体","[Agent Memory \u002F 强化学习] MemPO源码学习笔记 （1） 总体 目录[Agent Memory \u002F 强化学习] MemPO源码学习笔记 （1） 总体0x00 概要0x01 基础 & 背景1.1 用RL训练记忆系统的要点1.2 主要难点1.3 主要思路1.4 RL训练方案1.","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F1850883\u002F202609\u002F1850883-20260906190854637-986949885.jpg","\u002Fnews\u002F935",[71]]