专栏首页Forrest随想录谈谈技术和成本(三)

谈谈技术和成本(三)

接上篇文章,我们讲了技术不是唯一的解决成本问题的手段,但这不代表技术就没有意义,没有价值,相反,到了一定阶段之后,技术将成为最终的决定因素。

下面就分享下我的理解:

技术为什么很重要?

为什么说技术很重要,因为商务上也好,利用新技术和新硬件的手段也好,还是从业务入手去分析业务逻辑是否合理也罢,这些手段在成本优化和控制阶段,起到的作用虽然是立竿见影的,但是从长久来说,这些手段无法一直持续发挥作用,再往后,就必须要靠技术了。

但是,这里我们得搞清楚,靠技术达到成本管控和优化的目的,要怎么做?或者让技术发挥什么作用?这一点很关键,谈谈我的理解:

1、写出来的代码和逻辑本身是性能最好的,吞吐是最高的,这个就非常考验开发人员的代码精深程度,“一个优秀的工程师,可以抵得上100个平庸的工程师”,因个人能力和素质不同,所以很难控制。且属于微观上的优化,也就是只能靠人,只会带来局部的优化,并不能带来面上的改善,同时很容易走到前面讲的技术情节中去,导致过多的过度优化。

这里细究起来,其实根本因素还是在人,而不在于技术本身。而人的技能和素质的培养,就依赖于,良好的人才培训和成长体系,需要用时间和耐心去等待,再就是要有好的机会给到人才去锻炼,所以,这个时候,人才优势带来的成本收益,就要看整个公司的大环境和周边配套体系了。

2、接上条,关于人的能力,还会体现在产品逻辑和架构设计上,还是上篇文章提到的,以微服务架构为例,一个业务领域,最终应该拆分成什么样的粒度的应用和服务?服务间的调用逻辑怎么是最合理的?什么时候应该引入数据库分片,分几个片合适,按照增长趋势,能够支撑多长时间?等等等等。

其实,最后就是看业务架构师的水平和能力。

还有一个产品逻辑问题,就是有时候运营和产品或许只从功能角度考虑,不太会考虑到技术因素和成本,这时架构师要做的就是补齐这个短板,要把运营和产品设计上明显会带来极高的技术成本,或者性价比不高的功能找出来,并进行说明和重新设计。

所以,业务架构师,首先一点得必须懂业务,去了解业务,不然纯技术层面的架构设计,不能说没有意义,但是可能就仅仅停留在技术层面了。

这一点上,我觉得也应该是技术要发挥价值的的地方。

3、通过技术建立良好的容量、性能以及成本管控体系,上面两个点,是靠人的话,第三点就是靠技术管理体系,有明确的标准和约束条件进行管控,比如一个应用的容量水位是多少,现在实际是多少,多了就应该将资源归还,少了就增补上去,这样做就会有一个统一的运作机制去操作。

成本管控,就是业务或应用归属于那个团队,应用所占用的资源成本也归属过去,这里的资源最基本的包括硬件资源、存储资源和带宽资源等等。

同时,这里还有一个问题就是应用间的调用,也就是虽然应用是我的,但是我设计出来是为了给其它业务服务的,那这个成本应该如何结算,这里面就要设置各类业务标识,调用的时候带上这个标识,并通过日志打点记录下来,最后分析统计,最后是按次数结算,还是包流量结算,还是按照吞吐阶段等等,又要看具体的业务形态是如何的。

这一点,可以看一下各大公有云上的不同资源的计费模式,不同的资源和服务模式,不同的计费方式,意思是差不多的。

这里带来的另外一个问题就是,为了管控成本,我们又带来了新的成本投入,为了实现上述这些成本管理的能力,我们就需要投入新的人力来做这些事情,会不会因为成本结算问题带来各种撕逼扯皮等额外的成本?

所以,成本是上升了,还是下降了呢?

4、再往后走,从全局角度出发的技术架构设计来提升成本优化效率,比如在离线混部,这一点一般中小企业没这么强的诉求,但是对于BATJ,或者超过几万台、十几万台服务器规模的企业就非常需要了。

因为我们现在提到成本优化问题,就会涉及资源利用率,也就是CPU使用率问题,现在业界一般的CPU使用率能到10%-15%就已经非常好了,大部分可能都在5%-10%之间,甚至更低,这里单纯靠提升应用的容量和性能是无法带来CPU利用率持续提升的,因为性能瓶颈最终不一定出现在CPU上,还取决于磁盘、网络、内存,以及代码质量等等因素。

所以,问题的解决方案,不在问题本身,也就是我们不能总想着怎么通过容量和性能提升来提高资源利用率,而是要跳出这个问题,从全局去看。(貌似,跳出问题看问题这个观点,我在很多地方都用到了。)

目前业界提升资源利用率,最有效的手段就是,在离线混部,简单点讲就是,服务器上白天跑应用,晚上闲时就用来支持大数据的离线任务执行,CPU和磁盘IO妥妥的被充分利用起来,因为实际情况要比这个复杂的多,我也不专业,就不细讲了。

极客时间专栏的文章中,我也提到过,在离线混部,不是你想混就能混的,从底层服务器的硬件系统架构、到机房网络架构、到操作系统内核设计、再到上层应用架构和数据架构设计,以及周边的全自动化调度体系,这是一个非常复杂的系统化工程,从最初服务器选型和定制,到机房选址开始都得考虑设计的很周全,一脉相承才可以。

之前跟一个阿里的高级技术专家交流,他就提到,他们设计了非常牛逼的调度系统,可以很快很方便的将应用或任务调度起来,但是实际上线之后,发现这里硬件不匹配,那里网络架构不支持等等非常现实的问题,但是底层的东西又不是随随便便能动得了的,所以遇到这种问题就很痛苦,平台的应用范围也就相对有限。

我们现在看到BATJ等等,在容器化方面做的很超前,在弹性伸缩和在离线混部方面做的很牛逼,,我们看上去,好像是大厂说搞个啥事情就搞起来了,但是我认为这个是长期、持续,且大量的高精尖研发力量投入所带来的结果,是体系化的产出,其背后的积累才是关键。

回到主题上来,在超大规模体量下的系统,为了更有效的控制成本,这时技术就是核心手段了,而且到了这个阶段,也只能依赖技术,但是,从上面的案例我们又看到,这时在技术上投入的成本,无论是人力、管理、外部协作、周边体系配合等等的成本又是非常巨大的,也就是我们为了通过技术解决一个问题,实际会带来问题之外的巨大的额外成本。

那这个投入到底划不划算,又该怎么权衡呢?

未完待续。

相关阅读:

《谈谈技术和成本》

《谈谈技术和成本(二)》


本文分享自微信公众号 - Forrest随想录(forrest_thinking),作者:赵成

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2018-05-07

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 谈谈技术和成本(二)

    “技术是很重要的因素,但不是唯一的手段,而且用不好会越管越乱,起不到优化成本的作用,还会带来更多的成本损耗。”

    赵成
  • 谈谈技术和成本(四)

    前面谈完技术不是唯一因素,但是技术却很重要,接下来就谈谈,成本管理这个事情,一定要把握好度,千万别搞的越管越乱,越管成本消耗越大。

    赵成
  • 谈谈技术和成本

    因为最近我们内部也在实施成本优化和管控的事情,再加上之前写文章对一些技术和成本效率问题上的一些总结,发现这个事情还有点意思,是值得反复思考和玩味的一个问题,所以...

    赵成
  • git变基

    mwangblog
  • CVPR2019满分文章 | 强化跨模态匹配和自监督模仿学习(文末源码)

    首先,祝贺我党在3月成功举行了“两会”,希望我党越来越强大。在接下来将会有好几场关于IEEE会议,也会着重指向接下来人工智能的发展风向标,有兴趣的同学可以持续关...

    计算机视觉研究院
  • SaaS|软件创业公司的三大雷区

    作者:T客汇 杨丽,原文作者:风险投资咨询师 Philip Levinson 关键词:SaaS、创业 对处于成长期的 B2B 软件和 SaaS 公司而言,向企业...

    人称T客
  • .NET应用架构设计—面向查询服务的参数化查询设计(分解业务点,单独配置各自的数据查询契约)

    阅读目录: 1.背景介绍 2.对业务功能点进行逻辑划分(如:A、B、C分别三个业务点) 2.1.配置映射关系,对业务点配置查询契约(构造VS插件方便生成查询契...

    王清培
  • 设计模式 - 备忘录模式 - JavaScript

    备忘录模式:属于行为模式,保存某个状态,并且在需要的时候直接获取,而不是重复计算。

    心谭博客
  • 智能音箱全面测试,哪个智能音箱的“智商”最高?

    今年7月,Loup Ventures公布了一项“年度智能助理智商测试”的结果,该测试将谷歌助手与苹果的Siri,亚马逊的Alexa和微软的Cortana进行对比...

    AiTechYun
  • ECCV2020 | 将投票机制引入自下而上目标检测,整合局部和全局信息

    本论文收录于ECCV2020,从自下而上的角度出发,在目标检测任务中引入了投票机制,使得HoughNet能够集成近距离和远距离的class-conditiona...

    AI科技评论

扫码关注云+社区

领取腾讯云代金券