谈谈技术和成本（三）

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

下面就分享下我的理解：

技术为什么很重要？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

所以，成本是上升了，还是下降了呢？

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

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

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

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

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

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

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

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

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

未完待续。

相关阅读：

《谈谈技术和成本》

《谈谈技术和成本（二）》