1、高可用：
入口层：
通常指Nginx和Apache等层面的东西，负责应用（不管是Web应用还是移动应用）的服务入口。我们通常会将服务定位在一个IP，如果这个IP对应的服务器当机了，那么用户的访问肯定会中断。
此时，可以用keepalived来实现入口层的高可用。
例如，机器A 的IP是 1.2.3.4，机器 B 的 IP 是 1.2.3.5, 那么再申请一个 IP 1.2.3.6（称为心跳IP）， 平时绑定在机器A上，如果A当机，IP会自动绑定在机器B上；
如果B宕机，IP会自动绑定在机器A上。对于这种形式，我们将DNS绑定到心跳IP上，即可实现入口层的高可用。
业务层：
业务层通常是由Java等写的逻辑代码构成的，需要依赖于后台数据库及一些缓存层面的东西。如何实现业务层的高可用呢？最核心的就是，业务层不要有状态，将状态分散到缓存层和数据库。
1.Session：用户登录相关的数据，但好的做法是将session放在数据库里，或者一个比较稳定的缓存系统中。
2.缓存：在访问数据库时，如果一个查询很慢，就希望将这些结果暂时放到进程里，下次再做查询时就不用再访问数据库了。
一个简单的原则就是业务层不要有状态。在业务层没有状态时，一台业务层服务器宕掉了之后，Nginx/Apache会自动将所有的请求打到另外一台业务层的服务器上。由于没有状态，两台服务器没有任何差异，所以用户完全感受不到。
如果把session放在业务层里面的话，那么面临的问题是，这个用户以前是登录在一台机器上的，这个进程死掉后，用户就会被登出了。
缓存层：
非常简单的架构里是没有缓存这个概念的。如果系统的访问量较大，就可以考虑用缓存层来挡住绝大部分服务请求，提升系统整体的容量。
缓存层做高可用一个简单的方法就是，将缓存层分得细一点儿。
缓存层就一台机器的话，那么这台机器当了以后，所有应用层的压力就会往数据库里压，数据库扛不住的话，整个网站（或应用）就会随之当掉。
而如果缓存层分在四台机器上的话，每台只有四分之一，这台机器宕掉了以后，也只有总访问量的四分之一会压在数据库上面，数据库能扛住的话，网站就能很稳定地等到缓存层重新起来。
数据库层：
在数据库层面实现高可用，通常是在软件层面来做。例如，MySQL有主从模式(Master-Slave)，还有主主模式(Master-Master)都能满足需求。MongoDB也有ReplicaSet的概念，基本都能满足大家的需求。
总之，要想实现高可用，需要做到这几点：入口层做心跳，业务层服务器无状态，缓存层减小粒度，数据库做一个主从模式。
2.可伸缩性：
入口层：
在入口层实现伸缩性，可以通过直接水平扩机器，然后DNS加IP来实现。
业务层：
业务层的伸缩性如何实现?与做高可用时的解决方案一样，要实现业务层的伸缩性，保证无状态是很好的手段。此外，加机器继续水平部署即可。
缓存层
比较麻烦的是缓存层的伸缩性，最简单粗暴的方式是什么呢？趁着半夜量比较低的时候，把整个缓存层全部下线，然后上线新的缓存层。
新的缓存层启动起来之后，再等这些缓存慢慢预热。当然这里一个要求，你的数据库能抗住低估期的请求量。如果扛不住呢？取决于缓存类型，下面我们先可以将缓存的类型区分一下。
数据库
在数据库层面实现伸缩，方法很多，文档也很多，此处不做过多赘述。大致方法为：水平拆分、垂直拆分和定期滚动。
总之，我们可以在入口层、业务层面、缓存层和数据库层四个层面，使用刚才介绍的方法和技术实现系统高可用和可伸缩性。
具体为：在入口层用心跳来做到高可用，用平行部署来伸缩；在业务层做到服务无状态；在缓存层，可以减小一些粒度，以方便实现高可用，使用一致性Hash将有助于实现缓存层的伸缩性；
数据库层的主从模式能解决高可用问题，拆分和滚动能解决可伸缩问题。
