１，文章是以前写的，做了修正；２，水平有限，有不当之处欢迎指正；３，有问题或者觉得没说明白的地方可在评论中指出；４，谢谢～

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

高可用与高性能

首先要明晰两个概念：【高可用】和【高性能】，高可用和高性能在某些＂方法论＂或者实现上有类似的地方，但是其解决的问题的侧重点和目标有所不同：
＂高可用＂关注的是＂持续可用问题＂，我知道这是废话，那么何为＂可用＂，简单的说＂部分服务器挂了依然还能为用户提供服务＂。

＂高可用＂的目标是减少系统故障和维护造成的停机时间。这个问题在其他＂服务＂行业也同样存在，比如北京地铁某条线路整体在白天进行维护或者检修就会带来很严重的问题，为了增加系统的可用性，地铁可以选择在晚上进行检修。

衡量可用度有一个简单的指标：可用性，他是一个百分百比，具体为：在一段时间内服务器（组）正常提供服务的时间/总的时间。如果你的服务器（组）在93%的情况下是正常的，我们可以认为系统可用性为93%，当然对于单台服务器或者组还有其他指标参数，比如宕机时间（平均故障间隔时间），故障率等。
可用性做到什么水平算合格？这完全取决于你具体业务的重要程度，如果你发现你的客户开始抱怨了，大概就说明你需要做点什么改善一下系统的可用性了～当然我们其实更多的是希望可用性越高越好，对吧？60分及格，可我们的目标是100分～

以下是github的状态页面：https://status.github.com 上面显示了系统可用性和网站的其他指标，可以作为用户的参考。

＂高性能＂侧重于＂速度＂问题，其实购买更好的处理器更多的内存，或者对系统进行某些层面的优化某些程度上也算是追求高性能的表现；而，我们这里要讨论的＂高性能＂特指＂当系统规模，比如用户量达到一定的量之后，系统依然可以保持快速的服务水平＂

当你的计算量非常大的时候，比如需要处理的数据量（请求量）非常大，或者解题步骤非常多或者繁杂的时候的时候我们为了节省时间，提供更优质的服务需要考虑＂高性能＂问题；

我们假设程序和系统已经到大优化，此时高性能依赖于服务器或者CPU的＂堆叠（集群）＂，我们会想一台服务器可以服务100人，两台服务器理想情况可以服务200人。

从一台服务器扩展到Ｎ台服务器具体如何操作使我们要关注的问题；

高可用依赖于【容错机制】，比如失败之后采取什么措施（Faile-Safe Fail-Over Fail-Fast等等），部分服务不可用之后的＂熔断＂措施等，当然备份也是高可用的一个具体措施（包括数据备份），哪怕是冷备：有的银行在采购的时候同样的设备会买两套，一套放在仓库里晾着，生怕天灾人祸而供货商货或者生产商不在继续生产该型号的设备，都是保证系统高可用的一周手段。

很多时候，提高系统可用性同样也能再一定程度上提高系统的性能，反之亦然：

我们需要增加设备来实现其中一套设备挂了还能使用另一套的方式来实现高可用（备份，无论是热备还是冷备，是高可用的必要条件）；同样增加设备，如果你能保证两套设备同时工作分担任务，他便能增加系统的性能（我觉得吞吐量或者处理能力这些词更适合这个场景）

实现高可用一般有两种机制／思路（欢迎补充）

a，保险丝熔断机制，这种机制在系统出现问题的时候将问题系统切出去，以免问题扩大化，航天飞机电路设计的时候大概会采用这种机制，当某一电路出现问题，为了避免问题蔓延需要断开问题系统；软件种也需要这种机制来：1，避免数据污染造成的修复时间增加，2，避免请求堆积造成大面积瘫痪；

b，线路（备份）切换机制

当系统出现异常，将备机自动或者手动切换过来的机制保证高可用的一种手段，切换的速度和度是系统可用性的一个标准。同样，在高性能集群，尤其是负载均衡集群中（负载均衡主要是为了＂高性能＂），将不同请求＂路由＂到不同的服务器，同时添加失败策略也能很好的增强＂系统可用性＂。

其实很好的＂监控机制＂和＂预案＂也能有助于系统可用性的提升，及时收到到问题的报告并快速做出响应能减少很多的客户抱怨和损失～

＂使用自动化＂机制也能很好的提高系统可用性；

高性能集群：＂负载均衡＂与＂分布式计算＂

从＂业务＂或者＂需要被解决的问题＂角度出发，我们为了得到高性能需要做的是＂拆分＂业务＂规模＂或者＂步骤＂：

，问题（规模）是不是可以分解；第二，问题是不是可以＂分步＂，将不同的步骤分布到不同的节点分别完成（不同节点完成不同的工作或者工作中的某一个步骤，这其实是我理解上的真正意义的分布式计算）；

点关注数据或者规模的＂水平切分＂，就是将＂一块大数据＂或者＂大量互不影响的请求＂分布到不同的节点处理，分别得到结果，然后进行汇总（可选）；

第二点倾向于将问题分成不同的步骤（业务垂直切分），比如我原本需要先洗菜，然后再炒菜的，但是我得想一想我能不能将洗菜和炒菜一起放在不同的地方做（当然这个例子必然是不行，对吧），这是分布式计算的核心思想。很多架构师喜欢大谈特谈的＂服务化＂就是将不同的业务拆分成不同的子系统，比如一个电商系统你可以拆分成＂用户系统＂＂库存管理＂＂订单系统＂甚至收藏夹，短信．．．只要你＂无底线＂，你可以将系统细化成任何粒度，当然你需要考虑的是随之带来的成本和风险；

由上面两点我们可以简单的将高性能集群分为＂负载均衡集群＂和＂分布式计算集群＂；负载均衡集群为了解决规模分解问题，也就是水平切分；分布式计算主要解决问题分步解决问题，也就是业务的垂直切分；

一般而言，做＂分布式计算＂比＂负载均衡＂成本更高，风险更大；当然前者也能带来其他的比如管理上的好处，不同的业务由不同的人员负责，简化了问题，界限明晰责任划分清晰，同样分布式计算可以提升资源占比优化能力和系统隔离能力（比如，如果收藏夹系统负载是订单系统的两倍，那么我们很简单的可以给收藏夹功能配置２倍的服务器（资源占比优化），我们认为收藏夹功能相对订单系统不是那么＂重要（收藏家可以挂，订单系统不能挂）＂，如果将收藏夹和订单放在一个系统里很可能会导致大量收藏占用大量的资源导致＂挣钱＂相关的订单业务（资源隔离）无法正常使用）［关于分布式计算的（服务化）的讨论会在下一篇文章中讨论］

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

以上讨论了：高可用，高性能（分布式／负载均衡）几个概念，

我们在讨论问题的时候需要知道我们在讨论什么，目标是什么，简单区分和统一一下概念是必要的，但不要死抠这些概念性的东西，很多时候目标不是单一的，这些东西相互杂糅在一起，界限很难明晰，你在思考问题的时候大致心里有个数就OK了～；实际上，这种分法只是我个人的理解存，在很多不严谨的地方，也没有面面俱到；

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

另外，我一直强调的是，在没有说明任何场景的情况下泛泛的讨论高性能和高可用是没有意义的；系统的性能可以在任何层面解决和提升，比如分层做缓存可以吗？同步转异步算吗？数据库优化算增加系统性能吗？优化代码逻辑算命？while写成for(;;)算吗?对系统资源（比如JS/CSS/图片）进行压缩算吗?对大图片进行切割滚动按需加载算吗？做个反爬虫系统或者加个waf防火墙阻挡一些垃圾流量算提高性能吗?包括我说的买高端的CPU和内存算不算？

其实在不同层面你大概有一万种提高系统性能的方法～所以本文，包括以后与之相关的讨论，不说说明都限定在＂从一台服务器扩展到Ｎ台服务器的情况＂；