高可用的一些思考和理解

本文来源公众号：匠心零度

在目前的互联网大时代，在高并发等冲击下，还必须保证服务高可用，若是服务不高可用那么意味着：

• 系统不是7*24小时提供服务，那么用户体验就特别差了，可能用户下次不用了，留不住用户。
• 当系统不可用的时候，对公司的形象是有所影响的，BAT相似这种技术都是象征的。
• 最重要的一点，当系统不可用的时候，直接损失就是金钱！！！基本都是秒算损失的，依稀记得2015年5月28日携程网瘫痪事件，按照携程一季度财报公布的数据，携程宕机的损失为平均每小时106.48万美圆。

高可用是很是复杂的，本身水平有限，并不能涵盖那么多，只能说是本身对高可用的一些思考和理解。

那么怎么使系统高可用呢？

咱们不能让服务器不挂，让服务不挂，那么怎么样让这种必败的局面不会有问题呢，就是能够挂，服务能够坏，那么怎么让系统还能够提供服务呢？

首先若是机器有不少，服务有不少，就算坏了一部分也没有问题啊，必败的局面获得的解决。下面进行一步一步剖析，若是机器里面存储了特定值，那么就不能扩展，必须是用挂的那台机器，那么这个是不行的，机器问题好解决，相同的配置替代是容易的，那么应用服务也是相似，应用服务能够不存储状态有关的值在任何机器而本身内部不会有存储一些特定的特征数据，若是有就没办法很容易的扩展，只有当每一个主件都是同样的时候，无任何差别，咱们才好替换，容易扩展，那么这个就叫着服务的无状态化。

假如目前服务已是无状态化了，那么如何让系统动态的感知到服务挂了呢？否则请求仍是回去到挂的那台机器，怎么转移到新的机器呢？那么可能就须要服务发现与注册了。

若是达到了上面的状况，应对通常的状况基本已经够了，可是互联网是复杂的，刚刚说的机器坏，服务坏了的问题，那么若是网络出现短暂不通由于怎么办呢？

因此服务之间应该有心跳的检测，来按期看看是否可通（机器坏了，服务挂了，网络不通了）反正就是不可达了。这种状况经过服务注册与发现便可解决，可是有时候网络是闪断下那么在那种特定的状况呢？好比刚刚a服务已经把请求发送给了b服务，b服务已经接收到请求了，那么这个时候突然网络断了，可是b服务进行把逻辑处理作完成了，可是a服务反应的就是没有响应，前台超时了，那么再一次触发下，那么若是b服务把以前的逻辑再作一遍是否存在问题呢？ 好比支付，已经付款200元，难道再付款200元吗？这里须要提到一个幂等性的设计概念，什么是幂等呢，就是屡次执行结果都同样，若是有幂等性设计那么就不怕这种状况了，在没有获得反馈状况重试便可，也不会出现问题。

达到上面说的这些就是应对机器坏了，服务挂了，网络不通或者闪断等状况已经基本没有什么大问题了，那么目前互联网都是高并发，那么在高并发的状况，如何来提升系统的能力的？

就和搬东西同样，一我的慢，能够多来点人一块儿帮东西，因为上面的架构是能够添加机器，服务的，那么很容易想到的就是多来点机器和服务。那么这样必定比机器少要快的，好比有5台机器，那么不少请求过来了，用什么策略让他们分摊到不一样的机器呢？经过设备，经过一些软件层面，可是其中必定有服务发现注册，否则没办法动态知道节点变化，还有就是对一些信息的控制，黑白名单，访问频率等。不少时候，加机器可能看起来比较low，可是有时候的确比较有效，可是也不能一味的加机器，有些状况加机器是解决不了的了。

机器多了的确快了，若是在服务里面有一个阻塞方法，那么就算服务在多也没用，因此必须注意关于服务超时的问题，因为服务是幂等的，就算再次执行也没有任何关系，有了超时就不会卡好久影响到后面的服务了（下游服务宕机了，线程死锁了，下游服务忙等等）。

关于同步，异步的一些设计模式，在有些必须顺序执行的业务场景就必需要使用同步了，在非必须的这种场景那么用异步必定比同步处理的并发量要大（因为中间件经历不少步骤，因此从单个请求的总时间来看并不必定有同步的快，可是从一个宏观的角度来看提升并发的请求会大不少了）。简单聊聊异步，在一个服务内部，异步那么就须要提到多线程了，多线程不少有点提升cpu利用率，提升系统性能，可是实现成本要高不少了，那么不一样服务直接的如何异步呢，消息中间件了，（消息中间件很难，第一要保证真异步，第二须要保证不重不漏，就这2点真的很难，特别是在大数据状况下），特别是网络I/O须要重点考虑异步模型，不过Netty封装的挺好了。

因为每一个机器，或者服务都是有上限的，若是量一下泄洪式的过来而且不是他的能力能够处理的，那么该若是解决呢？

该问题在生活中处处可见，刚恰好国庆回家、出去玩，随处可见该事项体现，好比过安检的时候，有一个保安专门拿一个牌看人差很少了，让后面的人等，等处理的查很少了，在让后面的人进行，以后相似在等。，可是若是有级别高的，或者车快发车了，通常让他们先过，在软件架构里面应该叫限流、服务降级，通常有两种控制策略（1，拒绝部分请求，2，关闭部分服务）可能以前的时候都提到了关闭部分服务，不过如今不推荐了（毕竟也是公司技术实力的体现），目前重点说的是关于拒绝部分请求，关于这块的控制在那里添加？就是那块须要控制，应该每层都须要加下该控制。

依稀记得行业里面有句话，高并发、高可用三大法宝：限流、降级、缓存，关于缓存，你们应该接触的最多，互联网业务特色就是读多写少，那么就很是适合使用缓存了。

因为因此请求在一个服务，扩展仍是很差扩展，并且统一服务里面有些调用特别多，有些调用就比较少，由于继续划分，继续拆，这样仍是能够再次提升并发。

微服务了，微服务概念不少，首先提到的就是搞垂直拆分，很容易理解，以后垂直业务可能也不少，还须要继续水平拆分，（这里一切的拆分依据都是根据本身公司的业务，理解越深才的越好）。

经过上面的这些，服务能够挂，机器能够坏，网络不通或者闪断的问题都解决了，而且能够提升并发，尽最大努力来让服务高可用。那么因为这么作带来了不少问题，因此须要把这些修改带来的问题解决：

• 之前在一个服务里面，对于事务的控制很容易，那么微服务以后，事务的控制就显的特别重要了，不少时候咱们不能强一致性，可是咱们能够作到最终一致性就是能够的。
• 调用链监控也就显得特别重要了，一块儿的还有预警也特别重要了。
• 分布式日志也显得特别重要了。
• 高级的jstack、Btrace在真实环境就是特别重要的。

结束语

本人水平有限，不免会有一些理解误差的地方，若是发现，欢迎各位积极指出，感谢！！！