V2EX › abcbuzhiming 的所有回复 › 第 2 页 / 共 104 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 2 3 4 5 6 7 8 9 10 ... 104

❮

❯

130 天前

回复了 1311317 创建的主题 › 问与答 › 家人痴迷于酿酒想着以后能大卖怎么劝

你这酒但凡有一次失误，混进点杂醇进去，把人喝伤喝死，就准备坐牢吧，这可是有现实案例的，自酿酒最大的问题就是控制不了质量

131 天前

回复了 drymonfidelia 创建的主题 › 程序员 › 微服务到底在哪个方面让开发、维护简单了？怎么看都是变复杂了，原本配置一次数据库就能跑，现在要配置八九个容器和数据库，更新一次要配置好几个服务

@dylanqqt 朋友，十个人纯后端的项目真不能算大的，国外推荐开始考虑微服务的时间点，基本都是你已经有几十个不同功能开发小组的时候，而不是十几个人的时候。
当然，你这个时间点可以开始考虑转微服务，只是我觉得此时收益和付出的代价比还是不够。

微服务其实是一个“在到了一定条件下不得不选”的选择，而不是一个“更好的”选择。我觉得所有人在决定上微服务前，都得想清楚这个区别

131 天前

@dylanqqt 虽然那位说上千人有点夸张了。但是你这十多个人维护的几十个服务，也能叫业务规模大？

131 天前

老外有个暴论：当你的团队人数用一盒披萨就能喂饱的时候，你根本不需要微服务这东西。

微服务一定要系统足够庞大，庞大到不拆分几乎无法维护的时候，才会有意义——相对微服务带来的那些问题：运维麻烦，各数据分散在不同的存储中，报表困难。

另外和大家想的不一样的是，不要觉得微服务上了，就真能各团队独立，这其实是个幻觉，现实是大概率你把你的服务改了，一个依赖你的服务挂了，这才是普遍现象。

微服务不是灵丹妙药。

136 天前

回复了 momowei 创建的主题 › Go 编程语言 › go 的内存优势在部分场景比想象中多

对个人来说，Go 非常好，资源占用少，能省下不少服务器费用。
对企业来说，Go 省下的服务器费用不注意抵消 Go 开发人员工资远比 Java 开发人员高，还难找的尴尬。

所以用哪种语言只取决于你自己的身份

140 天前

回复了 nyxsonsleep 创建的主题 › 宽带症候群 › 跳板机跳转问题

@nyxsonsleep
我没有指明 A 、C 分别在两个内网中？？？？？
======
A 在甲地网络，C 在乙地网络，都没有公网 ipv4 ，这不是双方在各自的内网里，又是什么意思呢？

“另外我已经明确说明“B 只允许 A 访问。”，为什么这种情况下能打洞？”

C 和 A 分别在不同的内网里，它们要先连起来，所以才说尝试打洞

140 天前

回复了 nyxsonsleep 创建的主题 › 宽带症候群 › 跳板机跳转问题

@nyxsonsleep
1. A 、B 在甲地网络，C 在乙地网络
3. A 、B 、C 没有公网 ipv4(AB 无 v6)
======
这不是你自己说的吗？ A 在甲地网络，C 在乙地网络，都没有公网 ipv4 ，这不是双方在各自的内网里，又是什么意思呢？

141 天前

回复了 nyxsonsleep 创建的主题 › 宽带症候群 › 跳板机跳转问题

这个问题简化后实际就是 C 如何访问 A ，C 和 A 都在内网里，首先尝试一下能不能打洞，不能打洞的话那就只有借助 D 这个桥了。
安全问题都不是首要的，只要能通，接下来你是上 VPN 还是 SSH 都随你愿意

144 天前

回复了 kevinguoCN 创建的主题 › Vue.js › 后端学前端的无力感

@Dimen61 我也没什么好建议，我甚至可以说，但凡是正常思维的程序员，都无法真的搞定 CSS ，因为 CSS 它就不是编程的思维，它本质是查表，而且这个表存在排列组合，有十几种搭配。理解并熟练运用这十几种配列组合的思维模式和程序员的思维模式不搭边。我三进三出 CSS ，至今不敢说自己会 CSS 。我坦诚的说我掌握不了，所以我已经摆烂了。反正我是后端出身，CSS 就停留在能写简单 UI 就行。人和人是不同的，人得接受这辈子有些领域就是搞不定。

145 天前

回复了 Dlin 创建的主题 › 职场话题 › 程序员们，还有当初的技术热情么？

想开点哥们，我们人生能遭遇一次互联网这样的技术大爆发，已经是很不容易的事情了，至今为止人类也就 4 次技术革命。其它时间基本技术都处于接近停滞的状态。现在的情况是技术红利确实已经没有了。

152 天前

回复了 kevinguoCN 创建的主题 › Vue.js › 后端学前端的无力感

1-5 这些问题都不是啥问题，基本都是你搜搜资料都能解决的，本质都没有超脱传统编程的套路。

真正的麻烦 CSS 你放在最后一个了，其实这才是前端的叹息之墙。虽然这东西看起来简单，大部分人也用不了高深的特性，但是这个玩意出问题的时候，你是没有办法用传统编程思维去解决的，这才是前端真正的“房间里的大象”，不可解的问题。

155 天前

回复了 Legman 创建的主题 › 问与答 › 请教基础服务方案

@lower 每种就部署一个的话，需要搞私有云吗？那不是硬造需求？服务这玩意从来都是多了才需要运维，少根本不需要运维。
不过每种就一个，你就更要小心，每个组最好单独一个账户，隔离它们能访问到的数据，否则就会出现 a 不小心改了 b 的库这样搞笑的事情。
反正有状态服务，我是坚决反对多个组混在一起搞开发使用的，各种各样的笑话，就算老手都不一定保证不失误

155 天前

回复了 Legman 创建的主题 › 问与答 › 请教基础服务方案

你提到的服务，全部都是有状态服务，有状态服务最好的方案就是一个环境一套，但凡它有状态，运维就轻不起来。你就算私有云，照样是申请一个，就是一个实例，单独为某个环境服务。而且你还得配审核人员，更烦

167 天前

回复了 chesha1 创建的主题 › 程序员 › 一个服务的配置文件用什么格式（比如 xml, json, yaml）比较好？

@GeekGao 我手上并没有，但是老外的社区说过不止一次这个问题，想来不是空穴来风

167 天前

回复了 chesha1 创建的主题 › 程序员 › 一个服务的配置文件用什么格式（比如 xml, json, yaml）比较好？

@GeekGao 我前面说了，yaml 这个东西之所以被 k8s 广泛采用，就是因为 k8s 的工程师动不动就要些几万行的配置文件。在这种数量级下，同样的配置项，少写一个 key 就成为了收益性很高的一件事。所以 k8s 才选了这个格式作为自己的配置文件。
你自己只需要写几百行 k8s 配置，那你一个大类下面有几个子类不得了了，那自然是体会不到这玩意难读的。实际上国外社区已经不止一次抨击过 yaml 作为 k8s 的配置文件“难以阅读”了。就在于我说的，它们说的这种“难读”的 yaml ，一个大类下面子类的数量，多到可以横跨好几个屏幕高度。看着看着眼睛就花了

167 天前

回复了 chesha1 创建的主题 › 程序员 › 一个服务的配置文件用什么格式（比如 xml, json, yaml）比较好？

@GeekGao 我给了理由，不是随便轻松的讲话，人眼的特性就更适合横向扫描。况且你是不是觉得 python 和 yaml 都是有缩进，就觉得这两个玩意一样？你见过 yaml 子项的数量多到可以横跨整个屏幕高度的情况没？

168 天前

回复了 chesha1 创建的主题 › 程序员 › 一个服务的配置文件用什么格式（比如 xml, json, yaml）比较好？

@GeekGao 这上面写错了，yaml 根本就不易读，人眼的生物特性，更适合横向扫描，而不是纵向位移。这就决定来了 yaml 读起来一点都不友好。而且 yaml 之所以设计成这样就是因为 k8s 的配置代码量非常大，所以少写一个 key 的收益就特别大。yaml 是少见的专门针对写多读少环境的配置语法

168 天前

回复了 chesha1 创建的主题 › 程序员 › 一个服务的配置文件用什么格式（比如 xml, json, yaml）比较好？

@kenvix 因为 k8s 用 yaml 这东西，而 k8s 用这东西的核心原因是，k8s 工程师写配置文件的量非常大，几万行的配置文件和家常便饭一样。典型的写多读少。对于他们来说，节省几个字符串带来的收益海了去了，所以 yaml 才是这个样子。
但是对但部分其它人来讲，配置文件永远是读多写少。yaml 这种读起来一泡污的语法就一点都不友好了

1 2 3 4 5 6 7 8 9 10 ... 104

❮

❯