构建高性能服务的考量

作一款互联网产品，人们每每立马就想到了海量用户、海量数据、高并发、高性能。因此起初作架构设计时就把性能提到了一个不得不作的地位。我我的是很反对这种“未雨绸缪”的方式的，由于对于一个新应用来讲获取一个互联网用户的成本并不小，并且“海量”不是短时间内就会面临的。因此请建议您最好先在基于投入产出比的考量下对快速实现 OR 性能重要程度作出权衡后再作考虑，最好先实现应用再作优化，过早优化是万恶之源这句话不是吓唬小孩子的。固然，本文讲的就是性能的考量，因此文章如下的讲解是在你已经决定要重点考虑性能的基础上。

---

性能无非就是为了经过缩短响应时间来得到良好的用户体验，一般咱们会提及2/5/10法则：用户响应在2秒以内是很好的用户体验；用户响应在2-5秒之间是通常的用户体验，用户能够接受；可是用户响应在5-10秒之间是很糟糕的用户体验，已经接近了用户可接受的极限。因此咱们为了减少用户响应时间必需要分析出可能出现的性能瓶颈在哪里。

如图咱们能够很清晰的看出用户在等待的过程当中发生了什么：

• 数据在网络上传输的时间；

• 后台服务器处理请求并生成回应的时间；

• 客户端处理回复并进行UI呈现的时间；

由于咱们今天讲的是构建高性能服务，因此3咱们暂时忽略。因此响应时间 = 发送时间 + 传播时间 + 处理时间。有些人要问了，发送时间是个什么东东，咱们来分析下一次网络I/O的过程：

1. 将要发送的数据写入进程的数据缓冲区；

2. 调用系统API，这里涉及到用户态到内核态的转化，将数据存入系统内核缓冲区；

3. 数据从内核缓冲区进入网卡；

4. 数据从网卡传输到网络线路；

5. 数据在线路中转换成相应的信号经过介质进行传输；

因此发送时间 = 数据量/带宽，带宽就是数据的发送速度，就是一般咱们所说的Mb/s。那么传播时间又与什么有关呢？很容易想到的就是传输距离和传输速度，传输距离就是咱们现实中的从北京到上海的距离(铺设网线的距离）。传输速度指的是信号的传输速度，一般接近于光速，咱们将其约等于2x10^8m/s。因此传播时间 = 传输距离/传输速度。

如今咱们得出了响应时间 = 数据量/带宽 + 传输距离/传输速度 + 处理时间。究竟是哪个步骤最大的影响了咱们的用户响应呢？咱们举个例子，假如客户在兰州，网络出口带宽为4Mb/s（实际运营商提供的4Mb的网络上行带宽远远低于4）；服务器在北京，网络出口带宽为100Mb/s；兰州距离北京约为2000km；发送回应均为10kB(0.08Mb)数据。

• 客户端发送时间 = 0.08/4 = 0.02s

• 服务端发送时间 = 0.08/100 = 0.0008s

• 传播时间 = 2x10^6/2x10^8=0.01s

• 那么响应时间 = (0.02+0.0008) + 2x0.01 + 处理时间；

除去处理时间发送时间+传播时间才为0.04秒，仿佛能够看出影响咱们服务性能的仿佛是在处理时间上。其实否则，这里面哪一项都不能被彻底忽略。好比刚才咱们举得就是个很极端的例子，客户端上行带宽不低，并且服务端只给这一个用户提供服务，因此两端的发送时间都很小；在传输上咱们忽略了信号的衰减，各级路由器的转发，甚至不一样运营商的互联互通问题。可是这两个问题一般不是咱们程序开发者能解决的，这须要科学合理的IDC的支持，并且这个成本是企业很是关注的。

因此咱们仍是把优化重点转移到最后一项服务器的处理时间，这里才是考验咱们架构师，研发工程师，DBA能力的地方。如何实现服务灵活的扩展，部署；如何设计服务的并发策略；选择怎样的I/O处理模型；如何下降业务逻辑复杂度；如何处理负载；如何优化数据库......咱们还有很长的路要走。

推荐书籍《构建高性能Web站点》,感谢做者 郭欣给你们提供了这么一本很优秀的国产书籍。