基本理论
扩展性设计
AKF可扩展立方设计。
可用性设计
可靠性设计
软件可靠性 (software reliability )是软件产品在规定的条件下和规定的时间区间完成规定功能的能力。规定的条件是指直接与软件运行相关的使用该软件的计算机系统的状态和软件的输入条件，或统称为软件运行时的外部输入条件；规定的时间区间是指软件的实际运行时间区间；规定功能是指为提供给定的服务，软件产品所必须具备的功能。软件可靠性不但与软件存在的缺陷和（或）差错有关，而且与系统输入和系统使用有关。软件可靠性的概率度量称软件可靠度。
一致性设计
负载均衡设计
负载均衡（Load Balance），顾名思义，是把服务的并发请求均衡地负载到后端多个具有相同能力的服务进行处理分担，以廉价有效透明的方式扩展网络设备或服务的带宽，增加吞吐量，增强服务的整体处理能力，提供服务的灵活性和可用性。
过载保护设计
一 问题的产生
在大型的分布式系统中，通常需要调用或操作远程的服务或者资源，这些远程的服务或者资源由于调用者不可以控的原因比如网络连接缓慢，资源被占用或者暂时不可用等原因，导致对这些远程资源的调用失败。这些错误通常在稍后的一段时间内可以恢复正常。
但是，在某些情况下，由于一些无法预知的原因导致结果很难预料，远程的方法或者资源可能需要很长的一段时间才能修复。这种错误严重到系统的部分失去响应甚至导致整个服务的完全不可用。在这种情况下，采用不断地重试可能解决不了问题，相反，应用程序在这个时候应该立即返回并且报告错误。
通常，如果一个服务器非常繁忙，那么系统中的部分失败可能会导致 “连锁失效”（cascading failure）。比如，某个操作可能会调用一个远程的WebService，这个service会设置一个超时的时间，如果响应时间超过了该时间就会抛出一个异常。但是这种策略会导致并发的请求调用同样的操作会阻塞，一直等到超时时间的到期。这种对请求的阻塞可能会占用宝贵的系统资源，如内存，线程，数据库连接等等，最后这些资源就会消耗殆尽，使得其他系统不相关的部分所使用的资源也耗尽从而拖累整个系统。在这种情况下，操作立即返回错误而不是等待超时的发生可能是一种更好的选择。只有当调用服务有可能成功时我们再去尝试。
二 解决方法
熔断器模式可以防止应用程序不断地尝试执行可能会失败的操作，使得应用程序继续执行而不用等待修正错误，或者浪费CPU时间去等到长时间的超时产生。熔断器模式也可以使应用程序能够诊断错误是否已经修正，如果已经修正，应用程序会再次尝试调用操作。
熔断器模式就像是那些容易导致错误的操作的一种代理。这种代理能够记录最近调用发生错误的次数，然后决定使用允许操作继续，或者立即返回错误。
灾难恢复和备份
协议设计
二进制协议
文本协议
接入层设计
DNS轮询（负载均衡）
一个域名针对多个ip A记录的解析，DNS服务器将解析请求按照A记录的顺序，逐一分配到不同的IP上，这样就完成了简单的负载均衡
动静态分离
我常常认为最佳的性能优化手段就是使用缓存了，但是缓存的数据一般都是那些不会经常变化的数据，上文里说到的浏览器缓存，CDN其实都是可以当做缓存手段来理解，它们也是提升网站性能最为有效的方式之一，但是这些缓存技术到了动态网站却变得异常不好实施，这到底是怎么回事了？
首先动态网站和静态网站有何不同呢？我觉得动态网站和静态网站的区别就是动态网站网页虽然也有一个url，但是动态网站网页的内容根据条件不同是会发生改变的，而且这些变化的内容却是同一个url，url在静态网站里就是一个资源的地址，那么在动态网站里一个地址指向的资源其实是不同的。因为这种不同所以我们没法把动态的网页进行有效的缓存，而且不恰当的使用缓存还会引发错误，所以在动态网页里我们会在meta设定页面不会被浏览器缓存。
如果每次访问动态的网页该网页的内容都是完全不同的，也许我们就没有必要写网站静态化的主题了，现实中的动态网页往往只是其中一部分会发生变化，例如电商网站的菜单、页面头部、页面尾部这些其实都不会经常发生变化，如果我们只是因为网页一小部分经常变化让用户每次请求都要重复访问这些重复的资源，这其实是非常消耗计算资源了，我们来做个计算吧，假如一个动态页面这些不变的内容有10k，该网页一天有1000万次的访问量，那么每天将消耗掉1亿kb的网络资源，这个其实很不划算的，而且这些重复消耗的宽带资源并没有为网站的用户体验带来好处，相反还拖慢了网页加载的效率。那么我们就得考虑拆分网页了，把网页做一个动静分离，让静态的部分当做不变的静态资源进行处理，动态的内容还是动态处理，然后在合适的地方将动静内容合并在一起。
静态化
这就说明静态网页的一个特点：静态网页的资源基本是不会发生变化的。因此我们第一次访问一个静态网页和我们以后访问这个静态网页都是一个重复的请求，这种网站加载的速度基本都是由网络传输的速度，以及每个资源请求的大小所决定，既然访问的资源基本不会发生变化，那么我们重复请求这些资源，自己在那里空等不是很浪费时间吗？如是乎，浏览器出现了缓存技术，我们开发时候可以对那些不变的资源在http协议上编写相应指令，这些指令会让浏览器第一次访问到静态资源后缓存起这些静态资源，用户第二次访问这个网页时候就不再需要重复请求了，因为请求资源本地缓存，那么获取它的效率就变得异常高效。
反向代理（可靠性）
反向代理（Reverse Proxy）方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个反向代理服务器。
通常的代理服务器，只用于代理内部网络对Internet的连接请求，客户机必须指定代理服务器,并将本来要直接发送到Web服务器上的http请求发送到代理服务器中。由于外部网络上的主机并不会配置并使用这个代理服务器，普通代理服务器也被设计为在Internet上搜寻多个不确定的服务器,而不是针对Internet上多个客户机的请求访问某一个固定的服务器，因此普通的Web代理服务器不支持外部对内部网络的访问请求。当一个代理服务器能够代理外部网络上的主机，访问内部网络时，这种代理服务的方式称为反向代理服务。此时代理服务器对外就表现为一个Web服务器，外部网络就可以简单把它当作一个标准的Web服务器而不需要特定的配置。不同之处在于，这个服务器没有保存任何网页的真实数据，所有的静态网页或者CGI程序，都保存在内部的Web服务器上。因此对反向代理服务器的攻击并不会使得网页信息遭到破坏，这样就增强了Web服务器的安全性。
LVS
LVS是Linux Virtual Server的简写，意即Linux虚拟服务器，是一个虚拟的服务器集群系统
F5
负载均衡（又称为负载分担），英文名称为Load Balance，其意思就是将负载（工作任务）进行平衡、分摊到多个操作单元上进行执行，例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等，从而共同完成工作任务。负载均衡设备不是基础网络设备，而是一种性能优化设备。对于网络应用而言，并不是一开始就需要负载均衡，当网络应用的访问量不断增长，单个处理单元无法满足负载需求时，网络应用流量将要出现瓶颈时，负载均衡才会起到作用。
F5取名自龙卷风风力的最高等级，是应用交付网络（ADN）的全球领导者，是应用交付网络（ADN）领域的全球领先厂商。全球很多知名企业、服务提供商和云提供商以及领先的在线公司都采用F5的负载均衡产品和解决方案来优化IT投资，推动业务发展。F5公司这方面的产品包括广域流量负载均衡、链路负载均衡和本地流量负载均衡等，准确名称你可以去F5中文官网查下F5 BIG-IP系列，比如F5 BIG-IP企业管理器、F5 VIPRION威普龙应用交付控制器、F5 WANJet 广域网加速器、F5 BIG-IP Web应用加速器(Web Accelerator) 、F5 BIG-IP 本地流量管理器(LTM)、F5 BIG-IP 链路控制器(LC) ……##CDN
CDN是构建在网络之上的内容分发网络，依靠部署在各地的边缘服务器，通过中心平台的负载均衡、内容分发、调度等功能模块，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。CDN的关键技术主要有内容存储和分发技术。
CDN的基本原理是广泛采用各种缓存服务器，将这些缓存服务器分布到用户访问相对集中的地区或网络中，在用户访问网站时，利用全局负载技术将用户的访问指向距离最近的工作正常的缓存服务器上，由缓存服务器直接响应用户请求。
逻辑层设计
连接池
连接池是创建和管理一个连接的缓冲池的技术，这些连接准备好被任何需要它们的线程使用。
串行化设计
串行化(Serialization)是计算机科学中的一个概念，它是指将对象存储到介质（如文件、内存缓冲区等）中或是以二进制方式通过网络传输。之后可以通过反串行化从这些连续的字节（byte）数据重新构建一个与原始对象状态相同的对象，因此在特定情况下也可以说是得到一个副本，但并不是所有情况都这样。
影子Master架构
批量写入
减少数据库访问次数，提升数据库性能
配置中心
随着业务复杂度的上升和技术架构的演变，对应用的配置方式也提出了越来越高的要求。一个典型的演变过程往往是这样的，起初所有配置跟源代码一起放在代码仓库中；之后出于安全性的考虑，将配置文件从代码仓库中分离出来，或者放在CI服务器上通过打包脚本打入应用包中，或者直接放到运行应用的服务器的特定目录下，剩下的非文件形式的关键配置则存入数据库中。上述这种方式，在单体应用阶段非常常见，也往往可以运行的很好，但到了微服务阶段，面对爆发式增长的应用数量和服务器数量，就显得无能为力了。这时，就轮到配置中心大显身手了。那什么是配置中心？简单来说，就是一种统一管理各种应用配置的基础服务组件。
选型一个合格的配置中心，至少需要满足如下4个核心需求：
非开发环境下应用配置的保密性，避免将关键配置写入源代码
不同部署环境下应用配置的隔离性，比如非生产环境的配置不能用于生产环境
同一部署环境下的服务器应用配置的一致性，即所有服务器使用同一份配置
分布式环境下应用配置的可管理性，即提供远程管理配置的能力
现在开源社区主流的配置中心框架有Spring Cloud Config和disconf，两者都满足了上述4个核心需求，但又有所区别
去中心化
在一个分布有众多节点的系统中，每个节点都具有高度自治的特征。节点之间彼此可以自由连接，形成新的连接单元。任何一个节点都可能成为阶段性的中心，但不具备强制性的中心控制功能。节点与节点之间的影响，会通过网络而形成非线性因果关系。这种开放式、扁平化、平等性的系统现象或结构，我们称之为去中心化。
随着主体对客体的相互作用的深入和认知机能的不断平衡、认知结构的不断完善，个体能从自我中心状态中解除出来，称之为去中心化。
去中心化，不是不要中心，而是由节点来自由选择中心、自由决定中心。简单地说，中心化的意思，是中心决定节点。节点必须依赖中心，节点离开了中心就无法生存。在去中心化系统中，任何人都是一个节点，任何人也都可以成为一个中心。任何中心都不是永久的，而是阶段性的，任何中心对节点都不具有强制性。
通讯机制
同步与异步
MQ（消息队列）
Cron（任务调度）
在Linux系统中，计划任务一般是由cron承担，我们可以把cron设置为开机时自动启动。cron启动后，它会读取它的所有配置文件（全局性配置文件/etc/crontab，以及每个用户的计划任务配置文件），然后cron会根据命令和执行时间来按时来调用度工作任务。
RMI（远程调用）
RPC（远程调用）
数据层架构设计
缓存优化
高可用
允许cache miss
http://www.360doc.com/content/16/0812/10/16915_582655840.shtml
DAO&ORM
双主架构
对于MySQL数据库的Master-Slave架构设计，对于一般的对可用性要求不高的系统来说，是一个不错的设计方案，但是如果对可用性要求较高，就会存在一定的问题，我们先看看Master-Slave架构的特点：一个Master作为主数据库服务器，主要功能是负责处理应用客户端的写数据处理，还担当众多Slave数据库复制数据源的角色。多个master主要是负责应用客户端的读数据处理。但是我们的Master数据库服务器难免会出现故障而停机，或者系统需要停机升级，这时就需要短暂的停机，从而导致系统无法处理写数据业务。这对于一些高可用性的系统来说是个无法接受的问题，因为很多领域的应用系统是需要24小时提供服务的。这时我们可以考虑Master-Master架构。
Master-Master架构的主要特点是：提供两个Master服务器，对应用客户端都提供读写服务，而这两个Master服务器互相将对方作为自己的Master，而自己作为对方的Slave来进行数据复制。这样，任何一方的数据修改都会复制到对方数据库。
但是，需要说明的是，Master-Master架构在实际应用中，并不需要2个Master服务器端都提供写数据的服务，因为这样的架构设计仅仅是解决可用性问题，也就是解决一台Master宕机或故障后无法提供写数据服务的问题，所以正常的情况下，只需要一台Master服务器提供写数据服务，而另一台则只提供读数据服务，同时兼承担备份写数据服务的角色。而且，在小型系统中，只需要一台Master服务器，提供读写服务，另外一台则只承担备份写数据服务的角色。这些都是根据需求灵活变化的。
也许有人会问，既然这种架构2个Master都可以提供读写服务，那么为什么不都负责读写呢，这样不是读写效率更高吗？2台服务器分担写数据服务效率自然高，但是必然产生一个新的问题，那就是数据的一致性问题。2台服务器写数据容易造成数据的不一致，而且MySQL Replicaiton是异步实现机制，即使是晚更新的数据也可能被早修改的数据覆盖。
京公网安备 11010502036488号