架构

1、MySQL 逻辑架构，上层客户端-----》连接/线程处理------》解析器-----》优化器 -----》存储引擎，解析器如果有生成查询缓存，那么连接/线程处理也有可能直接到查询缓存，返回结果，图如下 2、并发控制，读写锁，共享锁，排他锁，锁粒度（表锁 table lock 行级锁 row lock） 3、事务 ：原子性，一致性，隔离性，持久性 隔离级别：未提交度，提交读（不可重复读），可重复读 ，可串行化 死锁 MySQL 中的事务 4、多版本并发控制（MVCC），只在REPEATABLE READ 和 READ COMMIT下工作，原理就是每行记录后面加两个隐藏的列来实现，一个保存行的创建时间，一个保存行的过期时间；这个时间是指系统版本号； 4、MySQL存储引擎 InnoDB MyISAM archive(只支持isert和select操作，日志或者数据采集类) CSV fedetated引擎 Memory引擎（HEAP表）临时表局势memory引擎，场景 NDB集群引擎 第三方存储引擎（OLTP类引擎，XtrDB PBXT TokuDB） 面向列的存储引擎 infobright，大数据量 如何转换表引擎？ 1、ALTER TABLE 慢，会消耗系统所有的I/O能力 2、导入与导出 3、创建与查询 create table innodb_table like

1. 概述 本文以淘宝作为例子，介绍从一百个到千万级并发情况下服务端的架构的演进过程，同时列举出每个演进阶段会遇到的相关技术，让大家对架构的演进有一个整体的认知，文章最后汇总了一些架构设计的原则。 特别说明：本文以淘宝为例仅仅是为了便于说明演进过程可能遇到的问题，并非是淘宝真正的技术演进路径 2. 基本概念 在介绍架构之前，为了避免部分读者对架构设计中的一些概念不了解，下面对几个最基础的概念进行介绍： 分布式 系统中的多个模块在不同服务器上部署，即可称为分布式系统，如Tomcat和数据库分别部署在不同的服务器上，或两个相同功能的Tomcat分别部署在不同服务器上 高可用 系统中部分节点失效时，其他节点能够接替它继续提供服务，则可认为系统具有高可用性 集群 一个特定领域的软件部署在多台服务器上并作为一个整体提供一类服务，这个整体称为集群。如Zookeeper中的Master和Slave分别部署在多台服务器上，共同组成一个整体提供集中配置服务。在常见的集群中，客户端往往能够连接任意一个节点获得服务，并且当集群中一个节点掉线时，其他节点往往能够自动的接替它继续提供服务，这时候说明集群具有高可用性 负载均衡 请求发送到系统时，通过某些方式把请求均匀分发到多个节点上，使系统中每个节点能够均匀的处理请求负载，则可认为系统是负载均衡的 正向代理和反向代理 系统内部要访问外部网络时

VM架构设计文档初稿v0.01 文档介绍 本文档是经过讨论，作为VM新架构设计开发中的重要依据。对该架构的整个系统的结构进行详实细致的描述。阐述框架结构，说明该架构所采取的设计策略和所有技术，并对相关内容作出统一的约定。为设计，编码，测试提供可以参考的模板和帮助。提高设计变更开发的效率，将头脑风暴的结果进行的具体的书面呈现。 架构设计思想 该架构VM以微服务思想为核心进行衍化，兼容DevOps作为主要基础，并使用DDD领域驱动设计思想作为设计过程中的指导思想及方法论。 架构体系描述 以分层体系作为系统架构风格的顶层设计，秉承高内聚，低耦合思想引入分布式思想，消息队列等等作为架构解耦，扩展的基本要素，以DDD思想和业务逻辑作为微服务拆分的主要原则 系统设计分为 显视层 通信控制层 业务逻辑层 持久化层 系统关键模块及组件 根据各层以及各链路整体出发 系统关键模块及组件 共有 负载均衡 , RTM (Request To Message),MQ，Frame 微服务模块，数据存储等 首先 所有用户请求先行经过 负载均衡服务 到 多节点 分布式 的 RTM (Request To Message) 进行消息转发和 依赖 Zookeeper的非法请求识别，服务监测，降级， 接下来 请求消息被转换为约定JSON格式进入到 RabbitMQ相应的消息队列，消息队列主要承载 解耦 削峰 限流

在此之前，发布过两个版本： 运维工程师打怪升级之路 V1.0 版本发布 运维工程师打怪升级必经之路 V1.0.1 很多读者伙伴们反应总结的很系统、很全面，无论是0基础初学者，还是有基础的入门者，或者是有经验的职场运维工程师们，都反馈此系列文章非常不错！ 为了更好的提升可阅读性、可查找性，特此，将列与公众号菜单的系统系列文章，统一整理于一篇文章，按原来的整体架构，分类整理，也就是说，今后的更新与迭代不再是多级的菜单目录，统一是一篇完整的文章，有利于读者阅读与查找。 命名：《运维工程师打怪升级之路》 版本：V1.0版本「2019年1月20日发布」 V1.0.1版本「2019年4月26日更新」 V2.0版本 「2019年5月13日发布」 内容概况： 内容由浅入深，从最基础的网络基础开始，逐渐深入系统的学习Linux系统运维知识。然后引入企业项目实战内容，从而让更多学习Linux系统运维的读者朋友们「无论前端、后端、测试还是运维，底层系统是必备技术点」，都能够快速入门、并且在一程度上掌握当下企业所需要的技术储备。再穿插企业面试题、面试经验等，同时也能帮助运维工程师们在求职的路上能更加顺畅，少踩坑。 后面会逐渐更新将其完善，希望能帮助到同为运维路上的技术人。 运维工程师打怪升级进阶之路基础篇 1、网络基础 网络组建之路由基础 网络基础NAT（Network Address

当前数字化建设进入深水区，企业面临数字化转型所带来的新挑战。外围环境加速变化，竞争逐渐激烈，企业需要以大量的创新与实践为引导来实现自身的变化与转型。那么，如何能够更好地把握外部机遇以及应对机遇带来的不确定风险，重要的途径就是通过企业内部敏捷来助力外部的成功。DevOps就是为解决企业敏捷问题的一种新型方式方法，是企业为适应当前数字化发展形势做出的有效尝试。 DevOps是强调产品管理、软件开发和运营专业人员之间沟通和协作的软件开发过程，可通过自动化工具实现软件集成、测试、部署和基础设施变更。DevOps五个关键元素能够帮助更好理解这一概念，它们是——成体系的文化、协作的人、不断迭代的产品、持续的流程、自动化的技术。可以看到，DevOps既是一个技术问题，也是一个商业问题、文化问题。 DevOps的产生和兴起存在历史的必然性 1、在全球化经济蓬勃、互联网移动互联网等新技术催生出新的商业形态，而新的商业形态反过来又强化和促进了企业数字化转型的迫切性和IT在转型过程中扮演角色的重要性。 2、新技术和新的研发工程实践的成熟度提供了基础。例如以云计算（软件定义计算、存储、网络）为代表的灵活、弹性的基础设施供给能力；以微服务架构为代表的架构实践，为软件的持续交付降低了风险，提升了灵活性和交付效率；以Docker为代表的新的软件交付模式，简化了交付难度，且非常适合承载微服务架构下的软件交付

本文来自 Rancher Labs 前 言 实际上，没有一个迁移路径能够适用于将所有传统应用程序迁移到云。这些应用程序通常在物理机、虚拟机或本地。虽然一般情况下是重新设计应用程序架构以适用云原生服务，但这并非是唯一的答案。将一个现有的应用程序的架构重新构建为微服务架构或云原生架构会面临诸多挑战，如重构成本、复杂性以及应用程序的依赖性。 虽然将应用程序的架构现代化有诸多好处，但许多组织仍在Windows 2003 Servers上运行现有服务。而微软不再支持Windows 2003为此带来了一些挑战。首先，人们不得不开始决定要如何处理这些应用程序，特别是Windows 2008的生命周期也即将结束。 许多企业想要迁移到现代架构中，期望以此能让他们的应用程序获得复杂性、安全性和可用性。而容器提供了使应用程序现代化并将其移至云原声服务的灵活性。在本文中，我们将重点介绍能够迁移到容器的应用程序，一般是.Net、Web、SQL和其他没有依赖性但在Windows2003上运行的应用程序。你可以无需更改代码就能将这些应用程序迁移到容器，并且使它们在将来具备可移植性。你将会享受到在Kubernetes上运行容器的好处，如可编排、可用性、更高的弹性伸缩和密度。 请注意：不是所有的应用程序和服务都能运行在容器中。有些应用程序存在核心依赖项（如数据库、存储需求等），这些都需要解决。此外

前言 一个成熟的网站架构并不是一开始设计就具备高可用、高伸缩、高性能等特性的，它是随着用户量和业务线不断增加，基础架构才逐渐健壮的。在发展初期，一般都是从0到1，不会一上来就整一些大而全的架构，也很少人这么任性。 说明 适用业务：电商/门户/招聘网站 开发语言：PHP和JAVA Web服务：Nginx/Tomcat8 数据库：MySQL 操作系统：CentOS 物理服务器：Dell R730/R430 一、单台服务器部署 项目开发完成上线，用户访问量寥寥无几。 二、WEB与数据库独立部署 有一定用户访问量，单台服务器性能有些吃力，想提高并发能力，增加一台服务器，将HTTP请求与SQL操作负载分散不同服务器。 三、动静分离-初期 什么是动静分离？静态页面与动态页面分离部署。 四、数据库主从与查询缓存 RedisCache 使用Redis缓存数据库查询结果，将热数据放到内存中，提高查询速度，减少数据库请求。 MySQL主从 基于binlog异步复制。 HA MySQL：Keepalived 怎么保证Redis缓存时效性？ a) 增加中间件，在主从同步延迟时间内，中间件将SQL读操作还路由到主。 b) 主从同步延迟时间后，再异步发起一次淘汰Cache。 c) 增加消息队列和清理Cache程序，入库同时也写入消息队列，缓存清理程序订阅消息队列，一旦有数据更新，重新Cache。 d)

面试官心理分析 说实话，如果面试官问你这个题目，那么你必须要使出全身吃奶劲了。为啥？因为你没看到现在很多公司招聘的 JD 里都是说啥，有高并发就经验者优先。 如果你确实有真才实学，在互联网公司里干过高并发系统，那你确实拿 offer 基本如探囊取物，没啥问题。面试官也绝对不会这样来问你，否则他就是蠢。 假设你在某知名电商公司干过高并发系统，用户上亿，一天流量几十亿，高峰期并发量上万，甚至是十万。那么人家一定会仔细盘问你的系统架构，你们系统啥架构？怎么部署的？部署了多少台机器？缓存咋用的？MQ 咋用的？数据库咋用的？就是深挖你到底是如何扛住高并发的。 因为真正干过高并发的人一定知道，脱离了业务的系统架构都是在纸上谈兵，真正在复杂业务场景而且还高并发的时候，那系统架构一定不是那么简单的，用个 redis，用 mq 就能搞定？当然不是，真实的系统架构搭配上业务之后，会比这种简单的所谓“高并发架构”要复杂很多倍。 如果有面试官问你个问题说，如何设计一个高并发系统？那么不好意思，一定是因为你实际上没干过高并发系统。面试官看你简历就没啥出彩的，感觉就不咋地，所以就会问问你，如何设计一个高并发系统？其实说白了本质就是看看你有没有自己研究过，有没有一定的知识积累。 最好的当然是招聘个真正干过高并发的哥儿们咯，但是这种哥儿们人数稀缺，不好招。所以可能次一点的就是招一个自己研究过的哥儿们

以上拓扑是我在工作中遇到的一个小型网络架构，图画了有点丑但是不影响知识的分享。和学习CCNA的时候很相似，这种传统的网络架构一定要非常熟悉（知道每个设备位置的作用及大概需要配置点什么操作）。和学习CCNA时不同的是出口防火墙这边没有，直接是个三层路由器（实际工作中一般出口都是防火墙，很难想象没有安全设备直接将网络暴露在公网时多么的糟糕）。 下面具体说说设备位置的作用。首先配置最多的是在出口防火墙这里，内网的终端需要上网游览网页、DMZ区域的服务器(拓扑上未画)需要将端口映射公网给员工在家里访问。核心交换机起着承上启下的作用，连接几个楼层的交换机。以上大致需要用到技术：防火墙(安全策略)，三层(NAT,静态路由)，二层(Trunk,access,svi)。 总结，当网络工程师在看资料的时候第一先要抓住重点，配置最多的区域是需求最集中的。一定要严格知道每一条路由走向及策略是干什么的。话说回来其他复杂点的架构是在这种基本的架构需求基础上扩展的，以上这种架构客户端电脑基本50-100台左右，虽然使用人数不多但是麻雀虽小五脏俱全对于刚从事网络工程师这一块的朋友可以好好了解下这种架构。它的特点是结构简单、排错方便、后期可扩展性强。在今后的时间这个博客将定义成网络工程师案例及工作分析的平台希望大家一起进步。 来源： 51CTO 作者： 蓝天飞飞 链接： https://blog.51cto

微软网络安全参考架构描述了微软的网络安全能力，以及它们是如何与现有的安全架构进行集成的。 微软的网络安全参考架构将通过关键组件实现： Azure安全中心的跨平台可视性、保护等等检测。 如何获得不同的Azure服务覆盖Azure Policy,Azure Key Vault,Azure WAF ，Azure Antimalware，Backup& Site Recovery，Disk & Storage Encryption、SQL加密、SQL数据屏蔽，Azure Active Directory, Intune, Azure信息保护,Azure日志分析,Azure监控。 将涵盖M365安全与合规门户、CASB、MDATP、Azure ATP、Secure Score和合规管理 在此之后，您将知道在哪里可以保护、检测和修复安全基础设施的相关需求；管理你的身份；保护您的端点和用户免受基本和高级threat；并分类和加密您的数据。 安全架构的模板——企业可以使用该文档来帮助定义网络安全能力的目标状态，这对企业IT来讲，该安全架构很有用，因为它涵盖了现代企业资产的能力，而现在企业资产跨越了内部、移动设备、许多云以及物联网/操作技术。 安全功能的参考——很多企业不知道他们拥有了哪些技术，哪些已经部署落实到位，哪些是新功能，需要部署测试来验证其稳定性，从而推广使用。 了解微软的功能—