大型互联网技术架构2 － 运营/技术看运维?

我们继续互联网分布式技术架构。

1. 架构模式



上文发了经典大型互联网分布式架构后，小伙伴积极留言讨论，甚是推崇阿里的很多技术框架，如TDDL, Tair, OceanBase等。不然下次有时间，研究一下阿里的开源框架，来个系列，挑战一下？元芳，你怎么看？

真如我们所见，软件，互联网架构的模式，无非是分而治之，怎么分？

分层： 如网络7层通信协议；经典的MVC3层架构；

分割：按照系统功能，服务来拆分；如首页，商品，购物车等；

分布式：分布式真正蓬勃发展是近几年互联网的野蛮式扩张。

分布式应用：应用模块分布式；SOA; 微服务；

分布式静态资源：动静分离；如图片，css等；

分布式存储：NoSQL为首的分布式存储；

分布式计算：以Hadoop, MapReduce为首的分布式计算；其核心是“移动计算而不是移动数据”

分布式配置

分布式锁： ZK

2. 运维

稍微提一下运维，运维作为大型互联网的基石，不可谓不重要，简直是考验一个互联网公司的运营＋技术实力的时候。一些大型知名互联网公司要求运维做到4个9以上的可用性，即99.99%，什么意思？即一年最多53分钟系统不可用。



如何体现运维的实力？面对成千上万的分布式集群，机器，配置，数据库，文件。。。自动化

自动化发布：自动化发布是看一个大型互联网公司实力的基础，很多网站的发布都是头等大事，加班也多是发布不顺所致。更甚至，有CTO因发布不顺而引咎辞职。

自动化代码管理：又一个考验的基功。代码版本控制，代码分支创建与合并过程自动化。

自动化测试：代码提测后，自动将代码部署到测试环境，自动化测试包括单元，集成，性能，功能，UI等，并发送测试报告。

自动化安全检测：自动对提交代码进行静态扫描以及自动部署到安全测试环境进行安全检测。

自动化部署：最后当然需要自动化部署了。

以上整个过程需要全自动化，而且持续集成，并不是每到版本发布日才开始做的事情，正所谓DevOps。



除此，还有如自动化监控，自动化报警，自动化失效恢复，自动化降级等等。

正所谓，技术看百度(Really?), 运维看阿里，产品看腾讯。足以可见运维对于互联网之重要性。

另外，补充一下我们之前数据库中提及的CAP: CAP原理认为，一个提供数据服务的存储系统无法同时满足数据一致性(Consistency), 数据可用性(Avaibility)， 分区伸缩性(Partition Tolerance).

CAP理论对于大型互联网分布式系统设计具有重要意义，不要企图打造一个完美的系统。

3. 性能测试

性能是与用户感受直接关联的，打开一个1秒以内网页与一个20秒以内的网页，用户的体验如何
4000
？常用指标如下：

TPS: 每秒事务数

HPS: 每秒HTTP请求数

QPS: 每秒查询数

常用的性能测试方法：

性能测是一个不断对系统增加访问压力，以获取系统性能指标，最大负载能力，最大压力承受的过程。主要采用不断增加并发请求数。如下图，通常为抛物线规律。



性能测试：以系统初期规划指标为预期目标，对系统施压测试。

性能测试：

以系统初期规划指标为预期目标，对系统施压测试。

负载测试：对系统不断增加并发请求直到系统多项性能指标达到安全临界值，此时如继续施压则，系统处理能力开始下降，从而检测出系统的极限。

压力测试：超过上面的安全负载，继续施压，直到系统崩溃，目的是获取系统的最大承压能力。

稳定性测试：在特定系统环境，如硬件，软件，网络等，给系统夹在一定业务压力，使系统运行一段较长时间，检测系统的稳定性。

常用性能测试工具：



拿好，不谢！

4. 性能优化

性能优化是硬功夫，来不得半点虚的，快就是快，慢就是慢，数据说话。

浏览器优化

减少HTTP请求，即合并请求，合并css，合并JavaScript, 合并图片。

使用浏览器缓存：设置HTTP头，Cache-Control, Expires。对于静态资源，建议采用逐步更新方法，如需要更新10个大图片，建议一个一个图片逐渐更新，并设定间隔，否则浏览器突然大量缓存失效，集中更新，必然加大负载。

压缩： GZip压缩css，javascript等。

减少Cookie

CDN : 上文已经提及。

反向代理：反向代理（Reverse Proxy）方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个反向代理服务器。

应用服务器性能优化：主要靠缓存，集群等。

Memcached:被大量网站使用，设计简单，性能优异，服务器集群互不通信，海量数据可伸缩。Memcached采用高效的TCP协议作为通信协议，核心序列化则自定义，支持丰富客户端，高性能内存管理。



协议简单：memcached的服务器客户端通信并不使用复杂的MXL等格式，而是使用简单的基于文本的协议。

基于libevent的事件处理：libevent是个程序库，他将Linux 的epoll、BSD类操作系统的kqueue等时间处理功能封装成统一的接口。memcached使用这个libevent库，因此能在Linux、BSD、Solaris等操作系统上发挥其高性能。

内置内存存储方式：为了提高性能，memcached中保存的数据都存储在内置的内存存储空间中。由于数据仅存在于内存中，因此重启memcached，重启操作系统会导致全部数据消失。内容容量达到指定的值之后memcached回自动删除不适用的缓存。

Memcached不互通信的分布式：memcached尽管是“分布式”缓存服务器，但服务器端并没有分布式功能。各个memcached不会互相通信以共享信息。

上述看似复杂的分布式缓存设计，当引入一些取舍后，其卓越表现让架构师趋之若鹜。

5. Wikipedia著名架构

最后，上一个Wikipedia的著名架构，其著名在以少胜多，只有10几名技术人员，几百台服务器，并且采用传统的LAMP。



时间关系，第二部分到此。后续会继续介绍一些大型互联网架构之分布式存储，如文件系统，键值系统，数据库等等。

公众号：技术极客TechBooster