有关如何购买分布式信息系统的问题

在我开始谈论对建筑本质的理解之前，让我先谈谈我对当今技术沙龙主题的个人见解. 数以千万计的站点感到数量级非常大. 对于这个数量级，我们必须从战略上注意它分布式计算实验教程，我将再次对其进行鄙视. 让我举一个例子，来体验一千万的数量级吗？优步现在非常受欢迎. 根据媒体发布的信息，平均每天需要处理大约一百万个订单. 如果每天有10个小时的服务，则平均QPS仅为30左右. 对于后台服务器，一台计算机的平均QPS可以达到800-1000，仅读取和写入的业务量就非常简单. 我们为什么不能鄙视它？首先，让我们看一下它的数据存储. 如果一天一百万，一年内数据量的大小是多少？其次，刚才提到的订单量，每个订单应推送给附近的驾驶员，驾驶员需要同时抓取订单. 以下业务场景的访问量通常是前者的数百倍，很容易超过数亿的访问量. 今天，我想谈谈建筑的本质. 我希望您了解一些起点和解决一些建筑设计时所要解决的问题. 我刚刚开始的结构，解释就是从我的知识中学到的. 什么是建筑？有人说建筑并不是一件很容易的事情. 实际上，它是一个架子. 放一些业务和算法，它与我们生活中的晾衣架非常相似. 更抽象地说，该架构实际上是我们重复业务的抽象，并且是我们未来业务扩展的前景，强调了过去的经验和您对整个行业的远见.

构建架构需要什么功能？我认为最重要的是，架构师最重要的能力是您具有分解策略的能力. 如何看待: 首先，您必须具有抽象能力. 抽象的最基本能力是重复数据删除，它反映在整个体系结构的各个方面，从定义功能，定义类，提供服务以及模板，都与提高可重用性有关. 第二，分类能力. 要制作软件，您需要解耦对象. 您需要定义对象的属性和方法. 当您是分布式系统时，您需要对服务进行拆分和模块化. 您必须定义服务的接口和规范. 第三，算法（性能），其价值体现在提高系统性能上. 所有性能的提高最终将落在CPU，内存，IO和网络的四个主要方面. PPT的此页面提供了一些示例，以更深入地了解常见技术背后的体系结构概念. 第一个示例，在分布式系统中，我们将做MySQL子库和表. 我们必须从不同的库和表中读取数据. 这种抽象的最直观方法是使用模板，因为大多数SQL语义是相同的. 除了路由到哪个库和哪个表之外，如果不使用代理中间件，则模板是最经济的方法. 其次，让我们看一下加速网络的CDN. 就速度而言，这是性能上的改进. 刚才我们还提到，从CPU，内存，IO和网络方面来看，CDN本质上是一种用于网络智能调度优化，而另一种是多级缓存优化.

第三个是看服务化. 如前所述，在转型过程中一定会为每个大型网站提供服务. 实际上，这是抽象和服务的分离. 第四是看消息队列. 从本质上讲，它仍然是分类的，但是它不是两个空白边界类，而是通过队列对两个不清楚的边界子系统进行了解构和异步处理. 新浪微博的整体架构是什么？接下来，让我们看一下微博的整体架构. 对于特定级别的系统，整个体系结构将变为三层，客户端包括WEB，Android和IOS. 然后将有一个接口层，它具有三个主要角色: 第一个角色是进行安全隔离，因为前端节点直接与用户交互，并且需要防止各种恶意攻击；第二个也充当流量控制众所周知，在2014年春节期间，微信红包每分钟有超过8亿个请求. 实际上，到其后台的请求数量仅为100,000（此处的数据可能不准确），其余的流量在接口层被阻止. 第三，我们看到PC和移动终端的要求不同，因此可以将它们拆分. 在界面层成为背景之后，您可以看到微博背景中包含三个主要块: 一个是平台服务，第二个是搜索，第三个是大数据. 进入后台的各种服务实际上是已处理的数据. 像平台的业务部门一样，它的工作是数据存储和读取，搜索的工作是数据检索，而大数据的工作是数据挖掘.

微博实际上与淘宝非常相似. 微博实际上与淘宝非常相似. 一般来说，第一代架构可以基本支持用户达到百万级，而第二代架构可以基本支持千万级别. 没有问题. 当业务规模达到1亿个级别时，就需要第三代架构. . 从LAMP架构到面向服务的架构，有几个地方非常困难. 首先，通过基于第一代的简单维修无法满足用户的快速增长，并且业务也无法停止. 这就是我们经常说的关于更换飞机发动机的说法. 两天前，我的一个朋友问我，当他在内部实施服务时，他完成了模块的服务，而其他部门却无法回答. 我建议在进行服务时，首先，它更倾向于名片，同时找到一个好的切入点. 无论是体系结构和服务的改进，业务方也应具有好处，例如提高性能或减少维护成本和升级过程应平稳，建议从原子服务开始，例如基本用户服务，基本短消息服务，基本的推送服务. 其次，可以进行无状态服务，这将在后面详细讨论，并且在数据量大之后需要数据分片，这将在后面描述. 第三代架构要解决的问题是用户和业务数量趋于稳定增长（相对于爆发期呈指数增长），更多地考虑了技术框架的稳定性，总体系统性能为改进，降低了成本，并改善和升级了系统监视.

大型网站的系统架构如何演变让我们通过数据看一下它所面临的挑战. PV处于10亿水平，QPS处于百万水平，数据量处于1000亿水平. 我们的可用性是SLA需要四个9，并且接口响应不能超过150毫秒. 线路上的所有故障必须在5分钟内解决. 如果不花5分钟怎么办？这将影响您的年终绩效评估. 2015年，微博DAU突破1亿. 我们的系统有数百个微服务，每周将有两次常规和无限次紧急. 我们面临的挑战是相同的，即数据量越来越大，用户体验越来越快，业务越来越多. 互联网业务更受产品体验的驱动，技术对产品体验的最有效贡献是您的性能越来越好. 每次减少加载页面的时间，都可以间接降低此页面上用户的流失率. 微博的技术挑战和正交分解方法的解析体系结构让我们看一下第三代的体系以及如何使用正交分解方法进行解释. 我们可以看到我们可以从两个维度看到，水平轴和垂直轴. 一维是水平分层拆分，第二维是从垂直维度拆分. 水平维度从接口层到服务层再到数据存储层. 如何垂直分割将由业务架构，技术架构，监视平台，服务治理等来处理.

我相信，到第二代，许多架构已经与业务架构和技术架构分离. 让我们看一下，界面层具有提要，用户关系，通讯界面；服务层，SOA具有基本服务，原子服务和组合服务，而在微博中，我们只有原子服务和组合服务. 原子服务不依赖于任何其他服务. 组合服务由几个原子服务及其自己的业务逻辑构成. 资源层负责海量数据的存储（稍后会详细介绍）. 技术框架解决了许多独立于业务的高并发场景中的技术问题，并且由许多技术组件构成. 在接口层，微博使用JERSY框架来帮助您进行参数分析，参数验证，序列化和反序列化. 资源层主要是与缓存和有关的各种组件，例如缓存组件和对象库组件. 监督平台和服务治理，对系统服务进行完整的像素级监视，以及对分布式系统的早期诊断，预警和治理. 它包括SLA规则的制定，服务监视，服务呼叫链监视，流量监视，错误异常监视，灰度发布和系统以及扩展和收缩调度系统. 下面我们讨论常见的设计原则. 第一个是系统架构的三大武器: 一个是我们的RPC服务组件（此处未提及），第二个是我们的消息中间件. 消息中间件的作用: 两个模块之间的交互可以是异步的，其次，不均匀的请求流量可以作为统一的输出流量输出，因此消息中间件是异步解耦和流量峰值的利器.

第三个是配置管理，它是代码级灰度发布和系统降级保护的武器. 第二是无国籍. 接口层最重要的是无状态. 我们在电子商务网站上购物. 在此过程中，有很多情况是有状态的，例如我浏览了哪些产品. 人们为什么经常说接口层是无状态的？实际上，我们将状态从接口层剥离到了数据层. 就像用户在电子商务网站上购物并选择一些产品一样，在此步骤中，在界面变为无状态之后，状态将放置在缓存中或中. 实际上，它不是无状态的，但是在此过程中，我们希望将一些有状态的东西提取到数据层. 第三，数据层比服务层需要更多的设计. 这是非常重要的经验. 对于服务层，您可以用PHP编写它，明天可以用JAVA编写它，但是如果您的数据结构开始变得不合理，则更改数据结构将在未来花费您数倍的时间，而旧的数据格式将是新的. 数据格式迁移会让您不满意，无论是工作量还是数据迁移所花费的时间，有些迁移可能要花半年以上的时间. 第四，物理结构与逻辑结构之间的映射. 在上一张图片中，我们看到了二维被切成十二个间隔. 每个间隔代表一个技术领域. 这可以视为我们的逻辑结构. 此外，无论背景或应用程序层如何，开发团队通常都会分为几个垂直业务组以及一个基本技术架构组. 这是从物理组织结构到逻辑技术体系结构的完美映射. 帮助提高沟通和协作的效率.

第五，www.sanhao.com的访问过程不涉及我们的体系，例如，当您在浏览器中输入URL时，接口层之前的请求发生了什么？首先，它将检查您的本地DNS和DNS服务，找到与域名对应的IP地址，然后向过去发送HTTP请求. 该请求将首先转到前端VIP地址（公共网络服务IP地址），然后VIP将通过负载均衡器（Nginx服务器），然后到达您的应用程序接口层. 接口层之前发生了很多事情. 当用户报告问题时，您无法通过在接口层检查日志来找到问题. 原因是问题可能在到达接口层之前发生. 第六，当我们谈论分布式系统时，其最终瓶颈将落在哪里？当网民在前端时间与我交谈时，他们说他们的系统遇到瓶颈并搜索了CPU，内存，网络和存储，这没有问题. 我说您再次检查一下，因为最后，无论您使用数千台服务器还是数万台服务器，系统的瓶颈最终都将落在特定的计算机上（它可能是叶节点或核心节点） ）. 在CPU，内存，存储和网络上，终于在服务器的网卡带宽上发现了问题. 微博多级双机房缓存体系结构接下来，让我们看一下微博的提要多级缓存. 在开展业务时，我们很少进行业务分析，并且技术会议上的共享偏向于技术体系结构.

实际上，每个人的更多日常工作需要花更多的时间进行业务优化. 此图显示了访问微博信息流的前几页的比例. 前三页占97％. 设计缓存时，我们只能保存最新的M数据. 这里的重点是系统设计应基于用户的场景，越详细越好. 举个例子，每个人都会使用电子商务. 电子商务将在重阳节期间在全国范围内开展活动. 他们在设计时还将考虑场景. 一种是购物车. 我曾经与相关开发人员讨论过. 购物在“双十一”之前，该车的用户访问量非常大，只是为了增加商品. 他不会在“双十一”那天向购物车添加任何内容，但会经常浏览购物车. 响应于这种情况，重点是在事件之前优化购物车编写方案，并在事件开始之后优化购物车阅读方案. 您看到的微博的哪些部分已汇总？最右端是Feed，由所有关注微博及其微博的人组成. 在微博上，我们将按照时间顺序对所有跟随的人进行排序. 随着业务的发展，除了按时间顺序排列的微博和非按时间顺序排列的微博之外，还会有广告需求，添加一些广告和粉丝头条，即用钱购买，流行的微博会插入它. 分发控制，即与一些建议相关的建议，我建议一些相关朋友的微博客，我建议一些您可能没有阅读的微博客，以及我建议一些其他类型的微博客.

当然，对于非顺序微博和分发控制微博，实际上将读取多个并行程序，最后将同时进行统一聚合. 让我们在这里分享一些. 从SNS社会领域的角度来看，目前在中国表现良好的三个信息流是: 微博是一种基于薄弱关系的媒体信息流；朋友圈是基于牢固关系的信息流；另一个比较完成了. 好消息是今天的头条新闻. 它不是基于关系构建信息流，而是基于兴趣和相关性来个性化推荐信息流. 信息流的聚合反映在许多产品中. 除了SNS，电子商务中信息流的聚合也存在阴影. 例如，搜索产品后出现的列表页面，其信息流基本上由几部分组成: 第一，做广告；第二，做广告. 第二，提出一些建议，热门产品，第二，与关键字相关的搜索结果. 信息流在开始时非常简单，但是在后期，将发现如何控制信息流的分布非常复杂. 微博在过去一两年中一直在做这样的工作. 刚才我们从业务上进行了分析，那么如何从技术上解决高并发，高性能的问题呢？当微博流量很大时，底层存储是一个MySQL，当然还有其他. 当查询请求的数量很大时，每个人都知道必须有一个缓存，该缓存可以重用可重用的计算结果. 如您所见，当我发布微博时，我有很多粉丝，他们都看着我发布的内容，因此微博是最适合使用缓存的系统. 微博的读写比例基本上是数十比一.

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