XIAOSUO 记录个人学习的足迹

摘要：高并发系统架构常用案例 通用场景 日用户流量大，但是比较分散，偶尔会有用户高聚的情况； 解决思路 通过服务器架构和代码分流，系统架构设计保证它能够同时并行处理很多请求 场景特征 高并发相关常用的一些指标有响应时间（Response Time），吞吐量（Throughput），每秒查询率 QPS（Query Per Second）,每秒事务处理量(TPS),并发用户数等 测试模拟工具 Apache Jmeter 2.Visual Studio性能负载测试 3.Microsoft Web Application Stress Tool 分布式 分布式应用和服务,将分层或者分割后的业务分布式部署，独立的应用服务器，数据库，缓存服务器 当业务达到一定用户量的时候，再进行服务器均衡负载，数据库，缓存主从集群 分布式静态资源，比如：静态资源上传cdn 分布式计算，比如：使用hadoop进行大数据的分布式计算 分布式数据和存储,比如：各分布节点根据哈希算法或其他算法分散存储数据。 缓存 分析:高并发业务接口多数都是进行业务数据的查询，如：商品列表，商品信息，用户信息，红包信息等，这些数据都是不会经常变化，并且持久化在数据库中. 高并发的情况下直接连接从库做查询操作，多台从库服务器也抗不住这么大量的连接请求数（前面说过，单台数据库服务器允许的最大连接数量是有限的）。 结论:缓存将是一个不错的选择。浪费内存。 异步 分析:在高并发业务中如果涉及到数据库操作，主要压力都是在数据库服务器上面，虽然使用主从分离，但是数据库操作都是在主库上操作，单台数据库服务器连接池允许的最大连接数量是有限的 。当连接数量达到最大值的时候，其他需要连接数据操作的请求就需要等待有空闲的连接，这样高并发的时候很多请求就会出现connection time out 的情况 。 结论:异步将是一个不错的选择 分层/隔 1.分层，将系统在横向维度上切分成几个部分，每个部门负责一部分相对简单并比较单一的职责，然后通过上层对下层的依赖和调度组成一个完整的系统. 2.分隔，在纵向方面对业务进行切分，将一块相对复杂的业务分割成不同的模块单元. 3.包装成高内聚低耦合的模块不仅有助于软件的开发维护，也便于不同模块的分布式部署，提高网站的并发处理能力和功能扩展. 比如用户中心可以分割成：账户信息模块，订单模块，充…… 阅读全文

摘要：参考 什么是负载均衡--阿里云 反向代理 内容服务器的替身 如果内容服务器具有必须保持安全的敏感信息，如信用卡号数据库，可在防火墙外部设置一个代理服务器作为内容服务器的替身。 当外部客户机尝试访问内容服务器时，会将其送到代理服务器。 实际内容位于内容服务器上，在防火墙内部受到安全保护。 代理服务器位于防火墙外部，在客户机看来就像是内容服务器。 代理服务器成为安全数据库和可能的恶意攻击之间又一道屏障。 即便这道屏障打破，充其量也仅限于访问单个事务中所涉及的信息。 未经授权的用户无法访问到真正的内容服务器，因为防火墙通路只允许代理服务器有权进行访问。 内容服务器的负载均衡器 可以在一个组织内使用多个代理服务器来平衡各 Web 服务器间的网络负载。 在此模型中，可以利用代理服务器的高速缓存特性，创建一个用于负载平衡的服务器池。 对于客户机发往真正服务器的请求，代理服务器座位中间调停者，将所请求的文档存入高速缓存。 如果有不止一个代理服务器，DNS 采用“循环复用法”选择其 IP 地址，随机地为请求选择路由。 即便是同一个 URL发出请求，所采取的路由每次都可能经过不同的代理服务器。 特征： 内容服务器可以处理更高的负载，并且比其独自工作时更有效率。 适用于处理高用量内容服务器的请求 负载均衡 四层负载均衡 四层负载均衡工作在 OSI 模型的传输层，由于在传输层，只有 TCP/UDP 协议，这两种协议中除了包含源 IP、目标 IP 以外，还包含源端口号及目的端口号。 四层负载均衡服务器在接受到客户端请求后，以后通过修改数据包的地址信息（ IP+端口号 ）将流量转发到应用服务器 七层负载均衡 七层负载均衡工作在 OSI 模型的应用层，应用层协议较多，常用 HTTP、Radius、DNS 等。 七层负载就可以基于这些协议来负载。 这些应用层协议中会包含很多有意义的内容。 LVS（Linux Virtual Server） 也就是 Linux 虚拟服务器，是一个由章文嵩博士发起的自由软件项目。 使用 LVS 技术要达到的目标是：通过 LVS 提供的负载均衡技术和 Linux 操作系统实现一个高性能、高可用的服务器群集，它具有良好可靠性、可扩展性和可操作性。从而以低廉的成本实现最优的服务性能。 SLB 阿里云当前提供四层和七层的负载均衡服务。 四层采用开源软件L…… 阅读全文

摘要：高并发高可用角度架构演进 单机应用(WebSite) 渐渐的随着用户量的增加， 问题：一台服务器已经不够用了，服务器不稳定。挑战：高可用/高并发。 解决方式：于是我们将准备两台服务器搭成集群 简单集群(WebSite) 搭完集群之后，假如原来十个用户访问一台服务器,现在平均开，五个人访问上面的服务器，五个人访问另一个服务器。 用户的体验就会稍微好一点。 好处：简单高可用,假如其中一台服务器挂了，是不影响用户访问的，因为用户可以访问另一台好的服务器 问题：这样做有一个局限性，就是同时存在两个服务器，就会同时存在两个外网IP/域名 。 解决方式：于是我们增加了一个代理服务器,用户不需要记住两个服务器的IP或域名了，只要记住一台(代理服务器)IP就可以 负载均衡集群(WebSite) 增加代理服务器后，用户不需要记住两个服务器的IP或域名了，只要记住一台(代理服务器)IP就可以了。由代理服务器来负责分发用户是访问服务器A还是访问服务器B。用户具体是访问服务器A还是访问服务器B，我们可以通过nginx里面的权重设置来决定的。 好处：服务器高可用,户不需要记住两个服务器的IP或域名了，只要记住一台(代理服务器)IP就可以 问题：这样做不少局限性，数据的存储问题，服务器缺少角色分工，如磁盘损坏，数据是不安全的。 解决方式：于是这里我们使用了JAVA的MVC设计思想，我们将数据进行了抽取，服务器A和服务器B仅负责动态代理的分发，而不负责数据的存储，具体的数据放到数据服务器当中，数据库分离 MVC集群(WebSite) 增加代理服务器后，用户不需要记住两个服务器的IP或域名了，只要记住一台(代理服务器)IP就可以了。由代理服务器来负责分发用户是访问服务器A还是访问服务器B。用户具体是访问服务器A还是访问服务器B，我们可以通过nginx里面的权重设置来决定的。 好处：服务器高可用,户不需要记住两个服务器的IP或域名了，只要记住一台(代理服务器)IP就可以 问题：用户通过代理服务器分发到应用服务器，而应用服务器负责从数据库服务器进行数据的读取和写入。 解决方式：这里是关系型数据库，是遵循原子性、一致性、隔离性、持久性四大特性的；这时候是业务层分离的，即主服务器负责写，从服务器负责读，这就是数据的一致性和主从库读写分离。 数据库集群(DataBase) 用户通过代理服务器分发…… 阅读全文

摘要：持续发布/部署需求 持续部署和持续发布[CI/CD]： 复杂软件架构，往往带来更多的地面分层，更多的软件节点。系统的节点发布就会变得很麻烦。特别微服务 系统得持续发布，持续部署就是为了解决这些问题 持续集成： 强调开发人员提交了新代码之后，立刻进行构建、（单元）测试,根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起 持续交付： 是在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境(类生产环境)中。比如，我们完成单元测试后，可以把代码部署到连接数据库的Staging环境中更多的测试 持续集成 持续集成(Continuous Integration, 持续集成) 持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。 常用的工具：Hudson和Jenkins 持续部署 持续部署(Continuous Delivery，持续交付) 在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境(类生产环境)中。比如，我们完成单元测试后，可以把代码部署到连接数据库的Staging环境中更多的测试。如果代码没有问题，可以继续手动部署到生产环境。 Jenkins实现CD： https://blog.csdn.net/xiangnan10/article/details/80332866?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecasedepth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase 自动化测试需求 复杂得软件架构，如：PAAS，SAAS，IAAS。过多得分层带来自动化部署，往往也带来自动化测试的需求。 对于自动化，用代码来代替手工，软件测试就是在预设条件下运行系统或应用程序，评估运行结果，预先条件应包括正常条件和异常条件。 Selenium 架构图 自动化运维需求 解决中小形的架构问题： 1.开发人员兼职完成，监控…… 阅读全文

摘要：常见的高可用/并发场景带来挑战 问题：高可用和架构安全的关系 常见的架构安全问题 SQL注入 SQL注入（SQLi）是一种注入攻击，，可以执行恶意SQL语句。它通过将任意SQL代码插入数据库查询，使攻击者能够完全控制Web应用程序后面的数据库服务器。攻击者可以使用SQL注入漏洞绕过应用程序安全措施；可以绕过网页或Web应用程序的身份验证和授权，并检索整个SQL数据库的内容；还可以使用SQL注入来添加，修改和删除数据库中的记录。 带内注入 常见的tsql拼接或UNION ALL 推理SQL注入：非为了显示数据，根据用户行为线索，尝试SQLi攻击途径 带外注入/二阶注入：注入SQL语句，结合用户的行为习惯，进行数据库针对性攻击 csrf(跨站请求伪造)攻击 CSRF（Cross-site request forgery）：跨站请求伪造。利用用户对网站的信任 方法一： Token 验证：（1）服务器发送给客户端一个token；（2）客户端提交的表单中带着这个token。（3）如果这个 token 不合法，那么服务器拒绝这个请求。 方法二：隐藏令牌：把 token 隐藏在 http 的 head头中。 方法三： Referer 验证：Referer 指的是页面请求来源。意思是，只接受本站的请求，服务器才做响应；如果不是，就拦截。 xss(跨站脚本)攻击 不需要你做任何的登录认证，它会通过合法的操作（比如在url中输入、在评论框中输入），向你的页面注入脚本（可能是js、hmtl代码块等） 盗用Cookie破坏页面的正常结构，插入广告等恶意内容D-doss攻击 是向网站 注入 JS代码，然后执行 JS 里的代码，达到篡改网站的内容目的，eg： XSS盗取Cooike 文件上传漏洞防御 大致思路： ①文件上传的目录设置为不可执行 ②判断文件类型 ③使用随机数改写文件名和文件路径 ④单独设置文件服务器的域名 ⑥在客户端和服务器端对用户上传的文件名和文件路径等项目进行双重验证 ⑦服务器端添加白名单过滤 ⑧对%00截断符进行检测 ⑨对HTTP包头的content-type也和上传文件的大小进行检查 路径遍历攻击防御 最有效的办法就是权限控制，谨慎处理传向文件系统API的参数，净化数据：对用户传过来的文件名参数进行硬编码或统一编码，对文件类型进行白名单控制，对包含恶意字符或者…… 阅读全文

摘要：高并发原则 无状态：应用无状态，配置文件有状态 拆分：系统维度、功能维度、读写维度、AOP维度、模块维度 服务化：进程内服务-单机远程服务-集群手动注册服务-自动注册和发现服务-服务分组/隔离/路由-服务治理（限流/黑名单） 消息队列：实现服务解耦、异步处理、流量削峰/缓冲（需要注意：处理生产消息失败、消息重复接收处理、生产重试；作为大流量缓冲，牺牲强一致性，保证最终一致性；需要数据校对） 数据异构：异构数据形成闭环，数据存储到合适的存储引擎；聚合数据，使前端通过少量调用拿到所需数据；依赖系统出问题，还能正常工作 缓存： 浏览器缓存（时效性不强的数据） APP客户端缓存（大促前提前下发素材到客户端） CDN缓存（把资源推送到离用户最近的CDN节点） 接入层缓存（没有CDN缓存可以考虑使用Nginx搭建一层接入层） 应用层缓存（在应用所在机器上部署一组Redis，直接本机读取数据，多机之间主从同步数据） 分布式缓存（数据量太多，单机存储不了，用分片机制分散流量到多台要，或用分布式缓存实现， 常见的分片规则：一致性哈希算法） 并发化 高可用原则 降级：开关集中化管理，推送机制把开关推送到各个应用；可降级的多级读服务；开关前置化；业务降级，高并发流量来袭，保障核心业务，保证数据最终一致性即可，可同步改异步，优先处理高优先级数据 限流：恶意请求只到Cache层；对于穿透到后端的流量考虑Nginx的limit模块；对恶意IP可用Nginx deny屏蔽 切流量：可用Nginx切换故障的应用层 可回滚：版本化（事务回滚、代码库回滚、部署版本回滚、数据版本回滚、静态资源版本回滚） 阅读全文

摘要：什么是分布式架构 单体 分布式集群 分布式的高可用 搭建服务集群，提高负载，避免单点故障 应对灾难，搭建异地灾备，预防地区因发生地震等自然灾害 接口限流以及服务降级。为防止过高的并发量造成服务器负载过高而出现故障 故障监控报警 服务的可伸缩性，易于水平扩张服务器数量。 使用缓存降低数据库压力 使用CDN等加速静态资源的访问 分布式能够给架构带来什么 应用服务器集群： 随着访问量的继续增加，单台应用服务器也无法满足需求了，我们就需要搭建应用服务器集群来对外提供服务了 数据负载-读写分离 主从数据库之间的数据需要同步 应用中需要根据业务进行对应数据源的选择 搜索引擎/Nosql负载-读写分离 Nosql/Elasticsearch等 数据量压力-拆表/拆库 据的垂直拆分和水平拆分 =1000万，考虑拆表 =1亿 ，考虑拆库 应用压力-应用拆分 应用拆分，按照领域模型将我们的用户、商品、交易拆分成多个子系统 中台实现的基础--》微服务 案例—电商系统 系统分层，微服务管理 案例—Nginx反向代理 务器层面分流 案例—WCF分布式 每层中的服务器，可水平扩展（集群），可纵向扩展（按系统/域/功能切分） 案例—微服务架构 哑铃架构 微服务分布式集成 前端后端双向扩展。 分布式常见的坑—数据一致性 系统间的数据一致性。 系统内应用间的数据一致性。 应用内部对应多数据库的数据一致性，是个反模式，不要做通用方案。 一个数据库对应多个应用的数据一致性。 数据中台 分布式优点 分布式结构就是将一个完整的系统，按照业务功能，拆分成一个个独立的子系统，在分布式结构中，每个子系统就被称为“服务”。这些子系统能够独立运行在web容器中 阅读全文

摘要：“我们大家都知道把一个微服务架构变成一个异步架构只需要加一个MQ，现在市面上有很多MQ的开源框架。到底选择哪一个MQ的开源框架才合适呢?” 一、什么是MQ？MQ的原理是什么？ MQ就是消息队列，是Message Queue的缩写。消息队列是一种通信方式。消息的本质就是一种数据结构。因为MQ把项目中的消息集中式的处理和存储，所以MQ主要有解耦，并发，和削峰的功能。 1，解耦： MQ的消息生产者和消费者互相不关心对方是否存在，通过MQ这个中间件的存在，使整个系统达到解耦的作用。 如果服务之间用RPC通信，当一个服务跟几百个服务通信时，如果那个服务的通信接口改变，那么几百个服务的通信接口都的跟着变动，这是非常头疼的一件事。 但是采用MQ之后，不管是生产者或者消费者都可以单独改变自己。他们的改变不会影响到别的服务。从而达到解耦的目的。为什么要解耦呢？说白了就是方便，减少不必要的工作量。 2，并发 MQ有生产者集群和消费者集群，所以客户端是亿级用户时，他们都是并行的。从而大大提升响应速度。 3，削峰 因为MQ能存储的消息量很大，所以他可以把大量的消息请求先存下了，然后再并发的方式慢慢处理。 如果采用RPC通信，每一次请求用调用RPC接口，当请求量巨大的时候，因为RPC的请求是很耗资源的，所以巨大的请求一定会压垮服务器。 削峰的目的是用户体验变好，并且使整个系统稳定。能承受大量请求消息。 二、现在市面上有什么MQ， 重点介绍RocketMQ 现在市面上的MQ有很多，主要有RabbitMQ，ActiveMQ，ZeroMQ，RocketMQ，Kafka等等，这些都是开源的MQ产品。以前很多人推荐使用RabbitMQ，他也是非常好用的MQ产品，这里不做过多的介绍。Kafka也是高吞吐量的老大，我们这里也不介绍。 我们重点介绍一下RocketMQ，RocketMQ是阿里巴巴在2012年开源的分布式消息中间件，目前已经捐赠给Apache软件基金会，并于并于2017年9月25日成为 Apache 的顶级项目。 作为经历过多次阿里巴巴双十一这种“超级工程”的洗礼并有稳定出色表现的国产中间件，以其高性能、低延时和高可靠等特性近年来已经也被越来越多的国内企业使用。 功能概览图 可以看见RocketMQ支持定时和延时消息，这是RabbitMQ所没有的能力。 RocketMQ的物理结构 从这…… 阅读全文

摘要：同步架构与异步架构 背景 把智能系统比喻成KFC营业厅，处理器是窗口和窗口后面的服务员（把一个窗口当作一个核心），指令集是后面排队的人，窗口是数据吞吐量。 当中午就餐人多的时候，一个窗口肯定忙不过来， 这时候就需要增加窗口 解决方案 1.在窗口后面增加多个服务员，分担一下工作 2.新增多个窗口 分析 方案一就是异步架构，方案二同步架构 一个窗口是不可能比上多个窗口的工作效率 对比结论 优点：异步架构设计简单，实现方便。 缺点：性能低，吞吐量差。 总结：如果对处理并发量不高的系统。优先选择异步架构！！！ 异步能够给架构带来什么 优化前端，主动把控与用户的会话，让用户体验更好。 高并发处理，能够比较简单实现负载均，案例：12306 提供架构容错能力。高可用 系统代码更加安全，不用使用多线程，所以也会碰到线程死锁等问题，对信息同步也更加方便。 异步--高并发场景 异步编程—给我们带来什么 async/await 非阻塞I/O可以使CPU与I/O并不依赖，可以更大程度的利用资源 对于网络应用，并行带来的优势更大，利于分布式和云的应用 异步，自动多线程，主动处理软件架构问题，如：高并发，高可用。 异步—高可用场景 高可用实现 反向代理/负载均衡，实现网站的高可用 Processor，通过重复Worker实现高可用的架构 微服务-高并发/高可用实现 前端MQ订阅，后端Processer调用微服务实现 高并发，利用网关，很方便的进行服务分流，eg：Docker 高可用，MQ防止数据丢失，结合线程池/反向代理网关[k8s]插件,实现微服务的高可用 缓存—给我们带来什么 提高数据使用性能和安全….. 高可用，实现内存数据的高可用，结合nginx等，可以很方便的实现软件高可用 高并发，Redis数据多节点异地存储，可以实现多节点分流 微服务-高并发/高可用场景 前端MQ订阅，后端Processer调用微服务实现 高并发，利用网关，很方便的进行服务分流，eg：Docker 高可用，MQ防止数据丢失，结合线程池/反向代理网关[k8s]插件,实现微服务的高可用 MQ--高可用/高并发 高可用 高可用，服务的持续响应 解耦，MQ的消息生产者和消费者互相不关心对方是否存在 并发，MQ有生产者集群和消费者集群，所以客户端是亿级用户时，他们都是并行的。从而大大提升响应速度。 削峰…… 阅读全文

摘要：什么是架构分隔 单体 单体：是把系统部署到一台服务器上，所有的请求业务都由这台服务器处理 优点：适合小型系统，节省资源 缺点：安全性低，一旦有突发压力， 整个系统都会面临崩溃 分层—隔离效果 分层：分层架构的一个突出特性是组件间关注点分离 (separation of concerns)。一个层中的组件只会处理本层的逻辑。 比如说，展示层的组件只会处理展示逻辑，业务层中的组件只会去处理业务逻辑 组件分离，让我们更容易构造有效的角色和强力的模型。这样应用变的更好开发，测试，管理和维护。 忌：分层使架构变得复杂，我们不能为了分层而分层 纵向分层是为了什么 整体灵活性 分析:总体灵活性是响应环境变化的能力。尽管分层模式中的变化可以隔绝起来，想在这种架构中做一些也改变也是并且费时费力的。分层模式的笨重以及经常出现的组件之间的紧耦合是导致灵活性降低的原因。 易于部署 分析:这取决于你怎么发布这种模式，发布程序可能比较麻烦，尤其是很大的项目。一个组件的小小改动可能会影响到整个程序的发布(或者程序的大部分)。发布必须是按照计划，在非工作时间或者周末进行发布。因此。分层模式导致应用发布一点也不流畅，在发布上降低了灵活性。 可测试性 分析:因为组件都处于各自的层次中，可以模拟其他的层，或者说直接去掉层，所以分层模式很容易测试。开发者可以单独模拟一个展示组件，对业务组件进行隔绝测试。还可以模拟业务层来测试某个展示功能。 性能 分析:尽管某些分层架构的性能表现的确不错，但是这个模式的特点导致它无法带来高性能。因为一次业务请求要穿越所有的架构层，做了很多不必要的工作。 伸缩性 评级:低分析:由于这种模式以紧密耦合的趋势在发展，规模也比较大，用分层架构构建的程序都比较难以扩展。你可以把各个层分成单独的物理模块或者干脆把整个程序分成多个节点来扩展分层架构，但是总体的关系过于紧密，这样很难扩展。 易开发性 分析:在开发难度上面，分层架构得到了比较高的分数。因为这种架构对大家来说很熟悉，不难实现。大部分公司在开发项目的都是通过层来区分技术的，这种模式对于大多数的商业项目开发来说都很合适。公司的组织架构和他们软件架构之间的联系被戏称为”Conway’s law”。你可以Google一下查查这个有趣的联系。 隔离设计原则 1，第一个依据是基于目的划分层次。 以领域驱…… 阅读全文