可用性

设计高可用的软件架构，是每个互联网软件开发工程师的追求。尤其对于在线交易系统、在线广告系统而言，服务的可用性会直接影响商业变现。随着互联网技术在工业界的广泛使用，各大互联网公司在各自的业务领域内，沉淀了成熟的高可用架构方案。那么究竟什么是高可用？高可用架构该如何设计呢？ 度量 首先需要了解下什么是可用性以及如何度量可用性。对于一个交互式IT产品，是否可用是看用户能否用该产品完成他的任务。可用性就是在某个考察时间内，系统能够正常运行的概率或时间占有率的期望值。对于可用性等级，业内一般用n个9来描述，如下所示。 服务处于不可用状态的时间称为 故障时间 。可用性每提高一个等级，故障时间就要降一个数量级。从天到时到分，相对来说比较容易实现。再往后每提高一个等级，将付出成百上千倍的努力。大型网站服务通常至少做个4个9，做到5个9及以上就比较困难了。不仅要解决技术挑战，还要面对极大的成本压力。对于网站核心服务，会尽可能做到5个9，而非核心服务4个9，甚至3个9也可以接受。做技术决策时必须考虑 经济账 。 方法 那如何做到高可用呢？方法很简单： 冗余 。通俗讲，就是双保险机制。背后的理论基础是概率论。假设某个服务的可用性是99%（故障率1%），那么两个服务的可用性就是1-0.01*0.01=99.99%。可以看到，冗余对可用性的提升是 指数级 的。再冗余一个服务，可用性就达到6个9了。哇

考核方式 开卷考试，其中60％为计算题 两次平时作业 平时考勤 信息安全的基本概念 信息安全的三个级别 计算机安全 网络安全 信息系统安全 其中计算机安全为主机范围 ，网络安全为整个网络范围，信息系统安全则为整个信息系统范围 安全的几个要素： 可用性 授权实体有权访问数据 其中DOS攻击即破坏信息的可用性，维护可用性安全只有防护DOS攻击 ​ 附：DOS攻击为通过各种手段耗尽被攻击对象的资源，使其无法正常提供服务 机密性 ：信息不暴露给未授权实体或进程 完整性 ：保证数据不被未授权修改 可控性：控制授权范围内信息流向及操作方式 可审查性：对出现的安全问题提供依据和手段（追责，查人） 其中前三者被称为 信息安全的三属性 ，后两个是在信息安全发展后逐渐出现的扩展属性。 安全威胁的来源 外部渗入：未被授权使用计算机的人 内部渗入者 被授权使用计算机，但是不能访问某些数据、程序或资源，它包括： 冒名顶替：使用别人的用户名和口令进行操作（用别人的号） 隐蔽用户：逃避审计和访问控制的用户（逃过检查和防火墙） 滥用职权者： 被授权使用计算机和访问系统资源，但是滥用职权 安全的目标 保障安全的基本目标就是要具备 ： 安全保护能力：积极的防御措施，保护网络免受攻击、损害，具有容侵能力，使得网络在即时遭受入侵的情况下也能提供安全、稳定、可靠的服务 隐患发现的能力：能够及时、准确

消息队列 为什么要用消息队列，都有什么优缺点？ 要问的是消息队列都有哪些场景，然后项目里具体实现的什么场景，你在这个场景里用的什么消息队列？ 期望的回答是， 你们公司有个什么业务，这个业务场景有什么技术挑战，如果不用MQ可能会很麻烦，但是你现在用了MQ带给你什么好处？ 场景比较多，但是比较核心的是3个： 解耦、异步、削峰 解耦 ​ 需要去考虑你负责的系统中是否有类似的场景，一个系统调用了多个系统和模块，互相之间的调用很复杂，维护起来很麻烦。但是这个调用并不需要直接同步调用接口，如果用MQ给它异步化解耦，也是可以的，你就需要 考虑在你的项目中，是不是可以运用这个MQ去进行解耦。在简历中体现出来 异步化 异步化可以大幅度提升高延迟接口的性能 削锋： 未使用MQ的时候： 使用MQ以后： 系统架构中引入MQ后可能存在的缺陷： 系统可用性降低：系统引入的外部依赖越多，越容易挂掉。 系统的复杂性更高：需要考虑的问题越多 一致性问题 问题2：kafka,activeMq,rabbitMq,rocketMq 都有什么优缺点？ 特性 ACTIVEMQ RABBITMQ ROCKETMQ KAFKA 单击吞吐量 万级吞吐量，相比RocketMq和Kafka要第一个数量级 万级，吞吐量相比RocketMq和 Kafka要低一个数量级 10万级，RocketMq也是可以支撑高吞吐的一种MQ 10万级别

一、 设计理念 1. 空间换时间 1) 多级缓存，静态化 客户端页面缓存（http header中包含Expires/Cache of Control，last modified(304，server不返回body，客户端可以继续用cache，减少流量)，ETag） 反向代理缓存 应用端的缓存(memcache) 内存数据库 Buffer、cache机制（数据库，中间件等） 2) 索引 哈希、B树、倒排、bitmap 哈希索引适合综合数组的寻址和链表的插入特性，可以实现数据的快速存取。 B树索引适合于查询为主导的场景，避免多次的IO，提高查询的效率。 倒排索引实现单词到文档映射关系的最佳实现方式和最有效的索引结构，广泛用在搜索领域。 Bitmap是一种非常简洁快速的数据结构，他能同时使存储空间和速度最优化（而不必空间换时间），适合于海量数据的的计算场景。 2. 并行与分布式计算 1) 任务切分、分而治之(MR) 在大规模的数据中，数据存在一定的局部性的特征，利用局部性的原理将海量数据计算的问题分而治之。 MR模型是无共享的架构，数据集分布至各个节点。处理时，每个节点就近读取本地存储的数据处理(map)，将处理后的数据进行合并(combine)、排序(shuffle and sort)后再分发(至reduce节点)，避免了大量数据的传输，提高了处理效率。 2) 多进程、多线程并行执行

从各个角度总结了电商平台中的架构实践，由于时间仓促，定了个初稿，待补充完善，欢迎大家一起交流。 转载请声明出处： http://blog.csdn.net/yangbutao/article/details/12242441 作者：杨步涛 关注分布式架构、大数据、搜索、开源技术 QQ:306591368 技术Blog： http://blog.csdn.net/yangbutao 一、 设计理念 1. 空间换时间 1) 多级缓存，静态化 客户端页面缓存（http header中包含Expires/Cache of Control，last modified(304，server不返回body，客户端可以继续用cache，减少流量)，ETag） 反向代理缓存 应用端的缓存(memcache) 内存数据库 Buffer、cache机制（数据库，中间件等） 2) 索引 哈希、B树、倒排、bitmap 哈希索引适合综合数组的寻址和链表的插入特性，可以实现数据的快速存取。 B树索引适合于查询为主导的场景，避免多次的IO，提高查询的效率。 倒排索引实现单词到文档映射关系的最佳实现方式和最有效的索引结构，广泛用在搜索领域。 Bitmap是一种非常简洁快速的数据结构，他能同时使存储空间和速度最优化（而不必空间换时间），适合于海量数据的的计算场景。 2. 并行与分布式计算 1) 任务切分、分而治之

从各个角度总结了电商平台中的架构实践，由于时间仓促，定了个初稿，待补充完善，欢迎大家一起交流。 转载请声明出处： http://blog.csdn.net/yangbutao/article/details/12242441 作者：杨步涛 关注分布式架构、大数据、搜索、开源技术 QQ:306591368 技术Blog： http://blog.csdn.net/yangbutao 一、 设计理念 1. 空间换时间 1) 多级缓存，静态化 客户端页面缓存（http header中包含Expires/Cache of Control，last modified(304，server不返回body，客户端可以继续用cache，减少流量)，ETag） 反向代理缓存 应用端的缓存(memcache) 内存数据库 Buffer、cache机制（数据库，中间件等） 2) 索引 哈希、B树、倒排、bitmap 哈希索引适合综合数组的寻址和链表的插入特性，可以实现数据的快速存取。 B树索引适合于查询为主导的场景，避免多次的IO，提高查询的效率。 倒排索引实现单词到文档映射关系的最佳实现方式和最有效的索引结构，广泛用在搜索领域。 Bitmap是一种非常简洁快速的数据结构，他能同时使存储空间和速度最优化（而不必空间换时间），适合于海量数据的的计算场景。 2. 并行与分布式计算 1) 任务切分、分而治之

　　用户界面评审特别是那些非正式的评审可以简单而直接地引入到几乎任何软件开发环境或过程中,所需要做的就是鼓励设计人员和程序员将其工作展示给同事来征求评论和建议。评审方法通常会促进协作,即使是最没有效的评审过程也会有利于开发人员之间交流思想和共享信息。用1-2小时时间来审视一些屏幕画面可以给用户界面带来很大改进。同行评审的最大问题是容易陷于长时间毫无结果的争论。非正式的同行评审特别是在没有很好加以计划和组织的情况下可能会导致比较低的效率,但其成本相对也较低。同行评审的质量可能还会受到同行经验的很大制约。成功的关键在于让那些有经验的开发人员参加评审,并且事先为有效发现可用性问题对评审活动加以认真计划和组织。 　　用户界面设计、可用性工程和人机交互方面的专家已经成为软件领域的重要技术资源。可用性专家可以为我们提供现成的技能和知识,而不必我们自己费力去学习。但是,现在还没有足够数量的合格专家来满足世界上所有软件开发项目的需要。即使是在适合的情况下依靠专家来解决可用性问题,开发人员自己无能为力的状况仍然得不到改变。在许多情况下,开发人员并没有真正理解这些来自专家的技能或知识。 　　软件开发过程一直都在不停地发生着变化，这种变化几乎发生在所有方面。编码曾经一度意味着个人埋头苦干,而如今已经成为一种团队过程。 　　近年来,软件和计算机应用系统开发的社会经济环境发生了巨大的变化

　　怎样才能满足对可用性日益增长的需求?软件可用性可以通过许多途径加以改进,但人们普遍使用的是其中几种比较成熟的方法。最受人们欢迎和广泛使用的方法有可用性测试、风格指南及标准、专家咨询和反复原型设计。尽管这些方法往往是有效的,但它们都有很大的不足。 　　改进软件可用性方面最常用的方法是可用性测试。可用性测试是以人们熟悉和广泛传授的标准技术为基础的。测试可以在可用性测试实验室中在受控条件下进行,或者是在日常工作条件下通过现场测试来进行。可用性测试的实验室方法和现场方法各有长处和不足,在时间和预算允许的情况下,最好结合在一起使用。如果运用得当,实验室和现场可用性测试方法都会成为改进软件可用性的有效手段，但它们都有各自的严重局限。可用性测试是一种改进软件可用性的有效手段，但高质量不是靠测试得到的。所有测试技术的最大问题是它们往往是在产品开发过程后期才进行。要进行测试，必须要有一个东西可以测试，通常这要求已经有一个正在开发的可以使用的系统、一个相对完整的模拟系统或者能够充分运转的原型。发现和改正任何软件缺陷的成本是随时间增加的。一旦系统交付使用,发现和改正缺陷的成本将会大幅度增加。为了改进质量，通过更有效地运用更好的方法去防止缺陷远比缺陷检测和清除更加高效和划算。 　　可用性测试经常避免不了这样一种情况 ，即无论测试如何细致入微和富有成果，其结果往往不尽如人意。对于开发过程来说

“应用交付”， 实际上就是指应用交付网络（Application Delivery Networking，简称ADN），它利用相应的网络优化/加速设备，确保用户的业务应用能够快速、安全、可靠地交付给内部员工和外部服务群。从定义中可以看出应用交付的宗旨是保证企业关键业务的可靠性、可用性与安全性。应用交付应是多种技术的殊途同归，比如 广域网加速 、 负载均衡 、Web 应用防火墙 …针对不同的应用需求有不同的产品依托和侧重。 网络的发展为企业带来更多的机遇，但也给企业带来了更多的挑战，随着应用系统访问人数的快速增长，企业对应用网络的稳定性和安全性要求也越来越高，而传统的解决方案日益显现出不足，根本无法保障最终用户对于应用访问的 快速性 、安全性以及稳定性方面的高要求，在这样的背景下，应用交付解决方案的真正价值开始体现，它能完全保障企业整个应用系统的快速、安全和稳定。应用交付作为一种全新的解决方案，一方面，能够在用户与应用之间建立一条快速、安全、稳定的访问通道，能保证众多的用户对应用系统的访问的稳定性的同时，还能够保证用户对应用访问的速度和安全性；另一方面，功能的复合和集中能够减少的企业的硬件的采购维护成本，同时提高了企业应用系统的运行效率，提高客户满意度。 F5: F5 公司成立于美国，是应用交付网络（ADN）领域的全球领先厂商，致力于帮助全球大型的企业和服务提供商实现虚拟化、 云计算

九、网站高可用建设：大型网站的稳定性建设 稳定性是决定网站生死的命脉 1、故障带来的影响 导致极差的用户体验、严重影响公司声誉 2、网站的可用性指标 网站可用性即网站正常运行时间的百分比，业界用N个9来量化可用性，最常说的是“4个9（99.99%）”。 网站可用性如果对达到4个9基本上就算及格了，即网站一年的不可用时间不超过52分钟。为了保障整个网站的全部服务完全不出错，有必要对服务进行分级，以保障服务的高可用性。 3、稳定性建设思路 稳定性的建设，有两个重要因素：一是思想上重视，开发人员对稳定性的重视可以避免70%-80%的故障；二是规范和工具的建设，用以保障稳定性。 架构阶段的稳定性建设项目：避免单点、分组隔离、异地容灾。 编码阶段的稳定性建设：错误捕获、异步线程、超时处理、限流保护。 测试阶段的稳定性建设：自动化对比测试、Beta测试。 发布阶段的稳定性建设：分批发布、多版本发布。 运行阶段的稳定性建设：实时监控报警、过载保护和自动降级、实时数据对账。 故障发生时的稳定性建设：故障定位、快速恢复。 4、高可用体系化建设 包括压测体系、管控体系、监控体系、恢复体系和度量体系。 压测体系：分为单系统压测和全链路压测。 全链路压测的技术难度并不大，技术手段主要由流量的制造、流量的标记、测试数据的处理。 管控体系主要是遇到一些异常情况时提供保护系统的措施，包括开关系统、预案系统