大型互联网架构

大型互联网架构

解决问题的通用思路是将分而治之（divide-and-conquer），将大问题分为若干个小问题，各个击破。在大型互联网的架构实践中，无一不体现这种思想。

架构目标

• 低成本:任何公司存在的价值都是为了获取商业利益。在可能的状况下，但愿一切都是低成本的。
• 高性能:网站性能是客观的指标，能够具体体现到响应时间、吞吐量等技术指标。系统的响应延迟，指系统完成某一功能须要使用的时间；系统的吞吐量， 指系统在某一时间能够处理的数据总量，一般能够用系统每秒处理的总的数据量来衡量；系统的并发能力，指系统能够同时完成某一功能的能力，一般也用 QPS(query per second)来衡量。
• 高可用：系统的可用性(availability)指系统在面对各类异常时能够正确提供服务的能力。系统的可用性可 
  以用系统停服务的时间与正常服务的时间的比例来衡量，也能够用某功能的失败次数与成功次数的比例来衡量。
• 易伸缩：注重线性扩展，是否能够容易经过加入机器来处理不断上升的用户访问压力。系统的伸缩性(scalability)指分布式系统经过扩展集群机器规模提升系统性能（吞吐、延迟、并发）、存储容量、计算能力的特性。
• 高安全：如今商业环境中，常常出现被网站被拖库，用户帐户被盗等现象。网站的安全性不言而喻。

典型实现

下面典型的一次web交互请求示意图。

DNS

1. 当用户在浏览器中输入网站地址后，浏览器会检查浏览器缓存中是否存在对应域名的解析结果。若是有，则解析过程结束；不然进入下一个步骤
2. 浏览器查找操做系统缓存中是否存在这个域名的解析结果。这个缓存的内容来源就是操做系统的hosts文件。若是有，则解析过程结束；不然进入下一个步骤
3. 前两个步骤都是本地查找，没有发生网络交互。在本步骤中，会使用到在网络配置的中DNS地址。这个地址咱们一般称之为LDNS（Local DNS）。操做系统会把域名发送给LDNS解析。若是解析成功，则解析过程结束；不然进入下一个步骤
4. LDNS将请求返回给GTLD（Global Top Level Domain）服务器，GTLD服务器查找此域名对应的Name Server域名的地址。这个Name Server一般就是你的域名提供商的服务器。Name Server根据客户请求，返回该域名对应的IP地址和TTL(Time To Live)值。
5. 浏览器根据TTL值，把这个域名对应的IP缓存在本地系统中。域名至此解析结束。

CDN

CDN（Content Delivery Network，内容分发网络）部署在网络提供商的机房里面。在用户请求网站服务时，能够从距离本身最近的网络提供商获取数据。好比视频网站和内容网站的热点内容。

若是须要本身搭建CDN系统，有3种主流方案能够选择:

• squid是缓存服务器科班出生,本身实现了一套内存页/磁盘页的管理系统
• varnish是以为squid性能不行，varnish以为linux内核已经把虚拟内存管理作得很好了，squid的画蛇添足反而影响了性能。
• nginx cache是属于游手好闲，得益于nginx强大的插件机制。

LB

LB(Load Balance，负载均衡)就是将负载（用户的请求）根据某些策略，将负载分摊给多个操做单元执行。该技术能够提供服务器的响应速度以及利用效率，避免出现单点失效。

这里回顾下前面介绍的两个小节，其实本质上把数据分类（根据数据更新频率，分为动态文件，静态文件），并把数据放在离距离用户最近的地方。另一点就是，在DNS和CDN具体实现时，也是大量使用了负载均衡技术。

常见的负载均衡算法由：RR（Round Robin，轮询）,WRR（Weighted RR，加权轮询），Random（随机），LC（Least Connection，最少链接），SH（Source Hash,源址哈希）

在常见的互联网架构中，一般使用软件负载：LVS+HAproxy+WebServer（Nginx）。在部署 时，LVS，HAProxy，WebServer都会部署一个集群，用来进行负载均衡。LVS工做在第4层，在网络层利用IP地址进行转发。 HAProxy工做在第7层，根据用户的HTTP请求（好比根据URL，消息头）来进行转发。

在上述实现中，一般还会使用Keepalived+VIP(虚IP) 技术。Keepalived 提供健康检查，故障转移，提升系统的可用性。经过VIP（配置DNS 绑定域名）的形式对网站进行访问。

WEB APP

前端技术：遵循基本的Web前端优化经验，详见Web前端优化最佳实践及工具集锦 
介绍。另外还可使用BigPipe，动态页面静态化，无限滚动的翻页技术等技术提供更好的用户体验。另一部分就是考虑mobile技术了，这块笔者暂时还没涉足，就不谈了。

后端技术：

• HTTP协议：HTTP协议大概分为请求头，请求体，响应头，响应体。不管是WebServer仍是ApplicationServer，不少花样都是基于请求头的请求路径来玩的。
• API接口:使用RESTFUL API，暴露接口。它具备以下好处：1.充分利用 HTTP 协议自己语义。2.面向资源，一目了然，具备自解释性。3.无状态，在调用一个接口（访问、操做资源）的时候，能够不用考虑上下文，极大的下降了复杂度。
• Application Server：在Java中，为了保证程序可以在各个厂商的AS中兼容运行，Sun公司为制定了J2EE规范。从技术发展路径来看， Serverlet,JSP演变都是为了更好地方便程序员们编程。以典型的Tomcat为例，Connector和Container组成一个 Service，多个Service组成一个Server。Connector主要负责接受外部请求，Container负责处理请求。Server提供 了生命周期管理，如启动，中止等。
• Session Framework：在大型互联网架构中，单台机器已经存放不了用户的登陆信息。同时为了支持故障转移等特性，须要一套session管理机制，支持海量用户同时在线。一般能够在遵循J2EE的容器内，使用Filter模式和分布式缓存系统来实现。
• MVC：即Model，View和Controller。Model表明业务逻辑，View表示页面视图，Controller表示根据用户请 求，执行相应的业务逻辑，并选择适当的页面视图返回。用过ROR的同窗都知道，里面的router配置了什么样的URL和什么样的action相对应。相 应的，MVC的本质就是根据不一样的URL选择不一样的servlet来执行。只不过，结合了Intercepting Filter提供了强大的功能而已。
• IOC：至于为何须要IOC，笔者在这篇文章进行了讨论。究其本质实现，无非是反射+单例模式+Hash算法+字节码加强+ThreadLocal。前3者用来实现对象生命周期的管理，后2者用来支持AOP，声明式事务。
• ORM：这个词实际上放在这里介绍不太合适，可是笔者目前没想把它单独拉出章节来说。根据笔者的经验，ORM主要完成了类和表的映射，对象和一条 表数据记录的映射。其核心实现是经过jdbc获取数据库的meta信息，而后根据映射关系（这里能够经过COC（Conversion Over Configuration，约定优于配置），注解等技术来简化配置）来动态生成sql和返回数据库的执行结果。

SOA

网站架构的演进之路，从单一应用架构到垂直应用架构，分布式服务架构以及流动计算架构，愈来愈体现SOA框架的重要性。这里以优秀的开源实现dubbo为例，简单介绍下。

dubbo的功能介绍见服务治理过程，对dubbo架构详细介绍的有如何学习dubbo源代码和dubbo源代码阅读。

简而言之，就是使用了spring的schema的扩展机制，进而支持自定义dubbo标签；经过相似serviceload机制配置多个可选服务。经过jdk动态代理和Javassist，使服务调用透明化。结合ZooKeeper实现高可用元数据管理。

MQ

MQ（Message Queue，消息队列）使服务调用异步化，能够消除并发访问洪峰，提高网站响应速度。 在MQ实现中，笔者写过一篇介绍Kafka的学习笔记，详细介绍见Kafka/Metaq设计思想学习笔记，再也不多言。

CACHE

Cache就是将数据放到距离计算最近的地方，用来加快处理速度。一般对必定时间内的热点数据进行缓存。 
在使用缓存时，须要注意缓存预热和缓存穿透问题。

通常海量数据的缓存系统不会使用Java来实现，是由于Java有额外的对象大小开销以及GC压力。因此通常是用ANSI C来实现。目前用的比较火的是Redis，更多介绍请查看Redis资料汇总

STORAGE

在出现NOSQL以前，一统天下的是MySQL分库分表技术。结合相似TDDL等SQL agent技术，也可以执行相似join的操做。后来，就像忽如一晚上春风来，出现了不少NOSQL/分布式存储系统产品。

分布式存储系统是分布式系统中最复杂的一部分，相比较SOA,CACHE等框架，它须要解决的问题更加复杂。常见的问题以下：

• 数据分布 在多台服务器之间保证数据分布均匀，跨服务器如何读写
• 一致性 异常状况下如何保证副本一致性
• 容错 把发生故障当成常态来设计，作到检测是否发生故障并进行故障迁移
• 负载均衡 新增、移除服务器时如何负载均衡 数据迁移如何不影响已有服务
• 事务并发控制 如何实现分布式事务，如何实现多版本并发控制
• 压缩、解压缩 根据数据特色选择恰当算法，如何平衡时间和空间的关系。

当笔者阅读完《大规模分布式存储系统原理解析与架构实战》和google的两篇存储论文后，感受里面的实现细节太多了。若是要写的话，仍是后面单独列一片把。因此这里暂且略过。

其余

还有其余方面的知识，等后面积累再多些，再重点写吧，这里仅仅是索引下，读者能够自行略过。

• 配置数据、元数据管理系统：能够查看这篇ZooKeeper和Diamond有什么不一样
• 搜索系统：机器学习分析用户行为，结合搜索进行推荐排名。 各类大数据分析工具。
• 云计算：硬件虚拟化。创业公司能够购买云服务，避免固定资产开销，可能闲置， 购买，管理，安装费用 ，没法迅速购买等问题，属于浮动消费，相似开车和租车的区别，仅是租用服务。 云厂商在能源，制冷，运维成本，量大硬件定制，充分利用闲置资源具备优点。
• 鹰眼系统：日志规范化+打点+数据分析+树状展示，详细介绍能够参考 鹰眼下的淘宝-分布式调用跟踪系统介绍
• 系统运维： 目标是自动化运维。
  • 监控各类资源指标：
    • OS:（cpu，memory，disk（空间，读写次数））
    • 网络流量
    • 中间件： tomcat， jvm，
    • MQ:经过监控生产者，broker，消费者之间的队列状况，动态决定增长、减小消费者
    • 服务框架自省（运维监控） 依赖关系统计，前台系统访问路径，
  • 显示各类监控结果：Agent —》 Explorer ，Analyze，Visual，Dashboard，Share。
  • 预警，运维 自动、手工降级，系统问题自动排查甚至问题自动修复，
• 能源节省：能源消耗（CPU,机柜，水冷）
• 系统安全：涉及系统的方方面面，各类脚本，sql注入，0day等等。
• 版本开发、版本发布：开发环境，测试环境，支持开速发布，不用大的cycle，灰色发布，回滚降级流程，周边协调。 大众点评的有个关于开发环境搭建的，感兴趣的能够点击打造高效的单机开发环境。
• 数据中心：在《程序员》2014年第一期介绍里面，提到了阿里使用了ZONE的概念来解决横向扩展的问题。阿里主要是为了解决机房网络瓶颈和超大规模系统的伸缩性问题，把完成某一特定业务须要的系统、核心服务、数据库组合成一个业务单元。

 

zookeeper中Watcher和Notifications 李克华 2014-10-29 19:14 阅读:337 评论:0  

zookeeper适用场景：分布式锁实现 李克华 2014-10-29 19:10 阅读:3019 评论:0  

zookeeper适用场景：配置文件同步 李克华 2014-10-29 19:07 阅读:3036 评论:0  

zookeeper适用场景：如何竞选Master及代码实现 李克华 2014-10-29 19:01 阅读:361 评论:0  

Nginx反向代理关于端口的问题 李克华 2014-10-28 13:42 阅读:11718 评论:0  

软件架构设计的六大原则 李克华 2014-10-22 10:10 阅读:519 评论:1  

Memcached内存分配优化及使用问题 李克华 2014-10-17 17:58 阅读:256 评论:0  

Hadoop 2.0中单点故障解决方案总结 李克华 2014-10-14 10:16 阅读:238 评论:0  

快速理解Kafka分布式消息队列框架 李克华 2014-10-13 16:11 阅读:394 评论:0  

观nginx与lvs负载均衡的较量 李克华 2014-10-10 15:33 阅读:479 评论:1  

kafka入门：简介、使用场景、设计原理、主要配置及集群搭建（转） 李克华 2014-09-29 09:33 阅读:141276 评论:9  

hadoop data 相关开源项目（近期学习计划） 李克华 2014-09-16 21:13 阅读:192 评论:0  

Zabbix监控windows部署安装 李克华 2014-09-12 16:51 阅读:20441 评论:1  

Web基础架构：负载均衡和LVS 李克华 2014-06-19 16:02 阅读:13108 评论:3  

HAProxy + Keepalived + Flume 构建高性能高可用分布式日志系统 李克华 2014-06-19 15:57 阅读:738 评论:0  

开源日志系统比较：scribe、chukwa、kafka、flume 李克华 2014-06-19 15:56 阅读:395 评论:0  

大型互联网架构概述 李克华 2014-06-19 15:52 阅读:493 评论:0  

可扩展Web架构与分布式系统 李克华 2014-06-19 15:51 阅读:471 评论:0