七，数据采集与监控

　　文章大纲

　　1. 要考虑的问题

　　两个前端架构

　　三，应用层架构

　　四个服务层架构

　　V. 存储层架构

　　六. 后端架构

　　七，数据采集与监控

　　8. 安全架构

　　九，数据中心机房架构

　　10. 自动化的操作和维护

　　11. 参考文章

　　

　　1. 需要考虑的问题1.研发过程管理中的困难

　　（1）依赖性管理，每个模块对其他模块的依赖性难以管理；

　　（2）版本管理；

　　（3）部署管理（很难通过出色的云选择吸引用户）；

　　（4）模块组织（图书馆项目，源代码级别，无权限）.

　　（5）痛苦的构造和打包: 可能无法打包（无法安装2.x），合并代码已完成很长时间，并且编译和打包时间太长.

　　2. 建筑设计需要考虑情况

　　（1）业务分类，核心和非核心业务隔离

　　（2）多机房部署，流量分配，灾难恢复冗余，峰值响应冗余

　　（3）多源阅读库，失败后自动传输

　　（4）编写库主和备份，在短期失去服务容忍的情况下快速切换

　　（5）外部接口，故障转移或快速断开连接

　　6.Redis活动/备用，故障转移

　　7. 迁移大型表，MongoDB取代MySQL来存储消息记录

　　8. 改进消息传递模型

　　两个前端架构

　　前端是指用户在请求到达Web应用程序服务器之前通过的链接. 它通常不收录网站业务逻辑，也不处理动态内容.

　　1. 浏览器优化技术

　　不是优化浏览器，而是通过优化响应页面来加快浏览器页面的加载和显示. 通常使用的是页面缓存，合并HTTP以减少请求数量以及使用页面压缩.

　　2. CDN

　　内容分发网络部署在网络运营商的计算机室中. 通过将静态页面内容分发到离用户最近的CDN服务器，用户可以通过最短路径获得内容.

　　动态和静态分离，静态资源的独立部署

　　静态资源（例如JS，CSS和其他文件）部署在专用的服务器群集上，与Web应用程序动态内容服务分开，并使用专用的（第二级）域名.

　　3. 图片服务

　　图片未引用网站徽标，按钮图标等. 这些文件属于上述静态资源，应与JS和CSS一起部署. 这里的图片是指用户上传的图片，例如产品图片，用户头像等. 图片服务还适用于独立部署的图片服务器群集，并使用独立的（第二级）域名.

　　4. 反向代理

　　它部署在网站计算机室中，并在应用程序服务器，静态资源服务器和图像服务器之前提供页面缓存服务.

　　5. DNS

　　域名服务，将域名解析为IP地址，使用DNS来实现DNS负载平衡，并且配置CDN还需要修改DNS，以便将域名解析为指向CDN服务器.

　　三，应用层架构

　　应用层是处理网站主要业务逻辑的地方.

　　1. 开发框架

　　网站业务是多变的. 网站的大多数软件工程师都在加班以发展网站业务. 良好的开发框架至关重要. 一个数量众多的开发框架应该能够分离问题，以便艺术家和开发工程师可以做自己的事情并轻松协作. 同时，应内置一些安全策略以防止Web攻击.

　　2. 页面渲染

　　将分别开发和维护的动态内容和静态页面模板集成在一起，形成一个完整的页面，最终将其显示给用户.

　　3. 负载均衡

　　将多个应用程序服务器组成一个集群，并通过负载平衡技术将用户请求分发到不同的服务器，以应对大量用户同时访问时产生的高并发负载压力.

　　4. 会话管理

　　为了获得高度可用的应用程序服务器群集，通常将应用程序服务器设计为无状态的，并且不存储用户请求上下文信息. 但是，网站服务通常需要维护用户会话信息，并且需要一种特殊的机制来管理会话，以便在群集内甚至跨群集，应用程序服务器可以共享会话.

　　5. 静态动态页面

　　对于不经常访问和更新的动态页面，可以将它们设为静态，即生成静态页面，并使用静态页面优化方法来加速用户访问，例如反向代理，CDN，浏览器缓存Wait.

　　6. 业务分离

　　将复杂而庞大的业务拆分为多个独立开发，部署和维护的较小规模的产品，不仅降低了系统耦合的程度，而且还促进了数据库业务的划分. 按业务拆分关系数据库的技术难度相对较小，并且效果相对较好.

　　7. 虚拟服务器

　　将物理服务器虚拟化为多态虚拟服务器. 对于并发访问率较低的服务，使用较少的资源来构建高可用性的应用服务器集群会更加容易.

　　四个服务层架构

　　提供基本服务，呼叫应用程序层并完成网站业务.

　　1. 分布式消息传递

　　使用消息队列机制实现异步消息发送和业务与业务，业务与服务之间的低耦合业务关系.

　　2. 分布式服务

　　在网站上提供高性能，低耦合，易于使用，易于管理的分布式服务，并实现面向服务的体系结构（SOA）.

　　3. 分布式缓存

　　通过可伸缩的服务器群集提供*敏*感*词*的热点数据缓存服务是网站性能优化的重要手段.

　　4. 分布式配置

　　需要为系统操作配置许多参数. 如果需要修改这些参数，例如将新的缓存服务器添加到分布式缓存群集，则需要修改应用程序客户端的缓存服务器列表配置，然后重新启动应用程序服务器. 分布式配置在系统运行时提供动态配置推送服务，并在不重新启动服务器的情况下将配置更改实时推送到应用程序系统.

　　5. 业务分离

　　系统包括所有功能，例如登录，注册，参数传递，消息，日志和更新.

　　实际上，对于玩游戏的玩家来说，只有登录和注册以及参数发布才是真正相关的. 消息，日志和更新对于玩家玩游戏实际上不是必需的，也不是很重要的.

　　因此，业务分离的做法是将核心业务和非核心业务分为不同的系统，并通过接口调用这两个系统以相互访问.

　　这样做的优点是，假设非核心业务系统发生故障，则不会影响核心业务系统，因为它们是通过接口调用的，并且不会共享相同的资源.

　　6. 服务中心

　　服务中心类似于DNS，它实现了整个内部系统之间的服务调用调度功能. 服务中心是一个类似服务的名称系统.

　　例如，企业A要访问其他系统提供的企业. 首先，它不直接访问另一个系统，而是访问服务中心.

　　例如，如果我需要X服务，服务中心会告诉A: 您要访问Host1 + port1的xxx界面. 服务中心具有配置和状态报告. 根据某些状态，算法和配置，您可以选择最好的服务器来告知A业务.

　　然后，在收到服务A后，按照以下说明访问实际提供服务的机器，例如B系统中的Host1 + port1机器. 服务中心的角色类似于HTTP-DNS，它可以在内部系统出现故障时快速处理或切换.

　　假设系统B中的机器出现问题，我们可以自动或手动将其放入服务中心. 当A业务请求时，它不会再请求此有问题的计算机. 在上面，此计算机的故障不会影响A的业务.

　　7. 业务降级

　　整个系统分为核心业务系统和非核心业务系统. 在某些紧急情况下，例如非核心业务系统的重新启动，是没有办法，甚至数据库已损坏，这会影响核心业务系统.

　　这时可以访问该接口，但是响应时间非常慢，核心系统也很慢.

　　因此，在这种更为极端的情况下，我们可以手动发出降级指令以停止该非核心业务系统的功能. 停止并不会停止程序，而是停止接口或URL之一，并且核心系统在访问该程序时会收到500或503错误.

　　我们已经建立了一个特殊的降级系统，降级系统可以发出这些降级说明. 在正常情况下，降级系统会向非核心业务系统发布降级指令. 实际上，如果出现关键时刻，核心业务系统中的某些接口也可以降级.

　　换句话说，降级时，我们并没有降级整个系统或整个功能. 我们可以降级接口或URL. 通过牺牲非核心业务系统的功能，我们尽最大努力确保核心业务系统提供的业务.

　　该行业中有很多名称，例如有损服务和有损服务. 实际上，我们的服务也是有损的. 功能的丧失不是交通的损失.

　　8. 灾难恢复和降级

　　如果无法抵抗转移和电流限制，并且系统存在进一步的压力问题，我们必须为灾难恢复和降级做好准备.

　　容灾能力降级为机房容灾能力. 我们进行多中心机房，网络容灾，内部和外部网络容灾，应用程序容灾，分组和底层容器，最后确保基本服务正常.

　　网络和IDC降级

　　这是灾难容忍降级，这是网络的*敏*感*词*. 我们的ISP进入计算机房，核心交换机，机柜级交换机，它们是交换机级容灾和网络共享容灾.

　　业务降级

　　购物车结算页面的降级. 当订单太大时，如果扩展保修服务和预订服务不可用，则会直接保护主流级别，这会降低业务级别.

　　安全和电流限制

　　我们假设，当系统超过一定流量时，多余的流量将被直接拒绝，以保护后端服务. 这是当前的限制.

　　Web的当前限制基于PIN，而PIN基于IP加上PIN风险控制数据流限制. 这是基于业务逻辑，一天可以下达多少订单，并且基于此逻辑来限制流程. 频道可以通过App，PC，微信等进行分隔，也可以通过拆分和限制来分隔.

　　让我们讨论一下尖峰系统是如何产生的. 峰值系统是限流和分流的典型特征.

　　Seckill，假设在那一分钟内预订量为1500万，那么有那么多用户来抢手机，即一个产品，而流量直接定向到seckill系统.

　　穗系统来自Ngnix，并且存在各种限制，以至于我们将确定用户供应商或供应商必须刷新的数据. 该调用从通常访问的单个产品页面分支，不会影响主要流程.

　　根据IP，PIN，每个步骤如何进行，用户提交记录，每秒多少次，每分钟多少次等，一堆规则做出判断来限制流量. 最后，验证是否有约会，公用地址服务等，然后全部通过后转移到订单系统.

　　整个秒杀系统是典型的沙漏系统. 当流量流向后面时，实际上只剩下一小部分，只需要实际的写入流量即可接收订单.

　　订单提交服务提供两台单独的计算机供其使用，并且其后面的存储受到保护. 这两个机器最多可容纳数十万个，这是分流和电流限制.

　　促销和价格

　　促销中也有购买限制. 例如，前30个用户喜欢促销并发送代码. 此代码需要处理. 这是流量限制.

　　在促销转移中，需要从中提取，划分价格服务订单，单个产品页面搜索，手机微信，购物车结构，这是最实时的价格. 这样，便生成了分布. 此块中有一个存储分布，还有更多未列出的其他分布. 这只是一个*敏*感*词*.

　　这是我们的全部转移和当前限制. 根据以前的渠道，呼叫的数量，要做的事（相对于影响），转移和流量限制.

　　V. 存储层架构

　　为数据和文件提供持久性存储访问和管理服务.

　　1. 分布式文件

　　大多数需要存储在网站的在线业务中的文件都是相对较小的文件，例如图片，网页和视频，但是这些文件的数量非常大，并且通常会继续增加，并且需要具有更好可伸缩性的分布式文件. 系统.

　　2. 关系数据库

　　大多数主要业务都是基于关系数据库开发的，但是关系数据库对集群可伸缩性的支持较差. 通过将数据库访问的路由功能添加到应用程序的数据访问层，并根据业务配置将数据库访问路由到不同的物理数据库，可以实现对关系数据库的分布式访问.

　　3. NoSQL数据库

　　目前，各种NoSQL数据库层出不穷，每种数据库在内存管理，数据模型，集群分布式管理等方面都有优势. 但是，从社区活动的角度来看，HBase无疑是目前最好的数据库.

　　4. 数据同步

　　在支持全球数据共享的分布式数据库技术变得成熟之前，具有多个数据中心的网站必须在多个数据中心之间同步数据，以确保每个数据中心都有完整的数据. 实际上，为了减轻数据库的压力，将数据库的事务日志（或NoSQL写操作日志）同步到其他数据中心，并根据该日志重播数据以实现数据同步.

　　六. 后端架构

　　在Web应用程序中，除了处理用户的实时访问请求外，还需要处理一些后台非实时数据分析.

　　搜索引擎

　　即使网站内部的搜索引擎也需要进行增量和完整的数据更新，建立索引等. 这些操作会通过后台系统定期执行.

　　数据仓库

　　基于脱机数据，提供数据分析和数据挖掘服务.

　　推荐系统

　　社交网站和购物网站通过挖掘人与人之间以及人与产品之间的关系来发展潜在的人际关系和购物兴趣，并为用户提供个性化的推荐服务.

　　七，数据采集与监控

　　监控网站访问和系统运行，为网站运行决策和运维管理提供支持.

　　1. 浏览器数据采集

　　通过在网站页面中嵌入JS脚本来采集用户浏览器环境和操作记录，分析用户行为.

　　2. 服务器业务数据采集

　　服务器业务数据包括两种类型，一种是采集记录在服务器端的用户请求操作日志. 另一种是在应用程序运行时采集业务数据，例如待处理消息的数量.

　　3. 服务器性能数据采集

　　采集服务器性能数据，例如系统负载，内存使用情况，网卡流量等.

　　4. 系统监控

　　以图表形式显示上述采集的数据，以便运维人员可以监控网站的运行状态. 此步骤仅是系统监视. 一种更高级的方法是根据采集到的数据进行自动化操作和维护，自动处理系统异常并吸收自动化控制.

　　5. 系统警报

　　如果采集的数据超出正常情况的预设阈值，例如系统负载过高，则会通过电子邮件，短信，语音呼叫等方式发出警报信号，等待系统的干预. 工程师.

　　6. 360度监控

　　总体计划从上到下分为五个层: 业务层，应用程序服务层，接口调用层，基本组件层和基础结构层.

　　（1）业务层: 是基于这些管理，模型统计或分析的业务管理；

　　（2）应用程序服务层: 简而言之，这是我们url的访问情况；

　　（3）接口调用层: 它是我们自己系统对外部相关接口的访问，例如，系统A调用系统B的接口，并统计或监视系统A中系统B的接口调用，包括时间延迟，错误数量等；

　　（4）基本组件层: 实际上是我们使用的某些组件，包括MySQL等；

　　（5）基础结构层: 它是最底层，包括操作系统，网络，磁盘，IO设备.

　　整个监视是分层的. 当我们遇到问题时，将收录解决问题所需的所有关键信息.

　　8. 安全架构

　　保护网站免受攻击和敏感信息泄漏.

　　1. 网络攻击