如何解决与网络接口层安全性相关的问题

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

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

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

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

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

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

第三个是配置管理，它是用于代码级灰度发布和保证系统降级的一种敏锐工具. 第二个是无状态的. 接口层最重要的是无状态. 我们在电子商务网站上购物. 在此过程中，有很多状态. 例如，我浏览了哪些产品？为什么经常说接口层是无状态的？实际上，我们将状态从接口层剥离到了数据层. 例如，当用户在电子商务网站上购买多个产品时，在该界面无状态之后的步骤中，状态将放置在缓存中或中. 实际上，它不是无状态的. 仅在此过程中，我们才希望将一些有状态的东西提取到数据层. 第三，数据层比服务层需要更多的设计. 这是非常重要的经验. 对于服务层，您可以使用PHP编写，明天可以使用Java编写，但是如果您的数据结构开始变得不合理，则将来更改数据结构将花费您数倍的时间，而旧的数据格式将是新. 数据格式迁移会使您感到不舒服. 数据迁移既有工作量，也有时间跨度. 有些甚至需要半年以上的时间. 第四，物理结构和逻辑结构的映射. 在上一张图片中，我们看到了将二维划分为十二个间隔，每个间隔代表一个技术领域. 这可以视为我们的逻辑结构. 此外，无论背景团队或应用程序层开发团队如何，它通常分为几个垂直业务组以及一个基本技术架构组，这是从物理组织结构到逻辑技术架构的完美映射，团队的工作分工精细，有助于提高沟通和协作的效率.

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

实际上，每个人的日常工作都需要花更多的时间进行业务优化. 此图是微博信息流前几页的统计数据. 前三页占97％. 设计缓存时，我们仅存储最近的M个数据. 这里要强调的是，系统设计应基于用户的场景，越详细越好. 举个例子，每个人都会使用电子商务. 电子商务将在“双十一”期间开展全国性活动. 他们在设计时还将考虑场景. 一种是购物车. 我已经与相关开发人员讨论过. 购物在“双十一”之前，这辆车有大量用户访问，而这正不断向里加添加产品. 在双十一时，他不会在购物车中添加任何内容，但是会经常浏览购物车. 针对这种情况，应在事件发生前优化购物车的书写场景，并在事件发生后优化购物车的阅读场景. 您看到的微博的哪些部分已汇总？最右边是提要，该提要是所有由其微博组成的微博关注者. 在微博上，我们将按照时间顺序对所有关注者进行排序. 随着业务的发展，除了按时间顺序排列的微博和非按时间顺序排列的微博之外，还会有广告需求，添加一些广告以及用金钱购买的热门标题，流行的微博，即插即用. 分发控制，即，有关一些建议，我推荐一些相关朋友的微博，我推荐一些您可能没有读过的微博，并推荐其他类型的微博.

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

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