千万级规模高性能高并发的网络架构经验分享Word文档格式.docx

千万级规模高性能高并发的网络架构经验分享Word文档格式.docx

《千万级规模高性能高并发的网络架构经验分享Word文档格式.docx》由会员分享，可在线阅读，更多相关《千万级规模高性能高并发的网络架构经验分享Word文档格式.docx（15页珍藏版）》请在冰豆网上搜索。

架构，刚开始的解释是我从知乎上看到的。

什么是架构？

有人讲， 

说架构并不是一个很悬乎的东西，实际上就是一个架子，放一些业务和算法，跟我们的生活中的晾衣架很像。

更抽象一点，说架构其实是对我们重复性业务的抽象和我们未来业务拓展的前瞻，强调过去的经验和你对整个行业的预见。

我们要想做一个架构的话需要哪些能力？

我觉得最重要的是架构师一个最重要的能力就是你要有战略分解能力。

这个怎么来看呢:

∙第一，你必须要有抽象的能力，抽象的能力最基本就是去重，去重在整个架构中体现在方方面面，从定义一个函数，到定义一个类，到提供的一个服务，以及模板，背后都是要去重提高可复用率。

∙第二， 

分类能力。

做软件需要做对象的解耦，要定义对象的属性和方法，做分布式系统的时候要做服务的拆分和模块化，要定义服务的接口和规范。

∙第三， 

算法（性能），它的价值体现在提升系统的性能，所有性能的提升，最终都会落到CPU，内存，IO和网络这4大块上。

这一页PPT举了一些例子来更深入的理解常见技术背后的架构理念。

∙第一个例子，在分布式系统我们会做MySQL分库分表，我们要从不同的库和表中读取数据，这样的抽象最直观就是使用模板，因为绝大多数SQL语义是相同的，除了路由到哪个库哪个表，如果不使用Proxy中间件，模板就是性价比最高的方法。

∙第二看一下加速网络的CDN，它是做速度方面的性能提升，刚才我们也提到从CPU、内存、IO、网络四个方面来考虑，CDN本质上一个是做网络智能调度优化，另一个是多级缓存优化。

∙第三个看一下服务化，刚才已经提到了，各个大网站转型过程中一定会做服务化，其实它就是做抽象和做服务的拆分。

第四个看一下消息队列，本质上还是做分类，只不过不是两个边际清晰的类，而是把两个边际不清晰的子系统通过队列解构并且异步化。

新浪微博整体架构是什么样的

接下我们看一下微博整体架构，到一定量级的系统整个架构都会变成三层，客户端包括WEB、安卓和IOS，这里就不说了。

接着还都会有一个接口层，有三个主要作用：

∙第一个作用，要做安全隔离，因为前端节点都是直接和用户交互，需要防范各种恶意攻击；

∙第二个还充当着一个流量控制的作用，大家知道，在2014年春节的时候，微信红包，每分钟8亿多次的请求，其实真正到它后台的请求量，只有十万左右的数量级（这里的数据可能不准），剩余的流量在接口层就被挡住了；

∙第三，我们看对PC端和移动端的需求不一样的，所以我们可以进行拆分。

接口层之后是后台，可以看到微博后台有三大块：

∙一个是平台服务，

∙第二，搜索，

∙第三，大数据。

到了后台的各种服务其实都是处理的数据。

像平台的业务部门，做的就是数据存储和读取，对搜索来说做的是数据的检索，对大数据来说是做的数据的挖掘。

微博其实和淘宝是很类似

微博其实和淘宝是很类似的。

一般来说，第一代架构，基本上能支撑到用户到百万级别，到第二代架构基本能支撑到千万级别都没什么问题，当业务规模到亿级别时，需要第三代的架构。

从LAMP的架构到面向服务的架构，有几个地方是非常难的，首先不可能在第一代基础上通过简单的修修补补满足用户量快速增长的，同时线上业务又不能停，这是我们常说的在飞机上换引擎的问题。

前两天我有一个朋友问我，说他在内部推行服务化的时候，把一个模块服务化做完了，其他部门就是不接。

我建议在做服务化的时候，首先更多是偏向业务的梳理，同时要找准一个很好的切入点，既有架构和服务化上的提升，业务方也要有收益，比如提升性能或者降低维护成本同时升级过程要平滑，建议开始从原子化服务切入，比如基础的用户服务，基础的短消息服务，基础的推送服务。

第二，就是可以做无状态服务，后面会详细讲，还有数据量大了后需要做数据Sharding，后面会将。

第三代架构要解决的问题，就是用户量和业务趋于稳步增加（相对爆发期的指数级增长），更多考虑技术框架的稳定性，提升系统整体的性能，降低成本，还有对整个系统监控的完善和升级。

大型网站的系统架构是如何演变的

我们通过通过数据看一下它的挑战，PV是在10亿级别，QPS在百万，数据量在千亿级别。

我们可用性，就是SLA要求4个9，接口响应最多不能超过150毫秒，线上所有的故障必须得在5分钟内解决完。

如果说5分钟没处理呢？

那会影响你年终的绩效考核。

2015年微博DAU已经过亿。

我们系统有上百个微服务，每周会有两次的常规上线和不限次数的紧急上线。

我们的挑战都一样，就是数据量，biggerandbigger，用户体验是fasterandfaster，业务是moreandmore。

互联网业务更多是产品体验驱动，技术在产品体验上最有效的贡献，就是你的性能越来越好。

每次降低加载一个页面的时间，都可以间接的降低这个页面上用户的流失率。

微博的技术挑战和正交分解法解析架构

下面看一下第三代的架构图以及我们怎么用正交分解法阐述。

我们可以看到我们从两个维度，横轴和纵轴可以看到。

一个维度是水平的分层拆分，第二从垂直的维度会做拆分。

水平的维度从接口层、到服务层到数据存储层。

垂直怎么拆分，会用业务架构、技术架构、监控平台、服务治理等等来处理。

我相信到第二代的时候很多架构已

经有了业务架构和技术架构的拆分。

我们看一下，接口层有feed、用户关系、通讯接口；

服务层，SOA里有基层服务、原子服务和组合服务，在微博我们只有原子服务和组合服务。

原子服务不依赖于任何其他服务，组合服务由几个原子服务和自己的业务逻辑构建而成，资源层负责海量数据的存储（后面例子会详细讲）。

技术框架解决独立于业务的海量高并发场景下的技术难题，由众多的技术组件共同构建而成。

在接口层，微博使用JERSY框架，帮助你做参数的解析，参数的验证，序列化和反序列化；

资源层，主要是缓存、DB相关的各类组件，比如Cache组件和对象库组件。

监控平台和服务治理，完成系统服务的像素级监控，对分布式系统做提前诊断、预警以及治理。

包含了SLA规则的制定、服务监控、服务调用链监控、流量监控、错误异常监控、线上灰度发布上线系统、线上扩容缩容调度系统等。

下面我们讲一下常见的设计原则。

∙第一个，首先是系统架构三个利器：

∙一个，我们RPC服务组件（这里不讲了），

∙第二个，我们消息中间件。

消息中间件起的作用：

可以把两个模块之间的交互异步化，其次可以把不均匀请求流量输出为匀速的输出流量，所以说消息中间件异步化解耦和流量削峰的利器。

∙第三个是配置管理，它是代码级灰度发布以及保障系统降级的利器。

∙第二个，无状态，接口层最重要的就是无状态。

我们在电商网站购物，在这个过程中很多情况下是有状态的，比如我浏览了哪些商品，为什么大家又常说接口层是无状态的，其实我们把状态从接口层剥离到了数据层。

像用户在电商网站购物，选了几件商品，到了哪一步，接口无状态后，状态要么放在缓存中，要么放在数据库中，其实它并不是没有状态，只是在这个过程中我们要把一些有状态的东西抽离出来到了数据层。

∙第三个，数据层比服务层更需要设计，这是一条非常重要的经验。

对于服务层来说，可以拿PHP写，明天你可以拿JAVA来写，但是如果你的数据结构开始设计不合理，将来数据结构的改变会花费你数倍的代价，老的数据格式向新的数据格式迁移会让你痛不欲生，既有工作量上的，又有数据迁移跨越的时间周期，有一些甚至需要半年以上。

∙第四，物理结构与逻辑结构的映射，上一张图看到两个维度切成十二个区间，每个区间代表一个技术领域，这个可以看做我们的逻辑结构。

另外，不论后台还是应用层的开发团队，一般都会分几个垂直的业务组加上一个基础技术架构组，这就是从物理组织架构到逻辑的技术架构的完美的映射，精细化团队分工，有利于提高沟通协作的效率。

∙第五，的访问过程，我们这个架构图里没有涉及到的，举个例子，比如当你在浏览器输入www.sanhao网址的时候，这个请求在接口层之前发生了什么？

首先会查看你本机DNS以及DNS服务，查找域名对应的IP地址，然后发送HTTP请求过去。

这个请求首先会到前端的VIP地址（公网服务IP地址），VIP之后还要经过负载均衡器（Nginx服务器），之后才到你的应用接口层。

在接口层之前发生了这么多事，可能有用户报一个问题的时候，你通过在接口层查日志根本发现不了问题，原因就是问题可能发生在到达接口层之前了。

∙第六，我们说分布式系统，它最终的瓶颈会落在哪里呢？

前端时间有一个网友跟我讨论的时候，说他们的系统遇到了一个瓶颈，查遍了CPU，内存，网络，存储，都没有问题。

我说你再查一遍，因为最终你不论用上千台服务器还是上万台服务器，最终系统出瓶颈的一定会落在某一台机（可能是叶子节点也可能是核心的节点），一定落在CPU、内存、存储和网络上，最后查出来问题出在一台服务器的网卡带宽上。

微博多级双机房缓存架构

接下来我们看一下微博的Feed多级缓存。

我们做业务的时候，经常很少做业务分析，技术大会上的分享又都偏向技术架构。

其实大家更多的日常工作是需要花费更多时间在业务优化上。

这张图是统计微博的信息流前几页的访问比例，像前三页占了97%，在做缓存设计的时候，我们最多只存最近的M条数据。

这里强调的就是做系统设计要基于用户的场景，越细致越好。

举了一个例子，大家都会用电商，电商在双十一会做全国范围内的活动，他们做设计的时候也会考虑场景的，一个就是购物车，我曾经跟相关开发讨论过，购物车是在双十一之前用户的访问量非常大，就是不停地往里加商品。

在真正到双十一那天他不会往购物车加东西了，但是他会频繁的浏览购物车。

针对这个场景，活动之前重点设计优化购物车的写场景，活动开始后优化购物车的读场景。

你看到的微博是由哪些部分聚合而成的呢？

最右边的是Feed，就是微博所有关注的人，他们的微博所组成的。

微博我们会按照时间顺序把所有关注人的顺序做一个排序。

随着业务的发展，除了跟时间序相关的微博还有非时间序的微博，就是会有广告的要求，增加一些广告，还有粉丝头条，就是拿钱买的，热门微博，都会插在其中。

分发控制，就是说和一些推荐相关的，我推荐一些相关的好友的微博，我推荐一些你可能没有读过的微博，我推荐一些其他类型的微博。

当然对非时序的微博和分发控制微博，实际会起多个并行的程序来读取，最后同步做统一的聚合。

这里稍微分享一下，从SNS社交领域来看，国内现在做的比较好的三个信息流：

∙微博是基于弱关系的媒体信息流；

∙朋友圈是基于强关系的信息流；

∙另外一个做的比较好的就是今日头条，它并不是基于关系来构建信息流，而是基于兴趣和相关