乐添：很高兴有这个机会跟大家交流阿里巴巴在云计算的探索，部署的过程中跟服务器、软硬件相关的尝试摸索。介绍一下服务器开发、验证、软硬件优化过程中我们遇到的一些事情。先做个广告，最近一个里程碑事件，对于阿里云来说，付费的用户数量首次超过100万，对阿里是个比较大的事情，这是亚洲首家超过100万用户的云计算公司。

简单回顾一下云计算业务的发展以及这些发展对于基础设施服务器、网络、存储的新要求，技术方面大家比较熟悉了，这里举的一个例子是网站的业务发展的过程，最开始如果我们要做一个网站的话，简单来说需要有一台或者几台服务器的主机。随着我业务规模的扩大，我需要把我的数据库独立出来，同时如果服务器数量越来越多，可能要考虑负载均衡，如果数据库的业务独立出来之后还要考虑缓存的事情，要考虑数据库的安全性、可靠性。如果我的业务数据继续增加，对于数据的存储有新的要求，需要有独立的存储技术，包括分布式存储、针对某些特定应用的结构化的存储。随着我的业务的规模越来越大，我可能要扩展到全国对于全球，对网络会提出一些新的要求，比如为了更好的客户体验，降低成本，需要内容分发网络。随着数据进一步增加，最后还需要有处理大数据的专用的业务。

在业务发展的过程中，不同的应用对于基础设施服务器来说会提出不同的要求，比如有些对成本特别敏感的业务，对于数据库的业务，对于性能要求是多少，弹性存储的各种业务，对于可靠性要求是多少，海量的服务器在数据中心运维的要求是什么样的。都在我们设计服务器开发验证流程中提出各式各样的要求。对于服务器的实现来说，在具体的配置上我们会有不同的具体配置，偏重主频的、大IO的、大容量存储的、高内存的，这几年又发展出很多新的异构计算的加速计算的。

举一个例子，以计算和存储来说，IT技术发展过程中计算和存储一直是分分合合的，2007、2008年左右做云计算的时候一个比较主要的共识或者当时主流的做法就是需要本地化，计算的资源和存储的资源尽可能靠近，尽可能减少获取数据的成本，很多时候会把计算和存储做在一个物理上本地化的资源池或者盒子里，同时尽可能的把计算和存储的能力同时都往大的方向做。当时很多业务的架构，用单一的集群大容量存储加上高性能计算可以满足很多当时业务的需求，随着接下来几年行业的发展，特别是北美互联网行业的发展下面，因为计算技术的发展、存储技术的发展，NVMe，网络技术的发展，数据获取的成本大幅度降低，现在比较主流的是计算和存储分离的架构。传统的集中式的存储都是在主机里面，通过共享的交换机连到其他远端的服务器上去，大部分数据的处理和备份都在同一个交换机下面完成。计算资源在物理上集中的放在某些机架位上，通过特定的交换机连到远端的存储资源上。在这些架构变化方面我们会遇到各种各样的问题，各种各样的挑战，其中有一个印象比较深的是在最早尝试这样架构的时候，我们在不同的物理机架位上我们放的是计算资源比较集中，我们典型的业务部署上去的时候发现存储节点的交换机的带宽很容易被打满，丢包率和重传率都非常高，因为我们的业务对于同一份数据会有多份副本拷贝的设计，在新的架构下面，在副本拷贝的过程中会发生比以往多的多的拷贝的失败，会重新发起副本的重传，这样会进一步加剧网络上带宽的浪费，因为有更多的包会倍发出来，又有更多的包被丢掉。

遇到这样问题的时候，我们现在有几个不同尝试的解决方法，比如我在交换机这一侧可以选用我的端口的buffer，更大的交换机直接换硬件。这个会带来硬件上的变化和成本上的变化。还有一个尝试，我们尝试把一定比例的存储节点和计算节点在同一个机架位上混合部署，通过和实际的应用业务做联合的调试，比如以四个计算节点配一个存储节点的比例来部署的时候，以八个计算节点配一个存储节点的比例，在不同的比例加上业务实际的部署情况下，可以逐步降低重传率提高业务的效率，这是优化前和优化后的重传率的数据的对比。另外一个遇到的问题是配置分布式存储之后，在磁盘的吞吐率上面我们发现进行大文件大压力写的时候磁盘吞吐率达不到预期，大量内存回收操作，cgroup内存策略，够用就行，内存策略调整，释放性能，优化成本。存储节点里因为可以调整内存上限，可以得到在系统架构下面大的需要内存的物理空间的值，针对具体的存储节点做内存的优化，比如最早我们给某个节点做系统架构的时候选了512G的内存，优化下来发现源源不需要这么多内存就能让它达到原来预定的磁盘的性能，这样可以节省一大笔内存的成本。

某一个业务上我们发现同样的架构下，IOPS的性能测试的时候发现小块读写性能达不到预期，大概是预期的60%，我们研究这个架构计算节点和存储节点比，比如原来是8比1的比例，每个计算节点写了50个进程，有400比1可以配比，400比1相对来说还是偏小的比例。我们对所有的IO的分布，包括大小、时间，都做了统计，发现绝大部分的读写都是小块的读写，我们在计算节点下做了一些优化，计算节点本身有一些小容量的SSD，我们根据具体业务把SSD容量换成NVMe的SSD，根据统计到的读写特征，把大部分的小块的读写都放在了本地的NVMe的SSD上，把大的放到远端的IO上面。满足性能的条件下硬件成本的变化还是可以接受的。

现在我们在云计算业务高速发展的时候做的服务器开发工作跟原来有很大的不一样，几年前我们行业里大部分做的都是非常按部就班的，从方案开始，有比较长的研发过程，研发完之后在我们的业务适配有一个引入的过程，最后才会大规模的部署，每个业务都会几个月来计，但现在在业务飞速发展的情况下大部分工作集中在后面的融合过程里面，在研发其没有结束没有完全量产的情况下我们就已经开始跟我们的业务做适配性、兼容性的测试，线上实际小规模的做一些部署，可以并行的流程早一点开始。引入的时候也做了一些调整，原来有几个不同的阶段，实验室、小批量、灰度，分别针对阿里自己的线上的监控业务、监控的工具、运维的工具、业务的操作系统应用的适配，现在都会做一些适当的裁减，甚至有更激进的做法，基本上可以理解成我们缩短40%的引入时间，从一个项目立项大最终商用对外发布大大缩短。

对于新的融合的流程来说，我们的目的还是一样的，我们希望上线的产品有足够的可用性和可靠性，这些目标我们不会降低，同时我们希望继续提升客户应用的实验体验，同时希望优化成本。项目经理们经常挂在嘴上的话，又要快又要好又要便宜，这种事情是很难发生的，大部分我们都要为这个做出一些取舍，做出一些牺牲，今天的分享就到这里，谢谢大家。