秒级计费？毫无技术含量！秒级部署？谁特么在乎？

版权声明：任何转载需全文转载并保留来源（微信公众号techculture）和该声明，并同时转载文后的二维码，否则视作侵权；如有文字或图片不全，请移步公众号techculture。

从当年的3Q大战，到各种中低端手机的网上抢购秒杀，消费级IT早已经脱离了技术、产品、口碑的本原，娱乐圈氛围甚浓，一时竟分不清身处IT圈还是娱乐圈。这种热闹并不是消费级IT所独享，今天说说企业级产品，特别是云主机产品：秒级计费和秒级部署，都毫无技术含量，都谁特么在乎？

       牛人怒了：草拟个锤子！秒级计费和秒级启动，多牛掰啊，秒级啊，以前都是小时级的，秒是小时的三千六百分之一，提高了三个数量级你不知道吗？我知道，所以我们来多聊几句。

    秒级计费

       抛开别的，先说，秒级计费，就是计费精确到秒嘛。首先，这是指结算使用时长的时间精度；其次它不是每秒来扣费，通常是隔一个小时或一天，这是指结算周期。

云主机的一些属性是按使用时长计费的。时长就是结束时间减去起始时间。但是，所有的度量都有个精度，以前没有云主机的时候呢，这个精度是年或月。有了云计算以后呢，大部分服务商采取了小时为单位。就是不管什么时候开始结束，一次计费周期至少是一个小时，算法可能是四舍五入、向上取整等等。

       很显然，时间精度是精确到小时、秒甚至毫秒，在技术上没有区别，技术所有的硬件和操作系统都支持毫秒时间。手机也不例外，不用说服务器了。

       那对对于开发人员来讲，起止时间的记录精确到什么单位都一样，只是整数的位数或小数点后的位数变了。比如原来记录结束时间是33秒，现在记录到33.222秒，可能数据类型也变了。

原来用户使用了3700秒，会算成2个小时，费用是2*小时价格。现在按秒计费了，会算成3700*每秒价格，或者是小时价格*3700/3600。也就是说，只需要在计算的时候，把精度调整一下。

当然，由于一个产品有好几项计费属相，好几款配置，系统设计比我说的要稍微复杂一些。但总的来说，变更计费精度，从小时到秒，对于一个产品来说，一个熟练的工程师可以在数天或数周内完成。只需考虑周全，剩下的就是体力活，普通的初级工程师一样干。

结论是：秒级计费，就是个有研发工程师的团队都能干的事。这个怕是没人可以否认。

那么，秒级计费很重要吗？普通的云主机通常在0.1元到1元每小时之间，换算成每秒的费用大概在0.0001到0.001元之间。肯定差3600倍，没错，至于是不是厂家会把苗费用设置成小时费用的3600分之一，那是另一回事。

如果我只用一秒、十秒、一百秒，你却收我一小时的钱，虽然只有不到一元的钱，也不好吧？假如我是1000台呢，你不就得受1000元了，按秒的话我可能只需要几元几十元钱。

这种场景有没有？有。概率是多少？1%不到。我真的很难找到需要用几秒几十秒甚至几百秒去完成的工作，基因分析？地质数据分析？分布式计算？操作系统启动，是需要几秒到几十秒的，程序和数据的初始化是需要网络传输的，至少也要几秒到几十秒。而什么样的任务只需要运行几十秒？一个非常简单的demo环境？有可能。

所以只有极端的极少数场景下，按秒计算对客户有意义。而且，这对服务商来说，过于极端了。所以大部分厂商并不会迅速支持到按秒计费。不是做不好，而是暂时没这需要。

秒级部署

       有人说：秒级部署呢？没有秒级部署，秒级计费都没啥意义的。

       卧槽，我都说了，秒级计费都没人关心，秒级部署是为秒级计费准备的，更没人关心了。

       有人说，这是NB技术，你不关心我关心。那就简单说说吧。

       部署时间包括三部分：业务准备时间，创建时间和启动时间。业务层处理时间是指业务层处理请求所需要做的权限验证、资金验证、资源调度等，创建时间是指VM本身直接需要的网络、磁盘、CPU、内存的准备时间，启动时间是指VM准备好后从通电到OS加载完成用户可登录的时间。

       业务层处理时间反映了业务系统的复杂性程度和架构的合理性。通常这个时间不会超过5秒，简单的业务平台，这个时间可能不超过3秒，你要严格限定在内网，再短点也可以。

       上回有个哥们说，OpenStack一个创建主机的请求要发几百个内部API调用，我们想了很多很多很多办法才把业务层处理时间搞到5秒以内。活该，谁让OpenStack为这点事搞这么多API请求？哥们冤枉：没办法，OpenStack就那么设计，为了灵活性和扩展性考虑吧。那也活该，谁让你用OpenStack干这个事了。

       事实上，如果用OpenStack本身做公有云或私有云，OpenStack本身的业务层很可能不够用，还要在其上加业务层。你想好了吗？

       现在来看创建时间。创建时间是指VM本身直接需要的网络、磁盘、CPU、内存的准备时间。这个过程最大的耗时在IO写入，主要是VM本身的配置文件写入，和VM的磁盘创建。所有的VM创建方法，其他的过程都差不多，没多少变化的余地，而VM的系统磁盘创建过程，可能有不同的方法，这将决定创建时间的长短。这是指从一个预先存在的镜像生成一个供即将生成的VM使用的系统磁盘镜像。最近PPPCloud箭头云主机的网站上有一篇《PPPCloud箭头部署时间为什么选择50秒而不是10秒》对此也做了描述。

       VM的系统磁盘创建过程取决于四个方面：存储介质、网络传输设计、本地缓存设计、系统盘文件格式、预分配磁盘大小。

       存储介质的影响是显而易见的，Sata、SAS、SSD，不同的磁盘，获取的读取性能差异很大，IOPS从几十到几十万不等。这取决于大场景。同一种介质，如果采用不同的存储阵列、块大小、硬盘调度方案也会出现性能略有差异，这通常取决于小场景。1.5GB的镜像文件，SSD介质存储时间只有3-5秒，而Sata和SAS可能需要20-30秒。

       网络传输设计，是指系统磁盘创建过程中需不需要网路传输，传输的物理链路如何。如果有本地缓存设置，当然可能大部分情况不需要网络传输系统磁盘。如果需要网络传输，那么传输的物理链路是千兆还是万兆网络就很重要了，这回产生近10倍的传输速度差异。如果采用本地全缓存，或共享存储，或分布式存储，可以避免网络传输，提高创建速度。

       本地缓存设计就是为了减少网络传输产生的。如果系统的镜像很少，可以全部缓存在本地Host上，或者热点镜像很固定，本地缓存命中率也很高，这基本可以避免网络传输。不管怎样，只要设置了本地缓存，就需要有缓存大小、替换算法等设置。

       系统盘文件格式有很多，raw、qcow2、LVM卷等，他们占用空间和性能影响略有很小的差异，当然，所支持的功能也有差异，这里不展开说了。这里最影响创建时间的，是VM磁盘的全量拷贝还是增量拷贝的选择。增量拷贝就是通常所说的快照，也就是创建一个VM只需要在源镜像文件上创建一个快照，这通常耗费不到1秒。而全量拷贝，耗费时间从数量到数十秒数百秒不同，取决于存储介质，系统镜像文件的大小。

       预分配磁盘大小，主要是指在系统盘文件格式采用稀疏文件情况下。即使是采用全量拷贝，为了减少创建时间，也可能采用稀疏文件格式。稀疏文件格式虽然占用空间少，但第一次读写速度比较慢，所以可以预分配一部分货全部空间大小，提高第一次读写速度。这个预分配过程，根据预分配大小和磁盘介质，将占用数秒到数十数百秒不等。

       那么，最快的创建过程是什么样的呢？全SSD硬盘，全万兆网络，共享存储或分布式存储或本地缓存所有镜像，不预分配磁盘，增量快照方式创建VM系统盘。增量快照方式创建VM系统盘，意味着诸多VM共用同一个源镜像。

       简单说一下启动时间，其实这个时间大部分服务商并不需要做优化。创建之后正常启动就是了，主要取决于存储介质。但对于VDI，也就是做远程桌面的厂家，却是个问题，因为很可能全公司几百人同一时间开机，存储却可能是集中的，就会很慢。要么分散存储，要么减少OS加载时的IO压力，比如使用共享内存。

       但是，你真的希望你的VM和别人的VM用同一个镜像源文件甚至同一块内存吗？服务商不会告诉你这个风险，而你得到的只是缩短了若干秒的启动时间。

       你真的能用到万兆网络吗？这个成本是会算在用户的头上的。

       事实上，即使不采用任何上述的优化措施，甚至不一定采用SSD磁盘和万兆网络，现在主流的服务商创建时间，linux也就是几十秒，windows也在十分钟之内。能满足我们绝大部分场景的需求了，不是吗？

 

    你现在还认为秒级计费和秒级很牛掰吗？对于服务商，这只是个选择题，不是个技术山头。

       技术很好，数字也很好，听起来没什么不好，但是否有人告诉你技术背后的风险和代价呢？