工程师硬通货系列六:系统知识,纵横捭阖

职场硬通货系列》首发于公众号“职场嘚吧嘚”,每周三更新,欢迎大家关注转发!

明明很努力,却没有什么成绩?知道自己要学的很多,但不知从何入手?对于普通人来讲,决定个人职场高度的是自己的优势上限,那么如何利用好自己的时间,去学习知识和技能来提高自己的优势上限,就是大部分人最大的难题!职场硬通货来帮你寻找答案!职场硬通货系列旨在帮助在职的工程师们明确行业边界,了解自己应该学习哪些技能,如何掌握这些技能;不断提升核心竞争力,让职业发展的道路越走越宽,从而成就更好的自己!


上一篇提到,架构工作不止要写出让人易懂易维护的代码,还要有完整易用的周边。其实,架构师的终极目标无非就两点:用户的体验尽量好,使用的成本尽量低。

体验好自不必说,用户界面易懂,操作反应流畅。成本低需要细化说明下,这里既是人力成本(需要几多个人,多少高级工程师),又是机器成本(需要多少机器,多少高配机器)。从工作内容上,一个架构师要做的无非两件事:架构优化(迭代&运维成本低)、性能优化(运行成本低)—— 多快好省。那么答案也就来了,为什么要高薪聘用你?你的 200万年薪,可以给公司优化掉几千万的机器。

那么怎么去省呢?这需要一个宏大的全局观,宽广的知识面,以纵横捭阖……


先从一个最简单的思路说起,同样一台机器怎么服务更多的请求。从单机抗 100 个请求,到抗 120 个请求,在大业务下,这就是一个巨大的资源收益。如果一个业务逻辑是健康的,单机随着 qps 的升高,cpu 会线性增加。我们一直加压,最终肯定会有一个非线性的临界点。

如果 cpu 到了某个点,压不上去了。这里很大概率是调度的问题:线程池不够大?锁?IO 卡住了(尤其是 log/databus 等,因为这些有可能是串行 or batch 串行,这种很容易导致性能无法线性)?

如果 cpu 到了某个点无法线性增加,或者接口的 latency 显著增加。需要区分对待,如果临界点 cpu 使用大于了 70%,应该与超线程有关。如果不到 70%,大概率是程序逻辑中有长尾节点,cpu 算不过来了。(如果是云机器还可能跟云厂家超卖有关,具体到现实需要很多着手点)


优化长尾节点,同时可以降低延迟,减少单个 request 占用的 cpu 时间,进一步增大吞吐。

首先,找到长尾。这其实类似于一次体检,扫描下身体看下问题在哪。比如 perf 等动态工具,类似于 B 超,在对你的身体运行基本没有任何影响的情况下,扫一遍你的全身状态。当然,还有一些静态的思路,比如增加 log、metrics,将运行状态可视化。但后者需要对业务有一定的理解,针对性的加一些信息,而且大概率需要反复增删监控以定位问题。、

然后,定位了问题就要想方案。比如,更轻的调度,类似于 golang/dag 等协程化,以及更轻量级的协程调度。比如,更好的内存管理 ,对象池、jemalloc等。比如,无锁优化。比如,可不可以 cache:即包括把 rpc 的数据 cache 住,减少重复请求;还包括把 cpu 计算的结果 cache 住,减少重复计算。

重点,还要考虑能不能优化机制。比如,可不可以离线化,有些计算的逻辑可不可以放到离线去算好,用户请求的时候用现成的。比如,能不能用更合理的硬件、体系(高吞吐的网卡、RDMA、NAPI、异步 IO、NUMA 绑定)……


不要固守地优化自己的一亩三分地,否则收益越发有限。引入旁路组件,把压力迁移出去。离线把数据算好,比如 flink/spark。而这些离线的计算又可以用稍微廉价、定制化的资源。


那么,数据怎么从线上传下来,传下之后怎么计算?

这里涉及到大量的数据传输、数据加载,而这些绝对不能引起性能的颠簸。比如,我们考虑更好的上行传输,异步 log、databus、RDMA。拿到数据,使用类似于 hadoop/spark/flink 等离线系统:批式思路集中计算最大限度减少重复计算,流式计算以尽量实时的拿到计算结果反馈给线上。

那么我们就至少需要了解,可以采用哪些组件 & 系统,进一步,组件 (如 kafka、spark、flink) 的运行机理,如何调优。


下一步,算好怎么存,存起来怎么用?

存与用是联系在一起的,一般都会为定制化存储,为了用而存。我们可以把数据直接上传到线上机器,使用时无需跨网络,也没了有额外的 DB 成本。比如,定期将数据分发给线上机器、P2P 传输…… 另一个角度,也可以直接把数据存入 DB。

无论放在哪,一定要好用,好用就涉及到数据索引。我们可以把数据导入 ES,也可以自己定制索引,甚至可以直接用 sql 数据库。小业务下 sql 足以承担,好用,数据全结构化。大的业务量级下,势必需要用 kv 类的数据库,减少数据库计算压力,运算迁移到应用层 or 直接存储计算结果(比如 xx 的好友列表,sql 类数据库可以能 xx 与 yy 是好友)。在更加复杂的业务逻辑下,可能就需要引入图数据库 (xx 好友的好友列表);而图的引入又势必涉及到大量图关系运算,这是一个比 sql 还要重的逻辑(需要更强的定制化存储) —— 慎用。

常见可选方案:mysql 的关系计算 + innodb 的kv 存储,redis 的 简单的关系数据结构 + kv 存储,rocksdb 等开源的 kv 存储引擎。

更深一层的思考,怎么既快与省兼容?选择适当的硬件,hdd->ssd->NVDIMM->Memory;选择更好的索引,树族(b+ 树、LSM树)、字典族( hashMap、字典树)


谈到存储不能不提安全。多副本、容灾快照;多副本如何一致?强一致、弱一致、最终一致。完备的应对预案:slave 挂了直接切走,master 挂了用 slave 补救(哪个 slave?) 全挂了容灾快照恢复。预案的定期预演。


走近存储,走近 databus,走近 spark/flink…… 它们又是一系列的软件架构,这些架构又涉及到了常规优化:网络传输、内存管理、资源调度、逻辑优化……


技术是无穷尽的,纵横捭阖,乐此者可不疲…… 努力再向前几步,虽然走到最前面必是天才,但你可以走到 99% 的人前面……


下一期 

工程师硬通货系列七:打开视野,拥抱世界!

全部评论

相关推荐

点赞 评论 收藏
分享
kyw_:接好运
点赞 评论 收藏
分享
评论
点赞
1
分享
牛客网
牛客企业服务