为什么要换掉这些技术栈呢，是因为这次 log4j 的事件吗？

给 LZ 提供一个新的思路，直接使用各种 managed service ，人家有专门的安全团队、运维团队，出了问题一个电话人连夜修；只要付钱，轻松省事。

Managed elastic - https://www.elastic.co/elastic-stack/
Managed spark - https://databricks.com/

最简单就是交给数据库去处理事务

数据库事务设计出来就是处理这样的业务场景的，为啥大家第一反应想不到用它呢？

这个需要 out of core computation
不考虑用 GPU 的话可以考虑

http://xarray.pydata.org/en/stable/dask.html
或者
https://docs.dask.org/en/stable/array.html

ConfigMap 变更之后需要重启服务，有几种办法；
1. 手动模式 kubectl rollout restart xxxxx 重新启动 deployment
2. 需要将 deployment 指向一个新的 configmap 才能触发更新；例如老的 configmap 叫 config1 ，新的更改了里面的部分值之后，重命名成 config2 ，然后 deployment 里面指向 config2 。


一些做 release 管理的工具，例如 kustomize 用的是方法 2 ； helm 用的是生成一个 configmap hash 的 annotation 放在 deployment 上；每次 configmap 内容变更之后，这个 annotation 也会变更，所以会触发 deployment 自动更新

先写 openapi spec -> 生成接口文档 -> 生成 mock server -> 前端开始工作的同时，后端开始补实现

接口变更也是 也从改 spec 开始，然后刷新文档，然后后端再补实现

@sslyd 你用模板引擎，做 server 端渲染，返回 html 就不是；
你只写 api ，例如用 DRF ，前端用其他框架做的就是

模板引擎还是有生存的空间，并不是所有的 web 都需要做成 SPA 的

Shopify 的 price rule 设计参考一下？没有奇奇怪怪的优惠玩法这个可以覆盖大部分优惠类型了

https://shopify.dev/api/admin-rest/2021-07/resources/pricerule

django-admin

初期 2 ，后期 1 ； ORM 搞不定的时候走 raw

这玩意儿自己可以成为一个项目了，如果做的精细点的化；
建议评估一下这个功能是不是会喧宾夺主，让 LZ 忘了自己原来要做的系统

拿 C 写的东西，基本都得会 C 语言之外得东西 -- 编译器、硬件、内核、数据库，和程序语言有关也没关

这类项目还是有一些的。例如 Instagram 的魔改版本的 python ，带 jit 的，https://github.com/facebookincubator/cinder

但是这玩意儿虽然开源但是 FB 没有资源支持社区。

Lz 的需求建议直接买 API 吧。
自己弄的话也得简单讲一下需求把，文件类型是什么？合同身份证文件还是带文字的图片？识别的内容是什么，文字表格还是啥？对精度需求是咋样的？

上来调个包就搞定了，这是不让这么多做 ocr 的公司吃饭啊

模板引擎 + bootstrap css + htmx 这是比较现代的老古董搞法

还在手写的飘过

这个不是 go 的问题；是缺乏像 spring 这样的杀手级框架。

可以上 proto+grpc

> 不同语言间的 rpc 我看了下不太好弄；
这个是 proto 强项，定义文件编译各种语言

> 而且在之前的架构设计上就把这几个子系统做得很独立，rpc 会耦合起来（也许是我 rpc 用得不太对）；
需要把交换的数据格式和暴露的接口定义出来；具体实现各个系统独立，不会耦合


> 因为也有多地部署的需求，像流媒体系统这种；
grpc 还支持流式传输；多地部署你需要配合服务网格或者 load balancer 这样的设施使用

我觉得有一个点大家都关注的很少 - 国外很多创业公司或者小企业，能够以很精简的人员和技术架构，做十分巨大的业务量（不是简单的以峰值 QPS 之类来衡量，而是能做实在的影响很多人工作生活的产品）；在有了钱和业务量之后，这类公司也没有一味的盲目扩张人员和做不同的业务，而是依然保持了这个精简做事的方法，继续做自己擅长的事情。

在技术方面，很多公司写的介绍技术方案的博客都十分的朴素，解决方案在国内看来甚至都有些简陋。
例如 github 介绍他们分库的方案： https://github.blog/2021-09-27-partitioning-githubs-relational-databases-scale/
notion 价绍他们分表的方案： https://www.notion.so/blog/sharding-postgres-at-notion

读来都语言平实，很多人看了之后都很惊讶他们现在才在做分表分库。

这种对业务和技术比较务实的态度，追求简单但是高效达成目标的做事方法，我觉得是很值得夸赞和学习的。

应该没有比这个质量更过硬的分布式可能了： https://pdos.csail.mit.edu/6.824/schedule.html

找个中文字幕，好好做做作业（用 go ），水平会突飞猛进