V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  xuanbg  ›  全部回复第 3 页 / 共 318 页
回复总数  6349
1  2  3  4  5  6  7  8  9  10 ... 318  
31 天前
回复了 Lyn321 创建的主题 生活 退税又开始了~
@popvlovs 你这话真的气人
31 天前
回复了 rayaa 创建的主题 汽车 买车决赛圈,帮忙说说建议
你这预算不选国产???
33 天前
回复了 axuahui 创建的主题 职场话题 警惕 AI 对我们的影响,
说句不好听的,你警不警惕的,能改变你的行为还是能改变结果?不能的话,就别矫情了。
用 1 年收入买个玩具还是很奢侈的
35 天前
回复了 xiaohupro 创建的主题 Redis Redis Stream 实现 MQ 的可行性
@likeme 对的,定时任务扫一把数据库最简单了。唯一的条件就是:只要扫得过来就行。
你一边接口的参数/返回数据的结构变了,用什么 rpc 协议都不能让你不用改调用者的逻辑就能实现同步啊。
可以是可以,但不能保证修复结果就是正确的。有可能你跑几天都跑不出正确的结果来。
不能把 AI 无缝链接到业务流程中的话,一窝蜂上 AI 的意义在哪里呢?
你这个不叫 go 基础,就是个编程基础。
首先,出现 10 个服务调用情况基本就是设计的问题。代码写错地方真的比写错了代码还糟糕。
然后,问题已经出现了,那该怎么办呢?简单,给一个 V2 版本就行了。需要新的改用 V2 版本,不需要的继续用 V1 ,就不需要动他了。
@mengdu
@thinkm 问题是:能跑的不用跑,不能跑的他没地方跑啊。
40 天前
回复了 yaozhao 创建的主题 NAS 天塌了, NAS 被勒索了,如何数据恢复?
放弃吧,直接重来是唯一正确的选择
41 天前
回复了 Joker123456789 创建的主题 Java 微服务是不是一种错误的方向?
OP 你说的 4 个缺点,只有 2 是微服务的问题。但多个注册中心算什么问题?你还需要多个网关、多个链路追踪组件呢。多出这些就增加系统复杂度了?不,对于开发来说,一点复杂度都没增加。因为这些基础设施不需要你去维护,你只管用一行代码调用就行了。

至于其他 3 个问题,都是人的问题而非微服务的问题。算了,我还是老观点:不会封装和不会自动化运维的,老老实实玩单体就好。微服务肯定要比单体先进,自己没这个本事玩微服务就别玩,不要把锅甩给微服务。
不返回文件的 url ?直接返回文件流?
44 天前
回复了 cssTheGreatest 创建的主题 旅行 大家好,三月底去云南,想咨询一下
洱海的东南侧有环海公路。但西侧是无法骑车或开车靠近洱海的,只能在龙龛、才村、下鸡邑等村子进入生态廊道,然后租电动车或自行车。
医生就是一个字:熬

熬个 20 年,熬成主任就出头了
@Whiplash55 我无法直接回答你的问题。

我认为微服务解决的是系统复杂度过高的问题。说到底,微服务就是一种对逻辑的封装模式而已。通过合理拆分服务,在服务层面实现高内聚低耦合、且正交的业务逻辑的封装。

当然,整体的复杂度并不因为服务拆分而降低。但很大一部分复杂度可以从开发转移到运维。所以,要玩微服务,先得有自动化运维的能力,不然肯定搞不定。
@Mrun 你们这个办法更好
@lscho 我们正常几乎没有本地 debug 的情况,有什么问题看日志就解决了。除非是日志中看不出来错误的原因,才会进 debug 模式跟跟看数据是不是正常。
1  2  3  4  5  6  7  8  9  10 ... 318  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2371 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 69ms · UTC 07:26 · PVG 15:26 · LAX 00:26 · JFK 03:26
Developed with CodeLauncher
♥ Do have faith in what you're doing.