这么说吧. 目前还用 K8S 这些东西的, 基本不是大厂就是外企. 前几年好多中厂小厂大规模的推广微服务跟云原生, 所以涉及到大量对 K8S 二开的工作, K8S 二开相关岗位一时风头无两. 这两年很多企业开始下云, 开始开源节流, 开发团队编制严重缩编甚至有大量的中厂小厂一批一批的倒闭. 剩下的这些中小厂也就都普遍不再搞什么微服务云原生了, 技术架构开始越来越保守, 也不搞什么 Docker 什么 K8S 了.

反正我知道的好多公司, 这两年技术团队腰斩, 有的技术团队一次性裁员 70%～ 80% 剩下的人根本就没那个人力跟精力去维护这些东西. 原来技术团队几十号人, 不微服务化, 不用 K8S 根本搞不定... 不用这些不行, 甚至为了维护这些乱七八糟的东西还要留一个 DevOps 岗. 现在技术团队就几个人, 每个人手里都一大堆功能要开发, 部署就怎么简单怎么来了, 最后就还是回到原来的直接部署到物理机的模式, 最多保留个 CI/CD.

asp.net core

而且嵌入式不吃行业. 上家公司做彩电下家公司搞汽车 但是你哪边都能搞.
这点比我们做上层软件的好得多. 我们做上层应用的必须在一个领域吃透. 不仅自己技术要牛逼业务也得熟悉才能混得下去.

嵌入式可以呀... 没必要转啊. 无论什么时候, 嵌入式这东西就业面都极其广泛, 就算是未来三战了, 做嵌入式的也比我们这些也上层业务的开发好. 到时候你们转进做射频做军用我们只配吃蘑菇.

@xmumiffy 啊 疫情时候西安健康码相关开发公司的事情


@nexo 那你要是这么说的话 如果喊你去写 React 的话 你会吐的

Electron + Cordova

@YuuuuuuH 还不如 /people/getPersonRelInOrg?orgid=&personid= 来的简单明了。

@YuuuuuuH 某个人在某个组织内的用户关系

视情况.
如果是系统内互相调用, 一般就是 get/post. 没啥必要搞什么 put delete...
如果是开放 API, 而且本身也比较简单 (例如只是开放个 WEB 接口给三方读写数据之类的), 可以用 RESTful API.

我个人是不喜欢 RESTful 这个风格的. 太简陋了, 对于一些复杂的业务接口来说, 要么把 URL 搞得极其抽象
(如: /api/v3/userrelationshipinorganization/7333/8964) 要么把接口拆散拆得跟被爆破了一样, 然后让前端做整合层.

无论哪种其实都很恶心.

Electron 挺好的啊, 非啥必须要用 QT 啊...
又简单又好看. 哪儿还有这么好的框架...

innodb_buffer_pool

首先你需要看下数据库物理文件是存放在什么地方的. 是不是 NVME 盘.
其次看下设置中 INNODB_BUFFER 设置的多少. 越多越好.
还有发一下 mysql 版本.

个人认为, MYSQL 的能力并不足以支撑单表 2GB 的数据量. 如果你确实有如此巨大规模的数据量, 建议换 MSSQLServer 或者 Oracle. 别想着什么加什么 ClickHouse, Doris...

相比招一些一年要付 20W 年薪的开发比, 买一个数据库产品授权成本并不算高.

主流是下云, 单体化.

要按你这么说, Element UI / AntDesign Vue 官网上的毛病更多. 各种打不开跟运行不了的例子.
怎么, 你不照样用的挺嗨么?

有 BUG 不可怕, 尤其这种开源项目, 本来成员能力跟责任心就参差不齐, 外加项目规模巨大, 面面俱到是基本不可能的. 关键是 issue 发出来多久能有回复. 至少看, 目前主流这些开源组件, 出问题时候回复的效率都还是蛮高的.

如果是桌面程序 没可能.
服务程序, 给指定用户 read + execute 权限, 去除其他用户读权限就行了.