怎么都在答非所问，架构师运用自己的经验帮团队少走弯路，其次不同团队之间的沟通，以及将技术语言转成领导能听懂的语言。

上面那几个， 谁跟你说架构都是高并发，高可用，你搞高并发，高可用的场景都不匹配，那就是白白浪费钱也没有产出。

如果就是个小公司，建议从可维护性上多入手，良好的抽象可以帮助降低复杂度，并使系统易于修改和适应新的应用场景。

架构难的还不仅仅是经验，难的是人际沟通，v2ex 上参与架构的并不多。

这个是语言哲学语言设计的范畴，无所谓好坏，支持运算符重载能找到一堆理由，不支持运算符重载的也有一堆理由。

新语言如 rust 也有通过 trait 来支持运算符重载的

@Leviathann #105
你连代码都不会写就开始瞎说的水平真强, xloger 填了一个 python 代码，被你说成是 go 代码

回复有点少啊，支持一下凹语言， 毕竟是基于 go 开发出来的针对 wasm 的语言。

我早就屏蔽这个冯若航和他写的一堆玩意，你不要听风就是雨。

看你的描述，这个公司运维技术含量很低，不要小看运维技术，你去的就是一个业务或者项目型公司，不需要多少高级自动化运维和运维开发技术。
其实你就是被公司安排到了一个边角部门了， 有时间自己补补知识，赶紧跳吧。

k8s 调度本身是基于 linux 内核的完全公平调度器 CFS, 要想做到绝对均衡的调度是不可能的，想实现一些特定的调度可以用 K8s 调度框架来实现插件，
简单的做法就是给机器打上各种标签，然后用 nodeselector 就好了。

这种情况估计你们需要自己研发了，ansible 模块通过 ssh 协议（或者 Kerberos 、LDAP ）推送到被管节点执行，执行完之后自动删除， 几万台服务器肯定是满足不了的, 每个服务器装 agent 是需要的

未来存储肯定是 csi 驱动方式为主， 也减少了 k8s 的 bug 和 代码耦合。对性能和可靠性要求比较高的场景，NFS 就不适合。

k8s 存储都是分场景来选的， 另外 k8s 最近几个版本都有存储驱动的弃用和移除，移除云服务厂商的 in-tree 卷驱动，都是让存储厂商来提供 csi 。

建议别尝试了， 通过修改 sqlite 数据库文件同步到共享存储的方式的方式是错误的，不要研究了，
另外出了问题你也搞不定，sqlite 是不存在跨机操作数据文件的方式的，sqlite 对数据文件的保护的确是操作系统的文件锁，
另外 nas 这种共享存储 不适合关键的数据库主备。

我也只见过 mysql, oracle 数据库搞这种共享存储的数据库集群的成熟方案，sqlite 别搞。

1.基于共享存储的方案 SAN
方案介绍：SAN(Storage Area Network)简单点说就是可以实现网络中不同服务器的数据共享，共享存储能够为数据库服务器和存储解耦。使用共享存储时，服务器能够正常挂载文件系统并操作，如果服务器挂了，备用服务器可以挂载相同的文件系统，执行需要的恢复操作，然后启动 MySQL 。

2.基于磁盘复制的方案 DRBD
方案介绍：DRBD(Distributed Replicated Block Device)是一种磁盘复制技术，可以获得和 SAN 类似的效果。DBRD 是一个以 linux 内核模块方式实现的块级别同步复制技术。它通过网卡将主服务器的每个块复制到另外一个服务器块设备上，并在主设备提交块之前记录下来。DRBD 与 SAN 类似，也是有一个热备机器，开始提供服务时会使用和故障机器相同的数据，只不过 DRBD 的数据是复制存储，不是共享存储。

其他方式是通过网络 IO 的主从之类的方案

题外话，sqlite 不适合独立出来做数据服务器，适合嵌入在程序中， 这种就算用 sqlite 需要魔改，当然市面上已经有了这种魔改 sqlite 作为数据库引擎的高性能分布式数据库 (bloomberg 出的 comdb2)
https://github.com/bloomberg/comdb2

sqlite 也是数据库，只不过是可以嵌入程序运行的数据库，像这样的嵌入式数据库有 SQLite, RocksDB, and DuckDB, 多尝试尝试

甲方说什么就是什么， 都限定了信创数据库，那就用起来，其他数据库根本不会给你过审的。

一般使用 go 的一些静态检查分析工具，过滤掉大多数问题代码，go vet 工具