XIAOSUO 记录个人学习的足迹

摘要：持续发布/部署需求 持续部署和持续发布[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，第一个依据是基于目的划分层次。 以领域驱…… 阅读全文

摘要：什么架构冗余 单体 单体：是把系统部署到一台服务器上，所有的请求业务都由这台服务器处理 优点：适合小型系统，节省资源 缺点：安全性低，一旦有突发压力， 整个系统都会面临崩溃 集群 集群：把系统的各个功能拆分成不同的小系统，主要是分散能力 优点：资源利用率高，可以承担部分压力，降低耦合度，易于扩展 缺点：安全性低，如果其中一台服务器出现问题整个系统就会崩塌 忌：服务器架构单点，集成必须解决单点问题 冗余是什么 多余的重复或啰嗦内容（包括信息、语言、代码、结构、服务、软件、硬件等等）均称为冗余。冗余有两层含义，第一层含义是指多余的不需要的部分，第二层含义是指人为增加重复部分，其目的是用来对原本的单一部分进行备份，以达到增强其安全性的目的，这在信息通信系统当中有着较为广泛的应用。 我们可以从两方面理解： 第一层：表示多余的不需要的部分，举个例子：一个数据库可以存储100万条数据，但是我们可以设置最多存储80万条，剩余的20万就是冗余，这样就提高一定的读写性能。那如果达到80万之后还要增加数据怎么办？可以通过更换硬件、增加数据库数量、分库分表等方式来解决！ 第二层：是说增加重复部分，上面所说的集群可以说是一种冗余 总结：集群是一种冗余，但是冗余可不一定是集群！ 冗余能够给我们架构带来什么 解决服务器架构单点! ! ! 具体表现：实现架构的高并发[多客户场景]，实现系统高可用[安全场景] 一个好的系统设计应该是分布式和集群的结合，先分布式再集群，设置适当的冗余， 具体实现就是业务拆分成很多子业务，然后针对每个子业务进行集群部署，这样某个子业务如果出了问题， 整个系统完全不会受影响。 冗余设计原则 1，平衡主节点故障允许时间T1和主备节点切换时间T2。 由于对于整个系统而言，需求被定位在节点的故障允许时间T。 当T1太长、T2太短时，系统用来监视主备节点运行状态的消耗就少些， 但对主备节点的切换性能要求高，这只有在主备节点间数据同步很充分的时候， 才能做到，所以就提高了对数据同步要求。 2，减少需要同步的数据量。一方面，对构件信息进行良好归类，分离出静态信息和可以自行获得的信息， 不需要对这些信息进行同步。另一方面，增大构件的尺寸，把内部联系紧密的构件聚合成较大的构件， 这样就减少了需要跟外部交换的信息，也可以减少需要同步的数据量。 被动式冗余架构 基于失败重试原理，在…… 阅读全文

摘要：高可用负载均衡: haproxy+keepalived 正文： 企业业务量比较小的时候，单台服务器就可以满足业务需要了。但是随着业务发展，单服务器的问题就凸显出来了： ·当服务器挂掉时，业务就会中断 ·当业务量增加，单台服务器性能变差，如何透明的扩展服务器和带宽，增加服务器吞吐量 负载均衡器可以解决以上问题 1 负载均衡器拓扑图 本文会根据拓扑图，用haproxy和keepalived搭建一个负载均衡器 2 准备 2.1 准备环境 准备5台CentOS7.3主机和一个VIP地址: ·准备一个可用IP用作虚拟IP(VIP): VIP: 192.168.1.100 ·负载均衡器会用到2台主机，一主一备的架构 lb1(默认为主): 192.168.1.101 lb2(默认为备): 192.168.1.102 ·后端服务器集群中主机的IP地址 s1: 192.168.1.2 s2: 192.168.1.3 s3: 192.168.1.4 2.2 主机配置 2.2.1 所有主机上关闭防火墙 systemctl stop firewalld systemctl disable firewalld 2.2.2 所有主机关闭selinux setenforce 0 vi /etc/selinux/config SELINUX=disabled 2.3 安装haproxy和keepalived lb1和lb2上安装haproxy和keepalived yum install haproxy keepalived -y 2.4 安装nginx(有其他后端测程序，可省略此步) s1 s2 s3上安装nginx，目的是把nginx作为后端，如果有其他后端程序，这一步可以省略 yum install epel-release -y yum install nginx -y 2.3 配置keepalived KeepAlived是基于VRRP(Virtual Router Redundancy Protocol，虚拟路由冗余协议)实现的一个高可用方案，通过VIP（虚拟IP）和心跳检测来实现高可用 Keepalived有两个角色，Master和Backup。一般会是１个Master,多个Backup。 Master会绑定VIP到自己网卡上，对外提供服务。Master和Backup会…… 阅读全文

摘要：什么是架构分层 架构的原理，分层的意义所在 富士康工厂10000人以上规模，目标：每天百万级的手机产出。如何实现呢？ 角色分类，节点分离，在管理上面很常见。同理，架构也不外乎如此。 分层是表示将功能进行有序的分组：应用程序专用功能位于上层，跨越应用程序领域的功能位于中层，而配置环境专用功能位于低层。分层从逻辑上将子系统划分成许多集合，而层间关系的形成要遵循一定的规则。通过分层，可以限制子系统间的依赖关系，使系统以更松散的方式耦合，从而更易于维护。子系统的分组标准包含以下几条规则可见度。各子系统只能与同一层及其下一层的子系统存在依赖关系 为什么要架构分层 分层为什么在高可用/高并发场景必不可少 分层结构将应用系统正交地划分为若干层，每一层只解决问题的一部分，通过各层的协作提供整体解决方案。大的问题被分解为一系列相对独立的子问题，局部化在每一层中，这样就有效的降低了单个问题的规模和复杂度，实现了复杂系统的第一步也是最为关键的一步分解。 分层结构具有良好的可扩展性，为应用系统的演化增长提供了一个灵活的框架，具有良好的可扩展性。增加新的功能时，无须对现有的代码做修改，业务逻辑可以得到最大限度的重用。同时，层与层之间可以方便地插入新的层来扩展应用。 分层架构易于维护。在对系统进行分解后，不同的功能被封装在不同的层中，层与层之间的耦合显著降低。因此在修改某个层的代码时，只要不涉及层与层之间的接口，就不会对其他层造成严重影响。 反例，过度设计，分层会给我们带来哪些弊端 功能上线后，用户不关心 资源浪费 迭代速度慢，失去业务拓展的好时机 使用场景 分层在高可用使用场景 服务器架构keeolived 服务器架构脑裂场景 分层在高并发使用场景 服务器弹性伸缩 nginx反向代理 分层案例 反向代理同步架构 http://nginx.org CQRS异步架构 http://liuy.com/files/NiuNiuCQRs.zip 微服务中台架构 经典服务器分层架构图 阅读全文