首页   注册   登录

ibegyourpardon

V2EX 第 158321 号会员,加入于 2016-02-07 20:12:56 +08:00
今日活跃度排名 15158
听说有人证明了黎曼猜想……
数学  •  ibegyourpardon  •  85 天前  •  最后回复来自 frylkrttj
8
对大量前端代码的版本化管理,有啥好思路不
问与答  •  ibegyourpardon  •  2018-02-26 16:42:13 PM  •  最后回复来自 doublleft
3
好多人喜欢用 iV2EX 的梗
V2EX  •  ibegyourpardon  •  2017-08-07 18:07:49 PM  •  最后回复来自 66beta
4
最近的 ofo 感觉变的少多了……
互联网  •  ibegyourpardon  •  2017-05-05 09:19:23 AM  •  最后回复来自 BearD01001
51
同事即将离开长沙去深圳,给做个推荐, PHP
职场话题  •  ibegyourpardon  •  2017-03-30 15:36:10 PM  •  最后回复来自 vingc723
6
才发现这个节点,这其实不就是个临时的 gist 么……
问与答  •  ibegyourpardon  •  2017-03-22 17:01:33 PM  •  最后回复来自 ibegyourpardon
1
ibegyourpardon 最近回复了
3 天前
回复了 kakalulin 创建的主题 问与答 你给自己定了哪些 30 岁前要做的事情?
我一个 30 多岁的人为什么要点进这个帖子。。
5 天前
回复了 hahahe 创建的主题 程序员 搞不懂现在的电商广告有什么意义……
有同样困扰的不止我一个。。。
至少我听说在玩 FPS 游戏的时候,120Hz 是能够让人更精准的捕捉高速移动物体的。
46 天前
回复了 yangyifan 创建的主题 问与答 关于 Nginx 和 PHP -fpm 通讯的选择
我记得还是有差别的。。需不需要走网卡。。。
46 天前
回复了 zhangpeter 创建的主题 问与答 网页如何做到禁止 F12 和右键的?
没啥好嘲笑的,小白这东西,拦一个是一个。

小白如果自己愿意上网查找答案,发现原来可以轻松破解,那也是好事,那意味着小白也多少学到了一点点新东西。

所以其实拦的不是小白,是某种意义上的伸手党,F12 一按就想抄。同样都是小白,能自己找寻破解方法和不愿意找的还是不一样的。
52 天前
回复了 huangdayu 创建的主题 程序员 你的编程启蒙老师是谁?
aveline
52 天前
回复了 hugee 创建的主题 PHP PHP 高并发 统计网页点击次数
朋友,我觉得真的高并发的话,可能你的问题首先不是出在 MySQL 上,而是 php-fpm 上……

当然我不知道你怎么部署的,如果真的若干机器堆住,一般 hold 住也没问题,当然真是这样的话那 Redis 啥的也不算事了。

毕竟不知道你的高并发首先有多高 - -#
60 天前
回复了 iacyl 创建的主题 全球工单系统 豆瓣又又又挂了?
切 CDN 是因为被 D 了么。。。
买,不要犹豫。
家里又不是没有这个条件。
67 天前
回复了 chaleaochexist 创建的主题 程序员 请教,rest api 的设计问题,关于粒度.
@guijianshi01 哈哈哈,理解理解,我就这么过来的。我的做法不敢说是完美,也是一个一个坑才过来的血泪史。

最核心的,我称为核心功能接口,我是尽最大可能划分到最细的粒度,比如一个 auth,这类接口我设计的时候原则上是不直接暴露给前端调用的,因为直接暴露意味着给前端需要请求太多的内容,无论性能还是开发流程上都不可接受,前后端会打架的。

但这类接口也不绝对,某些高频,无法也无需改动的,比如授权,这种模式下我会适当直接传给前端。

然后核心功能接口写出来其实是为了给后端调用的,用来做各种业务接口组合。这里面也是血泪史,差点和后端打疯,后端说我几个 import 的事你非要我调网络请求的形式来(我们目前的能力只能以 RESTful API 的形式互相调用),包括业务接口不一次写完,而是写完再组合… 但最后后端发现,在不同的项目中,熬过前期后,往往重新组合包装一个接口提供给前端,会变的异常轻松。

当然这里也有 API 网关这个我 18 年年初才学到的概念的支援。包括我上面讲的模式里,其实在包装组合接口提供给业务用这件事上,前端突然发现他们也有能力直接调用以及做组合了,所以业务上其实突然变的相对好一些了。

但一个系统的总体复杂度是不变的,对应的,压力放到了我这边,我自己做的这个设计和决策,现在我要为统筹管理和理清这么多接口、模式进行负责,这个压力也大。可总比和大家一起开会分析那绕来绕去的业务逻辑还是要轻松一些的。

所以我写了这么多,其实也没有直接回答你的问题。全部写一起肯定是弊大于利,畏手畏脚,甚至逼不得已要重新写一个新的大的单体出来。拆开的不合理的话,又会东改西改,并且接口功能重复,模糊,界限不清。

但就我自己的经验而言,还是要拆,拆的时候优先提炼出核心的不变的东西,尽可能在少增加额外开发的情况下将接口复用组合提供出业务接口来。而且业务接口尽量不要由核心系统直接提供,一定要有个 API gateway 层,让这个层来承担接口的分发工作。 我们用的也不好,业务中有大量冗余接口,也有很多沉没的存在安全隐患的东西,这个以后早晚要慢慢解决。但小公司,四五个人的团队,只能先到这样了。
关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   946 人在线   最高记录 5043   ·  
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.3 · 20ms · UTC 22:15 · PVG 06:15 · LAX 15:15 · JFK 18:15
♥ Do have faith in what you're doing.
沪ICP备16043287号-1