这是一个创建于 122 天前的主题，其中的信息可能已经有所发展或是发生改变。
工作的时候一直喜欢尽量把架构设计的简单，能不能做的复杂功能就不做
比如之前产品要我们做个后台录制客户给的直播视频链接，产品有个问题就是如果不同客户提交了同一个链接，是不是我们后台会重复录制？
我觉得用重复录制的设计会比较好，因为我原本设计的录制机，是一个链接就会单独起一个 deployment ，也不会检查是否有重复的链接；其二重复录制也不会占用多大资源，链接大概率是我们内网的直播，不占用带宽，录下的东西存对象存储里一天也就几毛几分钱。
不过这样的设计大概争对的也就是二位数以内客户，最多三位数的录制链接了，我觉得在这个量级下面，完全完全没有必要设计复杂的去重逻辑，根据链接去重？那每个链接都要存到数据库里计数，计到 0 才能删除录制服务，万一客户提交的链接后面有乱七八糟的参数？是去参数拿原始链接去重，还是直接带上参数存数据库里？
以前有另一个同事就是这样的设计，我觉得真的是非常、非常的负责，首先他的 worker 服务启动的时候会去查数据库，查有哪些链接还没有分配到 worker ，如果有的就把自己的 workerid 更新进去，然后自己作为 worker 开始录制，这样每次要查有哪些视频没有录制还有去翻数据库，不甚其烦。一个 deployment 一个录制，在 deployment 列表里直接就能看到所有正在录制的信息，不需要拿个直接把 replica 改成 0 ，不是很方便吗。
我觉得这个量级下面很多架构完全完全没有必要设计的那么复杂，我的思路有错吗？
20 条回复 • 2024-08-05 08:47:40 +08:00
 |
1
Songxwn 122 天前
的确，网络这边在设计底层架构的时候，越简单越好，方便维护。
|
 |
2
retrocode 122 天前 via iPhone
越简单越好，最烦的就是这里以后会怎么样哪里以后会怎么样，嘎嘎一堆预留代码预留接口，结果根本没有用。先以最简模型开发完成，剩下后面慢慢迭代，遇到了再说。
|
 |
3
Perry 122 天前 via iPhone
你直接把两个方案的研发时间，资源花费，各种优缺点对比下给整个组讨论下不就完了
|
 |
4
zzly263 122 天前 via Android
满足需要，最简单的。客户量不大，没必要
|
 |
5
povsister 122 天前
简单不等于把后路堵死，软件解决方案最好是可迭代的。
你表述的应该是：是否要为了尽善尽美的解决问题，而把系统复杂度拉的太高 这个老生常谈的问题了，自己拿 占用资源 - 工时 - 可扩展性 去权衡吧。每个项目都有每个项目的要求。 |
 |
6
WhateverYouLike 122 天前
同意你的想法。倒不是说去重实现的难度特别大，而是因为架构清晰是最大的优点。当有明显的成本节省时，才需要加中间一层。
另外在实现上即便要去重，去重逻辑跟底层的一对一录制逻辑都是尽量分开的，不要揉在一起。 |
 |
7
jones2000 122 天前
设计的时候需要考虑，预留去重接口，前期可以不用， 后期如果有需求可以加上。
|
 |
8
FYFX 122 天前
|
 |
9
zealic 122 天前  1
每座屎山一开始的时候也都是一个有手纸有遮阳的茅坑。
但是拉稀的时候，你可不管有没有对准坑位，更不会记得你手纸昨天刚用完。 拉到一半的时候，外面聚集了一群人：有来收拉屎税的，有憋着等抢坑位的，有来卖手纸的，还有一个老八两眼冒光。 最后厕长跑出来宣布，在场的所有人今天都必须拉满 3 斤才能离开。 “谁赞成？谁反对？” |
 |
10
louisxxx 121 天前 via iPhone
简单不是叫你乱拉屎，简单是在满足业务需求和稳定可靠的前提下的简单；什么是过度设计？明明用户数就 10 个你按 10 万用户来设计系统；你按 100 来设计可以算冗余，你按 10 万来设计存粹吃饱了撑的。程序也是一步一个脚印循序渐进的送代
|
 |
11
TimG 121 天前 via Android
稳定性/性能 - 扩展性 - 工作量 三者不可兼得。未来的需求不可预测，在这个前提下看项目组如何选择也算是一种项目设计的美学。
|
 |
12
wzy44944 121 天前
简单的好处就是清晰易维护，要是复杂点也能做到同样的清晰易维护其实是可以接受的，感觉你同事的方案也没多复杂，能降低成本的话还是挺好的。一个 deployment 一个录制的好处是用户功能的隔离更好一些，不容易出现串台之类的问题。复杂架构往往在出现故障后才会有机会简化。
|
 |
13
winglight2016 121 天前
这从来不仅仅是个技术问题，不懂技术的同事会有不同的目标，技术同事也有自己的需求等待满足。
比如，我这里有测试的同事拼命想表现自己，我不知道他是不是想争取加薪，动不动就说性能无法满足，其实测试环境里压出来的结果，生产并不一定有同样问题。 又比如，产品、测试、运维同事都担心旺季会导致系统无法承受，其实我们的架构再翻个几倍的量都没影响，大不了加 pod 数量。 最后，技术同事需要在公司项目上应用更新、更复杂的技术，方便找下一份工作有亮点。 以上。 |
 |
14
ZZ74 121 天前
技术上是对的，工作上是错的
|
 |
15
janus77 121 天前
按最佳实践来，既不会因为过于复杂而维护困难，也不会因为过于简单而后期加功能的时候代价很大。正如上面说的，复杂度是有一个平衡点的，这个平衡点一般就是最佳实践。
|
 |
16
opengps 121 天前
当然不对，不适合团队，你一人干了 4-5 人的活
|
 |
17
oddboy 121 天前
你肯定没错，产品的要求也没错，开发和产品人员本来就是站在两个视角看问题的，所以需要从中间做取舍和权衡。个人感觉可以先提出自己的想法，那 ROI 去 argue 设计方案的实施，简单实现一个 MVP ，先跑起来。然后做好分层设计，后面看数量级和产品的迭代，再加一层处理数据的去重和其他 worker 逻辑即可，既要表示对对方想法的认可，也要表达出自己一个人短期实现的难度，还要表示后续自己可以很快的通过技术实现支持，我想产品也不会特别和你难看的。沟通也是技巧，希望对你有帮助。
|
 |
18
james122333 121 天前 via Android
在保证基本灵活性的前提下 是
否则等同没架构 |
 |
19
LitterGopher 121 天前 1
这就看你怎么看待这个问题了，如果你为这个项目好那当然是在保留灵活性和鲁棒性的前提下约简单越好，如果你是为了 自己好（找下家简历好看），那就别问好不好，只问能不能。别说百万 QPS 好多系统 一万 QOS 都达不到，还不是一大堆为了炫技而使用的技术。
不到 100 个接口？没关系，上个微服务吧。 不到 50 万的数据量？没关系，分库分表主从备份搞起来。 不到 10 万的 月访问量，没关系，Redis ，Kafka 全部加上去。 虽然只是一个后台管理系统，没关系，ChatGPT 接入进来。 |
 |
20
uds9u32br 120 天前
正确的，搞一大堆这样 service 那样 service ，这样接口那样接口，起码 80%在未来都是不会有任何扩展的，反而会对看代码的人造成巨大的心智负担。
|
Select Language