初学开发者有个误区，认为业务开发的工程师是不需要了解所谓的服务高可用，认为平时开发压根就没有涉及到。
大错特错，只是你们缺乏这个高可用的意识认知。我想从小白的角度，从我工作经验和大家分享下。
所谓的高可用，就是在一些异常情况下，系统还可以继续提供服务，最大程度不影响用户体验。
1、为什么项目数据库一般有两台机器？
因为你的一台机器挂了，另外一台机器就可以备用，从而恢复服务的正常提供。这其实就是数据库的主从/主备模式，这里就是涉及到了存储高可用，通过增加机器或者数据的冗余方式，来实现服务的高可用。高可用性要求更好的，会进而采用集群的方式实现，而目的便是通过数据的冗余，实现高可用，只是实现的复杂度更高。
2、为什么程序代码中要有保底的逻辑存在？
场景：比如你请求某个依赖服务，而这个依赖服务有挂掉了。
此刻我们肯定想保证我们自己的业务正常，所以我们就可能用一些保底的数据返回给用户。这种其实就是服务降级手段实现高可用。当依赖的服务有故障时，我们可用采用退而求其次的方式依然提供服务；代码开发中常常有这种兜底的设计。
而服务降级的方式，也会在流量暴增、机器撑不住的情况下，在业务层对一些非核心功能进行降级出来，从减轻接口对整理系统的压力（mysql或者redis、或者机器性能），保证核心功能不受损。
3、为什么在一些高并发的业务场景（秒杀或者抢购）下，我们要限制用户的访问次数？
其实这就是服务限流的概念，限制用户对系统的访问流量，从而减少对系统的请求压力。
说说另一个例子，在我从事的公司，当一个服务的请求量达到了设定的阈值（一般由压测得出的支撑值）时，就要自动舍弃掉后面的流量，从而保证服务还能正常提供。
其实，在我们业务项目中，这些都是实现服务高可用，不管是存储高可用还是计算高可用，都体现在我们系统架构设计和代码设计，服务高可用一直存在我们开发日常中。有了这个意识认知后，你就会在设计代码和架构中，你就会多加思考服务的高可用性。
然而为什么一些项目需要很复杂的高可用设计，而一些项目则不需要过度设计？这其实就是和你的投入和产出相关，高可用带来的是复杂度更高、成本更大，所以一个服务不用做到很完美的高可用，可用依据成本和实现的难度决定。
