0，k8s 要求禁用，所以基本没用过

java 把，生态在后端吊打 node，项目可大可小，node 除了 io 好有其他任何优势？而且后端 jvm 上有很多新语言，kotlin 这种既兼容 java 又在语法上有很多优化，写出来的东西并不重

后端这样存其实算是常规操作。前端好像有个 decimal.js （好像叫这个）的库可以做精确的数字运算，我觉得 lz 可能需要的是这个

@dapengzhao 没搞懂你什么意思，如果你是有其他传统的关系数据还需要管理，那你这些数据还是用 mysql 这种关系库就行了啊

@dapengzhao 那专业的时序数据库比较合适，influxdb 或者 promethus 这种。用 grafana 可视化也简单

路由的什么信息？ url 这种 elasticsearch 检索和可视化（用 kibana ）比较好，如果是数字指标 Prometheus+grafana 这套比较合适

web 层，rest 接口这些小公司还是别用，一没这个性能需求，二开发难度比 java+spring 还是 php 那些差太多。如果 go 以后能有 java 的注解这种东西（可能不会有，毕竟会多很多魔法），包管理做好一点，也许能成为 web 开发一哥

能用基本类型绝不要用包装类，我清楚很多用包装类型是应为数据库默认值一般为 null。但用包装类型生产环境的空指针异常会让你想死（特别是 java 的自动装箱、拆箱，你写的时候根本不会考虑数据是不是 null 的）。这点 kotlin 有?来保证安全，真的好太多

别用关系库，虽然上面有人做过方案但是和专门的时序数据库没得比。哪怕在时序数据库里，influxdb 这种自己实现底层存储的都强国 opentsdb 这种依赖 hbase 的好几倍。

我之前在做服务器监控的时候顺带研究过这块，最开始用的 elasticsearch 做采集，一天的数据有 20g，后来换成了 promethus 一天就 500m 都没有。由于关系库不会像专门的时序数据库这样有很多优化与压缩，所以至少存储上你会很快遇到压力。

promethus 和 infuxdb 有很多设计上的相似，所以可以期望 infuxdb 至少在存储上也有这样大的优势。而且有大量 benchmark 都说明了综合看 infuxdb 是性能最好的了，唯一缺点就是集群要收费。

php 危险，还因为对 php 做攻击的多，我司 nginx 日志里面的攻击基本 90%的 url 都有 index.php 。php 就是这么牛逼

纯 rest，直接请求里带一个 requestId，由前端生成的 uuid。如果表(或者放 redis 或直接后端缓存下)已经出现，就直接拒绝

感觉就是人家写得💩，又懒得跟你讲(两三句话将不明白啊)。其实我们公司有部分业务也是，当时写得太烂，现在维护的同事每次改需求都感觉在掏粪，心情不好就不想和人多说话了。

lz 可能真的只能哄好，把注释流程啥的都重新搞好才好做。

@shyrock 国外没有小米华为 oppe vivo 这几大玩家，或者说大部分型号都不会（不能）在国外上市（特别是美国）。在 3000 左右这个价位一加自然好卖

一般做原型还是 python 这些写着快把，毕竟有 repl 可以事实看过程和结果，而且 python 上的各种计算密集的库底层一般都是 c，c++写的，也不会慢

@vipdog73 ceph 的话我也就是看官方文档过来的，英文吃力这里有中文文档 http://docs.ceph.org.cn/ ，虽然版本落后但差别不大。主要还是实际动手操作试坑把，然后 ceph 新版（ Mimic ？）开始 dashboard 加强了很多功能，一定要试下，可以少记好多命令。新版还有基于 k8s 与 helm 的部署方式，不过我没试过所以不好评价。

k8s 上还有挺多其他的存储解决方案，像 rock （也是基于 ceph ）还有 GlusterFS，但至今也没有完美的方案。像 ceph 主要都是用 ceph rbd，而 rbd 设备只能同时又一个设备读写，和用 docker 直接 mount 个主机路径或者 nfs 目录很不一样。如果是 io 很敏感的服务，比如数据库，这些分布式或者通过网络的存储性能上又不能满足。存储这个问题总之挺难的，还没有银弹。

@andyangyu 深有感触，我司是有个自建的 ceph，所以感觉还好。但想在 k8s 上管理数据库或者 kafka 感觉还是很不成熟，没看到有什么好的方案，k8s 自身直通主机硬盘的几个接口感觉还是有很多问题。

rancher 吧，开源的我司在用，现在机器就 10 多个，维护也很方便（主要还不要钱）