谈谈技术和成本(三)

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

下面就分享下我的理解:

技术为什么很重要?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

未完待续。

相关阅读:

《谈谈技术和成本》

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


原文发布于微信公众号 - Forrest随想录(forrest_thinking)

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

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Rainbond开源「容器云平台」

36氪报道:「好雨云」能否成就 Gartner 心中的技术主流?

1352
来自专栏即时通讯技术

写给小白的实时音视频技术入门提纲

这是由一篇我的演讲稿整理出来的文章,目标读者是对实时音视频开发感兴趣但是又不知道如何下手的初学者们,希望把我的经验分享出来,对大家有所帮助。

8053
来自专栏嵌入式程序猿

ARM mbed是你在等的吗?

今天看了几篇ARM mbed在2015技术大会上的视频,小猿第一次关注到这一系统也是在去年一次偶然的机会,那么mbed到底是什么样的一个针对嵌入式的操作系...

3328
来自专栏WeTest质量开放平台团队的专栏

Hi,腾讯 WeTest 联合 Unity官方打造了新的性能分析工具 UPA

早在2016年ChinaJoy开始,WeTest曾受邀出席过Unity中国的线下性能场的活动,介绍我们的自动化框架和王者荣耀的故事。当时的活动很成功,期间我们收...

2221
来自专栏用户3254834的专栏

干货丨小程序和APP的区别

小程序上线以来,一向被称为“便携版”的APP,关于两者之间的区别,无外乎小程序相对轻便、开发成本低,但是对于两者的详细对比较少,小程序从诞生到产品落地和推广,到...

1431
来自专栏云计算

如何利用云优化加快网站访问

云计算最近成为几乎所有行业的基本业务工具。大多数公司领导人已经注意到云计算及其作用,同时也注意到那些可以优化云计算的方法。总而言之,云计算,曾经的奢侈品如今已经...

24611
来自专栏罗超频道

QQ订阅号来了,有什么值得关注的?

几个星期前,我收到了QQ订阅号的内测邀请,现已入驻QQ订阅号平台(不叫公众平台)。从周边朋友的反馈来看,大家对QQ订阅号平台还是很重视的,很简单,手Q活跃用户大...

3819
来自专栏EAWorld

企业如何按需选择元数据管理工具?

在各种数字化的影响下,将企业环境中的各种元数据整合利用至关重要。对于企业来说,选择适合自己的元数据管理工具将能最大化发挥元数据的作用,以协助企业完成在数据方面的...

2912
来自专栏SDNLAB

电信云保障之旅

随着通信服务提供商(CSP)正在谋求数字化转型,在云环境中运行其业务,销售数字服务和像网络级互联网公司一样运营,以确保电信云环境和业务流程的高度优先性。随着网络...

35410
来自专栏我是攻城师

8个方法让你成为更优秀的程序员

3016

扫码关注云+社区

领取腾讯云代金券