反复发生您当前的网络存在链路层劫持_您当前的网络存在链路层劫持_网络 双链路

在起初谈我对架构本质的理解之前，先探讨对现在科技论坛主题的个人看法，千万级规模的网站觉得数量级是相当大的，对这个数量级我们战略上 要重 视 它 ， 战术上又 要 藐 视 它。先举个实例感受一下千万级到底是什么数量级？现在更流行的优步(Uber)，从媒体曝光的信息看，它经常接单量平均在百万左右， 假如每天有10个小时的服务时间，平均QPS只有30左右。对于一个后台服务器，单机的平均QPS可以到达800-1000，单独看写的业务量很简单 。为什么我们既不能说轻视它？第一，我们看它的数据存储，每天一百万的话，一年数据量的体量是多少？其次，刚才说的订单量，每一个订单要推送给附近的司机、司机要并发抢单，后面业务场景的访问量往往是后者的上百倍，轻松就达到上亿级别了。 今天我想从架构的本质谈起之后，希望你们理解在做一些解构设计的之后，它的出发点以及它解决的难题是哪个。 架构，刚起初的解释是我从知乎上发现的。什么是架构？有人讲， 说架构并不是一 个很 悬 乎的 东西 ， 实际 上就是一个架子 ， 放一些 业务 和算法，跟我们的生活中的晾衣架很象。更具象一点，说架构其 实 是 对 我 们 重复性业务 的抽象和我 们 未来 业务 拓展的前瞻，强调过去的经验跟你对整个市场的预见。

我们要想做一个架构的话必须哪些能力？我认为更重要的是架构师一个最重要的素养就是你要有 战 略分解能力。这个怎么来看呢: 第一，你需要应有抽象的素养，抽象的素质更基本就是去重，去重在整个架构中表现在方方面面，从定义一个函数，到定义一个类，到提供的一个服务，以及模板，背后都是要去重增加能复用率。 第二， 分类能力。做软件必须做对象的降维，要定义对象的属性和技巧，做分布式平台的之后要做服务的拆分和模块化，要定义服务的接口和完善。 第三， 算法（性能），它的价值凸显在提高平台的性能，所有性能的提高，最终就会落到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已经过亿。我们系统有上百个微服务，每周会有两次的常规上线和不限次数的紧急上线。我们的挑战都一样，就是数据量，bigger and bigger，用户体验是faster and faster，业务是more and more。互联网业务更多是产品体验驱动， 技 术 在 产 品 体验上最有效的贡献 ， 就是你的性能 越来越好 。 每次增加加载一个页面的时间，都可以间接的减少这个页面上顾客的流失率。微博的科技挑战跟正交分解法解析架构 下面看一下 第三代的 架构 图 以及 我 们 怎么用正交分解法 阐 述。 我们可以看见我们从两个维度，横轴和纵轴可以看到。 一个 维 度 是 水平的 分层 拆分，第二从平行的维度会做拆分。水平的维度从接口层、到服务层至数据传输层。垂直怎么拆分，会用业务架构、技术架构、监控系统、服务治理等等来处理。

我相信到第二代的之后这些架构尚未有了业务架构跟科技架构的拆分。我们看一下， 接口层有feed、用户关系、通讯接口；服务层，SOA里有基层服务、原子服务跟组合服务，在微博我们只有原子服务跟组合服务。原子服务不依赖于任何其它服务，组合服务由几个原子服务跟自己的业务逻辑建立而成 ，资源层负责海量数据的传输（后面例子会具体讲）。技 术框架解决 独立于 业务 的海量高并发场景下的科技问题，由很多的科技组件共同建立而成 。在接口层，微博使用JERSY框架，帮助你做参数的解读，参数的验证，序列化和反序列化；资源层，主要是缓存、DB相关的各种组件，比如Cache组件和对象库模块。监 控系统和服 务 治理 ， 完成平台服务的像素级监控，对分布式平台做提前诊断、预警或者治理。包含了SLA规则的制订、服务监控、服务调用链监控、流量监控、错误异常监控、线上灰度发布上线系统、线上扩容缩容调度平台等。 下面我们讲一下常见的设计方法。 第一个，首先是平台架构三个利器： 一个， 我 们 RPC 服 务组 件 （这里不讲了）， 第二个，我们 消息中 间 件 。消息中间件起的作用：可以把两个模块之间的交互异步化，其次可以把不均匀请求流量输出为匀速的输出流量，所以说消息中间件 异步化 解耦 和流量削峰的利器。

第三个是配置管理，它是 代码级灰度发布并且 保障系统降级的利器。 第二个 ， 无状态 ， 接口 层 最重要的就是无状 态。我们在电商网站网购，在这个过程中这些状况下是有状态的，比如我浏览了这些商品，为什么你们既常说接口层是无状态的，其实我们把状态从接口层剥离至了数据层。像用户在电商网站网购，选了几件商品，到了那一步，接口无状态后，状态应么放在缓存中，要么放在中， 其 实 它并不是没有状 态 ， 只是在 这 个 过 程中我 们 要把一些有状 态 的 东 西抽离出来 到了数据层。 第三个， 数据 层 比服 务层 更需要 设计，这是一条非常重要的经验。对于服务层来说，可以拿PHP写，明天你可以拿JAVA来写，但是即使你的数据结构开始设计不合理，将来数据结构的颠覆会耗费你数倍的损失，老的数据格式向新的数据格式迁移会使你痛不欲生，既有工作量上的，又有数据迁移跨越的时间周期，有一些或者必须半年以上。 第四，物理结构与逻辑结构的映射，上一张图看到两个维度切成十二个区间，每个区间代表一个技术领域，这个可以看做我们的逻辑结构。另外，不论后台还是应用层的开发团队，一般还会分几个垂直的业务组加上一个基础科技架构组，这就是从物理组织构架到逻辑的科技架构的完美的映射，精细化团队分工，有利于提高沟通协作的效益 。

第五， www .sanhao.com 的访问过程，我们这个架构图里没有涉及到的，举个实例，比如当你在浏览器输入网址的之后，这个请求在接口层之前出现了哪些？首先会查看你本机DNS以及DNS服务，查找域名对应的IP地址，然后发送HTTP请求过去。这个请求首先会至前端的VIP地址（公网服务IP地址），VIP之后需要经过负载均衡器（Nginx服务器），之后才到你的应用接口层。在接口层之前出现了这样多事，可能有客户报一个问题的之后，你借助在接口层查日志根本发现不了难题，原因就是问题也许发生在前往接口层之前了。 第六，我们说分布式系统，它最后的难题会落在那里呢？前端时间有一个网友跟我争论的之后，说她们的平台遭遇了一个瓶颈， 查遍了CPU，内存，网络，存储，都没有问题。我说你再查一遍，因为最后你不论用上千台服务器还是上万台服务器，最终系统出难题的必定会落在某一台机（可能是叶子节点也或许是核心的节点），一定落在CPU、内存、存储和网络上，最后查下来问题出在一台服务器的网关带宽上。微博多级双机房缓存架构 接下来我们看一下微博的Feed多级缓存。我们做业务的之后，经常很少做业务分析，技术大会上的分享既都倾向技术架构。

其实你们更多的日常工作是必须耗费更多时间在业务优化上。这张图是统计微博的信息流前几页的访问比例，像前三页占了97%，在做缓存设计的之后，我们最多只存最近的M条数据。 这里提出的就是做平台设计 要基于用 户 的 场 景 ， 越细致越好 。举了一个例子，大家就会用电商，电商在双十一会做全国范围内的活动，他们做设计的之后也会考量场景的，一个就是购物车，我当时和相关开发讨论过，购物车是在感恩节之前用户的访问量非常大，就是不停地往里加商品。在真正到感恩节这天他不会往购物车加东西了，但是他会经常的浏览购物车。针对这个画面，活动之前重点设计改进购物车的写情景， 活动起初后优化购物车的读场景。 你看见的微博是由这些个别聚合而成的呢？最左边的是Feed，就是微博所有关注的人，他们的微博所组成的。微博我们会根据时间顺序把所有关注人的顺序做一个排序。随着业务的演进，除了跟时间序相关的微博也有非时间序的微博，就是会有广告的要求，增加一些广告，还有粉丝头条，就是拿钱买的，热门微博，都会插在其中。分发控制，就是说和一些推荐相关的，我推荐一些相关的好友的微博，我推荐一些你或许没有读过的微博，我推荐一些其它类型的微博。

当然对非时序的微博跟分发控制微博，实际会起多个并行的程序来调用，最后同步做统一的聚合。这里稍微分享一下， 从SNS社交领域来看，国内目前做的比较好的三个信息流： 微博 是 基于弱关系的媒体信息流 ； 朋友圈是基于 强 关系的信息流 ； 另外一个做的比 较 好的就是今日 头 条 ， 它并不是基于关系来建立信息流 ， 而是基于 兴趣跟相关性的个性化推荐 信息流 。 信息流的聚合，体现在这些众多的产品之中，除了SNS，电商里还有信息流的聚合的影子。比如搜索一个商品后回来的列表页，它的信息流基本由几个别组成：第一，打广告的；第二个，做一些推荐，热门的商品，其次，才是关键字相关的搜索结果。 信息流 开始的之后 很 简单 ， 但是到前期会 发现 ， 你的 这 个流 如何做控制分发 ， 非常复杂， 微博在今天一两年一直在做 这样 的工作。刚才我们是从业务上预测，那么技术上怎么解决高并发，高性能的问题？微博访问量很大的之后，底层存储是用MySQL，当然也会有其它的。对于查询请求量大的之后，大家了解一定有缓存，可以复用可重用的计算结果。可以看见，发一条微博，我有众多粉丝，他们就会来看我发的内容，所以 微博是很合适使用 缓 存 的平台，微博的读写比例基本在几十比一。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/tongxinshuyu/article-137523-1.html