开发者学堂课程【ALPD 云架构师系列-云原生 DevOps36计：不可变构建及如何提升构建效率（二）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/82/detail/1269
不可变构建及如何提升构建效率（二）
内容介绍：
一、可预期的系统，始于可预期的制品产物
二、几个常见的构建问题
三、不可变构建
四、构建效率问题：积少成多
五、提升构建效率的实践建议
四、构件的效率问题：积少成多
这是简单的一个概念，当然也需要去检视自己身边，观察是否存在不对的地方。这里其实所有的东西的准确性，构建准确性，永远比速度更重要。因为如果一旦做的不准确，不一致，经常发生变化，或者说版本不可控，那所有东西就是无用的，这就是浪费。如果在做好准确性的前提下，另一个单纯从构建的角度去考虑构建的效率问题。这里来看一个简单计算公式：100个工程师，也就是从公司选择一个团队出来，数量是平均每人每天构建10次。
不管是本地，还是 CIA 基础上构建十次，每次假设1分钟时间。那每天需要耗费16个小时，构建时间要达到16个小时，这是非常大的数据，也是非常大的一个损耗，很多时候影响工程效率的大因素，就是构建速度太慢了。这个问题普遍存在，因为最近群里关注大家的一些问题，发现了大家提到的构建慢等各种各样的问题。确实很现实，因为构建影影响地方很多，从老师的角度讲，可以提供给大家关于构建效率方面的一些建议。
五、提升构件效率的实践建议
基本原则：无论使用什么提升构建效率的手段，一定要保证准确性，也就是构建的准确性永远大于构建效率。
1、实践建议：
（1）应用瘦身，减少应用的依赖项，例如应用是否过大，是否依赖数量过多，是否不需要某些依赖，基础镜像是否可以缩小。
（2）分层构建，复用底层的构建结果，例如假设拥有很大的系统，其依赖了10个组件，如果每次都要将全部组件拉下来，那可能会导致每次时间很长，效率变低。例如之前在电信公司时，使用 INC 的系统，拉代码要整个下午的时间，那导致构建可能一晚上不一定可以完成，然后如果整个组流程走一遍的情况，一整天时间就浪费了，这肯定不行。所以系统可能存在多个层次。那应该把底层的东西，先构建出来，能够被上层所复用，使构建效率能提升，可以进行增量式的构建。
（3）构建缓存，避免重复拉取依赖和重复构建，例如像 model 这样的东西，有时候一个代码才几十 K，但是 model 是可以达到2个 G 这样的情况。避免重复拉取依赖和重复构建，这在很多工具里都有，包括云效里有这样的能力。
（4）网络优化，保证代码、构建机器和制品库之间的低网络延时，很多构建问题都是网络问题。自己本机代码构建机器，比如依赖的制品库，就是 NPM 的源，或者 python 的源，这跟自己本机之间的网络延迟太大，是很典型的，NPM 与python可能都要使用镜像也是个原因。
首先要保证其低网络延时，另一点就是代码和构建机器是否在同一个网络域。比如代码可能在 get home，但是构建机器在云效，那就会发现它们之间的延时肯定不会太短，因为它们整个机器的网络路由就比较长。
（5）仓库镜像，减少拉取依赖项的时间，自己可以在公司内部做镜像。
比如简单 maven 仓库，然后像 python 仓库，很多的工具都可以完成，一旦存在计量仓库时，可以极大的减少拉取依赖项的时间。此投资非常划算，国内其实也有较多这种计量仓库，因为有时涉及到网络的影响，有防火墙。这会导致时间特别久，所以这里团队云效，其实也搭建仓库，然后相对减少垃圾的时间。
这里提到了一些提升构建效率的建议。这里每个建议里，不是针对某个语言，而是所有语言其实都需要考虑这些。另一点刚才提到需要构建。那构建应该从哪里来？
最终需要找到相应的源头，刚才也提到了，要最终保证制品和产物的一致性，必须保证代码版本的一致性，依赖的一致性，还有环境的一致性，以及构建脚本的一致性。这些都是在日常生活中，由源代码去管理的。
