如何权衡技术和成本

2020 年 3 月 18 日

如何权衡技术和成本

技术为什么很重要?


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


本文转载自成哥的世界公众号。


原文链接:https://mp.weixin.qq.com/s/BNSt5EleZcZWEMQC7jELzg


2020 年 3 月 18 日 20:0774

评论

发布
暂无评论
发现更多内容

架构师训练营 第五周 作业

Poplar

Redis分布式锁课堂开课了!

小闫

redis Spring Cloud Redis项目

ThreadPoolExecutor 线程池使用

郭儿的跋涉

线程 多线程 线程池

区块链正处于手脚并用攀爬的“攻坚时刻”

CECBC区块链专委会

数据上链 市场选择

高效程序员的七个好习惯——你有吗?

小谈

JVM Java 面试 springboot 程序员素养 SpringCloud

游戏夜读 | 互动剧的黎明到了?

game1night

系统架构师week04 Homework - 互联网架构技术手段和方案

尔东雨田

极客大学架构师训练营

分布式柔性事务之最大努力通知事务详解

古月木易

分布式事务

理解 Mysql 索引底层原理只需这一篇就够了

小谈

MySQL 数据结构 Spring Cloud Spring Boot Java 面试

听说你还没学Spring就被源码编译劝退了?30+张图带你玩转Spring编译

程序员DMZ

spring Spring源码编译

马匹、马镫、马车,和华为的数据基础设施革新

脑极体

架构师训练营第4周总结

aoeiuvzcs

Kafka 消息丢失与消费精确一次性

古月木易

kafka

测试开发工程师修炼手册—测试技能大盘点

Zoe

测试工程师产出

2020年7月国产数据库排行:华为、腾讯发新品,中兴、阿里结硕果

墨天轮

数据库 阿里 排行榜

自动特征工程在推荐系统中的研究

天枢数智运营

人工智能 推荐系统

一致性hash

彭阿三

一致性hash

分布式柔性事务之最大努力通知事务详解

奈学教育

分布式事务

Kafka 消息丢失与消费精确一次性

奈学教育

kafka

五分钟让你搞懂Nginx负载均衡原理及四种负载均衡算法

架构大数据双料架构师

阿里技术官:这样带你学Spring全家桶,其实没你想的那么难

小吴选手

spring Spring Cloud Spring Boot

nightingale安装详解

曾祥斌

AndroidStudio真机调试 - Waiting for Debugger

麦叔

Android Studio 真机调试

原创 | TDD工具集:JUnit、AssertJ和Mockito (二十五)运行测试-在IDE中运行测试

编程道与术

Java intellij-idea 编程 TDD 单元测试

向女朋友解释乐观锁与悲观锁的小妙招!

小闫

spring 面试 Spring Cloud 乐观锁 悲观锁

太阳马戏团在疫情下的组合式创新

石云升

商业模式 组合式创新 思想实验

四面阿里巴巴回来分享面经总结,定级P7架构师

小吴选手

架构 技术 Spring Boot 阿里 Java 面试

猿灯塔:疫情冲击,去体验远程面试被怼10分钟,今年Java开发找工作真难

猿灯塔

java基础思维导图,让java不再难懂 (建议收藏))

码哥小胖

Spring Boot Java 面试 Java 分布式

信创舆情一线--印度封禁59款中国App

统小信uos

App 舆情 印度

忘掉 Snowflake,感受一下性能高出 587 倍的全局唯一 ID 生成算法

今日长剑在握

golang redis 架构 分布式 CAP

如何权衡技术和成本-InfoQ