27天备战春晚红包项目，字节跳动背后这朵“云”很关键( 二 ) 12月2日

第二个数据，我们每天线上变更是两万次。云的能力，让业务有非常灵活调整的空间。

文章图片
第三个数据是我们每天新增大约1500个A/B测试，说明我们有很多想法的时候可以快速验证，就会产生进化。我再举个例子，假设有两家公司，他们的方向一致，战略水平也差不多，如果一家公司每个星期能做10个A/B测试，验证10个想法，另一家公司每个星期只验证1个想法，可以想象经过半年之后，两家公司会拉开多大的差距。所以说当方向、战略差不多的情况下，敏捷就是决定竞争力的关键因素。
如何做到敏捷开发？
首先是对业务有宏观设计，对整体架构做合理分层。因为不可能所有地方都敏捷，一些更偏应用、更频繁改动的部分需要敏捷，一些基础的模块需要更稳定、更高性能。我们要对业务有宏观的设计，这样可以把不同子系统放到对应的位置上去。如果胡子眉毛一把抓，什么地方都想快，这是错误的，而且也是很难实现的。

文章图片
有了宏观的设计，接下来说具体的实现方法：第一是微服务化，拆更小的服务单元，从开发上就可以有利于快速地变更，这些服务单元能够在很多业务系统中灵活组合以及多人并行开发。微服务是提高开发效率非常重要的一点。
第二个是容器化，这个概念我相信在座各位都比较了解。容器对于运维体系来讲有点像集装箱对于货运，可以解决环境部署的问题、隔离的问题、资源分配的问题。容器本身的开销可控，未来还有进一步提高灵活性的空间，以及重组的空间。

文章图片
是不是有这些技术之后就很美好了？我想说的是，从实践来看，问题才刚刚开始。
比如说运维、质量和发布体系的问题。有了大量的微服务，一旦有一个服务出问题，会导致故障的影响面不可控，排查很麻烦。做过运维的同学会了解，有可能会产生服务雪崩。另外，当我们想扩容的时候，怎么样在一条服务链路的依赖体系下比较自动地扩容，还有灰度发布问题，还有很多其他的问题。如果这些问题处理不好，你会发现你的发布是变快了，但维护代价也在成倍增加，渐渐地就敏捷不起来了。
所以我们做了大量投入，建设完善的DevOps体系，包括持续集成的流程、平台、线下测试环境、灰度发布、全面的监控系统、容灾系统、故障半径分析与治理、自动缩扩容等。直到今天我们还一直在做，就是让开发人员更关注业务本身，其他麻烦事儿让平台解决。
第二个是存储的易用性问题。微服务化之后，存储成为限制敏捷开发的一个关键因素。
存储是一个技术很复杂的领域，专业性很强，目前还没有一种可以应用于各个领域的存储技术，我们需要建立一套产品矩阵来满足需求。通过存储计算分离、架构改进、容器化部署、自动运维工具等等，来达成更优的存储方案。
第三是性能优化。前面做了这么多敏捷、自动帮助开发者降低成本的事情，都是有代价的，性能损失就是其中之一。如果不去改进，从系统延迟和综合成本两方面，都会遇到挑战。我们做了大量的性能优化工作。
经过多年的技术实践，我们的在线微服务数量超过10万，这是指微服务的类型，确实是很大的一个数字，我自己都觉得可能有点太大了；我们容器实例部署的规模大概是1000万的量级，应该是国内容器规模最大的企业之一，目前我还没听到过其他企业公布过更大的数字。我们在微服务和容器的使用上是非常极致的。