V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  abcbuzhiming  ›  全部回复第 2 页 / 共 104 页
回复总数  2061
1  2  3  4  5  6  7  8  9  10 ... 104  
@dylanqqt 虽然那位说上千人有点夸张了。但是你这十多个人维护的几十个服务,也能叫业务规模大?
老外有个暴论:当你的团队人数用一盒披萨就能喂饱的时候,你根本不需要微服务这东西。

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

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

微服务不是灵丹妙药。
95 天前
回复了 momowei 创建的主题 Go 编程语言 go 的内存优势在部分场景比想象中多
对个人来说,Go 非常好,资源占用少,能省下不少服务器费用。
对企业来说,Go 省下的服务器费用不注意抵消 Go 开发人员工资远比 Java 开发人员高,还难找的尴尬。

所以用哪种语言只取决于你自己的身份
99 天前
回复了 nyxsonsleep 创建的主题 宽带症候群 跳板机跳转问题
@nyxsonsleep
我没有指明 A 、C 分别在两个内网中?????
======
A 在甲地网络,C 在乙地网络,都没有公网 ipv4 ,这不是双方在各自的内网里,又是什么意思呢?


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

C 和 A 分别在不同的内网里,它们要先连起来,所以才说尝试打洞
100 天前
回复了 nyxsonsleep 创建的主题 宽带症候群 跳板机跳转问题
@nyxsonsleep
1. A 、B 在甲地网络,C 在乙地网络
3. A 、B 、C 没有公网 ipv4(AB 无 v6)
======
这不是你自己说的吗? A 在甲地网络,C 在乙地网络,都没有公网 ipv4 ,这不是双方在各自的内网里,又是什么意思呢?
101 天前
回复了 nyxsonsleep 创建的主题 宽带症候群 跳板机跳转问题
这个问题简化后实际就是 C 如何访问 A ,C 和 A 都在内网里,首先尝试一下能不能打洞,不能打洞的话那就只有借助 D 这个桥了。
安全问题都不是首要的,只要能通,接下来你是上 VPN 还是 SSH 都随你愿意
104 天前
回复了 kevinguoCN 创建的主题 Vue.js 后端学前端的无力感
@Dimen61 我也没什么好建议,我甚至可以说,但凡是正常思维的程序员,都无法真的搞定 CSS ,因为 CSS 它就不是编程的思维,它本质是查表,而且这个表存在排列组合,有十几种搭配。理解并熟练运用这十几种配列组合的思维模式和程序员的思维模式不搭边。我三进三出 CSS ,至今不敢说自己会 CSS 。我坦诚的说我掌握不了,所以我已经摆烂了。反正我是后端出身,CSS 就停留在能写简单 UI 就行。人和人是不同的,人得接受这辈子有些领域就是搞不定。
105 天前
回复了 Dlin 创建的主题 职场话题 程序员们,还有当初的技术热情么?
想开点哥们,我们人生能遭遇一次互联网这样的技术大爆发,已经是很不容易的事情了,至今为止人类也就 4 次技术革命。其它时间基本技术都处于接近停滞的状态。现在的情况是技术红利确实已经没有了。
112 天前
回复了 kevinguoCN 创建的主题 Vue.js 后端学前端的无力感
1-5 这些问题都不是啥问题,基本都是你搜搜资料都能解决的,本质都没有超脱传统编程的套路。

真正的麻烦 CSS 你放在最后一个了,其实这才是前端的叹息之墙。虽然这东西看起来简单,大部分人也用不了高深的特性,但是这个玩意出问题的时候,你是没有办法用传统编程思维去解决的,这才是前端真正的“房间里的大象”,不可解的问题。
114 天前
回复了 Legman 创建的主题 问与答 请教基础服务方案
@lower 每种就部署一个的话,需要搞私有云吗?那不是硬造需求?服务这玩意从来都是多了才需要运维,少根本不需要运维。
不过每种就一个,你就更要小心,每个组最好单独一个账户,隔离它们能访问到的数据,否则就会出现 a 不小心改了 b 的库这样搞笑的事情。
反正有状态服务,我是坚决反对多个组混在一起搞开发使用的,各种各样的笑话,就算老手都不一定保证不失误
114 天前
回复了 Legman 创建的主题 问与答 请教基础服务方案
你提到的服务,全部都是有状态服务,有状态服务最好的方案就是一个环境一套,但凡它有状态,运维就轻不起来。你就算私有云,照样是申请一个,就是一个实例,单独为某个环境服务。而且你还得配审核人员,更烦
@GeekGao 我手上并没有,但是老外的社区说过不止一次这个问题,想来不是空穴来风
@GeekGao 我前面说了,yaml 这个东西之所以被 k8s 广泛采用,就是因为 k8s 的工程师动不动就要些几万行的配置文件。在这种数量级下,同样的配置项,少写一个 key 就成为了收益性很高的一件事。所以 k8s 才选了这个格式作为自己的配置文件。
你自己只需要写几百行 k8s 配置,那你一个大类下面有几个子类不得了了,那自然是体会不到这玩意难读的。实际上国外社区已经不止一次抨击过 yaml 作为 k8s 的配置文件“难以阅读”了。就在于我说的,它们说的这种“难读”的 yaml ,一个大类下面子类的数量,多到可以横跨好几个屏幕高度。看着看着眼睛就花了
@GeekGao 我给了理由,不是随便轻松的讲话,人眼的特性就更适合横向扫描。况且你是不是觉得 python 和 yaml 都是有缩进,就觉得这两个玩意一样?你见过 yaml 子项的数量多到可以横跨整个屏幕高度的情况没?
@GeekGao 这上面写错了,yaml 根本就不易读,人眼的生物特性,更适合横向扫描,而不是纵向位移。这就决定来了 yaml 读起来一点都不友好。而且 yaml 之所以设计成这样就是因为 k8s 的配置代码量非常大,所以少写一个 key 的收益就特别大。yaml 是少见的专门针对写多读少环境的配置语法
@kenvix 因为 k8s 用 yaml 这东西,而 k8s 用这东西的核心原因是,k8s 工程师写配置文件的量非常大,几万行的配置文件和家常便饭一样。典型的写多读少。对于他们来说,节省几个字符串带来的收益海了去了,所以 yaml 才是这个样子。
但是对但部分其它人来讲,配置文件永远是读多写少。yaml 这种读起来一泡污的语法就一点都不友好了
130 天前
回复了 Drinkinghook 创建的主题 问与答 QQ 对发送图片进行了内容识别
你们大惊小怪的今天才知道吗?微信也有。而且微信更夸张,觉得你发的东西不对的话,那就只有你自己能看见,其它人看不见的
134 天前
回复了 Gannicus5 创建的主题 问与答 windows 服务器如何管控用户级别网络权限
现成的工具应该没有,域控制器只能分批设置目标电脑的防火墙,但是不能根据用户名来定义
1  2  3  4  5  6  7  8  9  10 ... 104  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1130 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 36ms · UTC 18:33 · PVG 02:33 · LAX 10:33 · JFK 13:33
Developed with CodeLauncher
♥ Do have faith in what you're doing.