- 主题:[转载]为什么现代软件让我悲伤
因为你本来的配置模型是对象的，非要拍扁成kv对
【 在 vmx 的大作中提到: 】
: 大哥，就是像ini这么简单直白原始的格式也支持注释需要注释啊
--
FROM 27.91.71.*
我们公司一些核心配置存储系统之前是部署在etcd2上的，后来新增的一个配置平台迁移到了etcd3。但是etcd3的客户端逻辑实在太恶心，于是又搞了一套agent，能把存储在etcd3上的配置用etcd2的接口读取。。
【 在 hgoldfish 的大作中提到: 】
: etcd 是一个使用 raft 一致算法的 KV 数据库，产生于 2013 年。最早是为 CoreOS 开发的，但本文不关心这个烂货，它已经完蛋了。本文的主角，它的副产物 etcd 使用更广泛。etcd 提供了简洁的 HTTP API, 多年以来，我已经使用 etcd 开发了多个工具。
: 2015 年的时候，又诞生了另外一个与之没有关系的 Kubernetes 项目，很多人称它为 k8s. 在我看来，这是继 systemd 之后系统管理领域的最大灾难。它号称要简化集群管理，为大众带来 Google borg 集群管理软件的体验。但实际上：
: 1. 为你的软件添加了几百种出错的模式。
: ...................
--
FROM 120.52.147.*
改变的不是写代码方式，而是开发管理方式。传统开发和敏捷在开发阶段参与者角色是项目经理、产品人员、设计人员、开发人员。而devops主张的是全员开发，将本来位于上线阶段的运维人员前置，从项目规划阶段就参与开发。
开发管理方理念的改变，带来的是全流程的变化，写代码的方式其实没有改变，而是因为流程的变化，导致以前开发结束才考虑的环境配置放到了前边。至于server到service mesh跟云原生没有必然联系，实际上在分布式rpc开始就已经在向这个方向发展了，接着演化出服务化，一直到近些年的微服务。
而容器化是由微服务带来的需求，服务功能单一化之后，单独的物理机或者虚拟机，运行一个单一功能的服务显然是资源的巨大浪费，于是基于相同环境的新资源组织形式才有了实际的需求。
所以，显示dry原则的落地，然后是服务的单一化，之后才是容器化。不要云原生这个结果当成了原因
【 在 ilovecpp 的大作中提到: 】
: k8s生态主张以新方式（“云原生”）写代码，例如，把网络配置，服务发现等全部从server移到service mesh，server只和sidekick通讯。这显然是要改变开发写代码的方式的。
--
FROM 114.249.193.*
这个。。。学习路线是：前后端分离的开发方式->微服务->容器化
当你有几百甚至几千个微服务，运行了成千上万的容器，分布在几百台物理机上。
不管是项目leader还是运维人员，你是要亲自写脚本上，还是用k8s把容器和物理机管理起来？
【 在 ztysys 的大作中提到: 】
: k8s到底是个啥？没用过哈
: 是打包软件，就像zip那样把一堆东西压缩打包在解压？
: 还是专门做管理，在哪儿哪儿再部署一套系统？
: ...................
--
FROM 114.249.193.*
这个时代运维也分为运维开发人员和普通运维，运维开发实际上是开启了运维的一个新的上升渠道。
传统的运维受限于工作内容，只能在初、中、高、专家级的运维体系内晋升，再向上就是跨体系的体系架构师，能实现职业跨越的毕竟是少数
而到了运维开发序列，工作内容从脚本和数据收集转化为对运维系统的开发，晋升序列也并入开发人员级别，毕竟运维开发也是开发，只不过专注的方向不同。
不过对于普通运维，还是普通运维，人各有志，这个不能勉强，所以不影响传统运维恰饭，只不过未来运维的需求量会增加，而传统运维的需求会逐渐变少
【 在 xiaoju 的大作中提到: 】
: 运维不一定喜欢k8s，他们更喜欢云平台原生的方案，直接点几下鼠标什么都搞定
: k8s和docker一样是devops理念发展带来的产物
:
--
FROM 114.249.193.*
这不是都不会忘的吗？我用gson，碰到“key” :{}转成dto对象的string字段都会报错而不是转成null的
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 易写可不对。。每个 key 都要加双引号，不然会报错的。
:
: 【 在 No1 () No1 () 的大作中提到: 】
: : json做配置、传数据都很好
--
FROM 124.202.217.*
properties呢？要是原生支持unicode而不是iso8859就好了
【 在 vonNeumann (劣币驱逐良币 | 少灌水) 的大作中提到: 】
: 配置文件的话，我宁愿用 xml 都不用 json
:
: 不支持注释
: key 必须用双引号，不支持单引号或无引号
--
FROM 124.202.217.*
不是所有程序员都是js程序员吧
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 名字都带 code 了，显然没有程序员之外的用户会用。
:
: 【 在 No1 () No1 () 的大作中提到: 】
: : 因为vscode虽然是用js（ts）写的，但配置文件主要是面向用户，用户可不全是js程序员，
--
FROM 124.202.217.*
yaml更合适
【 在 vonNeumann 的大作中提到: 】
: 配置文件的话，我宁愿用 xml 都不用 json
: 不支持注释
: key 必须用双引号，不支持单引号或无引号
: ...................
--
FROM 115.34.178.*
实事求是说 etcd v2 的 HTTP API 简单好用
而且支持各种语言
v3 的 gRPC 不支持 C
当初我们产品我开发 C 库
为了实现 C 支持，花费了不少精力
但是，二进制协议的 gRPC 的确性能比过去的 HTTP API 好不少
【 在 hgoldfish 的大作中提到: 】
: etcd 是一个使用 raft 一致算法的 KV 数据库，产生于 2013 年。最早是为 CoreOS 开发的，但本文不关心这个烂货，它已经完蛋了。本文的主角，它的副产物 etcd 使用更广泛。etcd 提供了简洁的 HTTP API, 多年以来，我已经使用 etcd 开发了多个工具。
: 2015 年的时候，又诞生了另外一个与之没有关系的 Kubernetes 项目，很多人称它为 k8s. 在我看来，这是继 systemd 之后系统管理领域的最大灾难。它号称要简化集群管理，为大众带来 Google borg 集群管理软件的体验。但实际上：
: 1. 为你的软件添加了几百种出错的模式。
: ...................
--
FROM 117.35.111.*