分布式架构下的可伸缩设计
写在前面：
- 你好，欢迎你的阅读！
- 我热爱技术，热爱分享，热爱生活， 我始终相信：技术是开源的，知识是共享的！
- 博客里面的内容大部分均为原创，是自己日常的学习记录和总结，便于自己在后面的时间里回顾，当然也是希望可以分享自己的知识。目前的内容几乎是基础知识和技术入门，如果你觉得还可以的话不妨关注一下，我们共同进步！
- 除了分享博客之外，也喜欢看书，写一点日常杂文和心情分享，如果你感兴趣，也可以关注关注！
- 微信公众号：傲骄鹿先生
可伸缩性/可扩展性(Scalable/scalability)
可伸缩性(可扩展性)是一种对软件系统计算处理能力的设计指标，高可伸缩性代表一种弹性，在系统扩展成长过程中，软件能够保证旺盛的生命力，通过很少的改动甚至只是硬件设备的添置，就能实现整个系统处理能力的线性增长，实现高吞吐量和低延迟高性能。
可伸缩性和纯粹性能调优有本质区别， 可伸缩性是高性能、低成本和可维护性等诸多因素的综合考量和平衡，可伸缩性讲究平滑线性的性能提升，更侧重于系统的水平伸缩，通过廉价的服务器实现分布式计算；而普通性能优化只是单台机器的性能指标优化。他们共同点都是根据应用系统特点在吞吐量和延迟之间进行一个侧重选择，当然水平伸缩分区后会带来CAP定理约束。
软件的可扩展性设计非常重要，但又比较难以掌握，业界试图通过云计算或高并发语言等方式节省开发者精力，但是，无论采取什么技术，如果应用系统内部是铁板一块，例如严重依赖数据库，系统达到一定访问规模，负载都集中到一两台数据库服务器上，这时进行分区扩展伸缩就比较困难，正如Hibernate框架创建人Gavin King所说：关系数据库是最不可扩展的。
性能和扩展性
-
什么是性能问题？ 如果你的系统对于一个用户访问还很慢，那就是性能问题；
-
什么是扩展性问题？ 如果你的系统对一个用户来说是快的，但是在用户不断增长的高访问量下就慢了。
延迟和吞吐量
延迟和吞吐量是衡量可扩展性的一对指标，我们希望获得低延迟和高吞吐量的系统架构。所谓低延迟，也就是用户能感受到的系统响应时间，比如一个网页在几秒内打开，越短表示延迟越低，而吞吐量表示同时有多少用户能够享受到这种低延迟，如果并发用户量很大时，用户感觉网页的打开速度很慢，这意味着系统架构的吞吐量有待提高。
扩展性的目标是用可接受的延迟获得最大的吞吐量。可靠性(可用性)目标：用可接受的延迟获得数据更新的一致性。
如何实现可伸缩
入口层
在入口层实现伸缩性，可以通过直接水平扩机器，然后DNS加IP来实现。但需要注意，尽管一个域名解析到几十个IP没有问题，但是很多浏览器客户端只会使用前几个IP,部分域名供应商对此有优化(如每次返回的IP顺序随机)，但这个优化效果不稳定。
推荐的做法是使用少量的Nginx机器作为入口，业务服务器隐藏在内网(HTTP类型的业务这种方式居多)。另外，也可以把所有IP下发到客户端，然后在客户端做一些调度(特别是非HTTP型的业务，如游戏、直播)。
业务层
业务层的伸缩性如何实现?与做高可用时的解决方案一样，要实现业务层的伸缩性，保证无状态是很好的手段。此外，加机器继续水平部署即可。
缓存层
比较麻烦的是缓存层的伸缩性，最简单粗暴的方式是什么呢？趁着半夜量比较低的时候，把整个缓存层全部下线，然后上线新的缓存层。新的缓存层启动起来之后，再等这些缓存慢慢预热。当然这里一个要求，你的数据库能抗住低估期的请求量。如果扛不住呢？取决于缓存类型，下面我们先可以将缓存的类型区分一下。
- 强一致性缓存：无法接受从缓存拿到错误的数据 (比如用户余额，或者会被下游继续缓存这种情形)
- 弱一致性缓存：能接受在一段时间内从缓存拿到错误的数据 (比如微博的转发数)。
- 不变型缓存：缓存key对应的value不会变更 (比如从SHA1推出来的密码， 或者其他复杂公式的计算结果)。
那什么缓存类型伸缩性比较好呢？弱一致性和不变型缓存的扩容很方便，用一致性Hash即可；强一致性情况稍微复杂一些，稍后再讲。使用一致性Hash，而不用简单Hash的原因是缓存的失效率。如果缓存从9台扩容到10台，简单Hash 情况下90%的缓存会马上失效，而如果使用一致性Hash情况，只有10%的缓存会失效。
那么，强一致性缓存会有什么问题？第一个问题是，缓存客户端的配置更新时间会有微小的差异，在这个时间窗内有可能会拿到过期的数据。第二个问题是，如果扩容之后再裁撤节点，会拿到脏数据。比如 a 这个key之前在机器1，扩容后在机器2，数据更新了，但裁撤节点后key回到机器1，这时候就会拿到脏数据。
要解决问题2比较简单，要么保持永不减少节点，要么节点调整间隔大于数据的有效时间。问题1可以用如下的步骤来解决：
- 两套hash配置都更新到客户端，但仍然使用旧配置；
- 逐个客户端改为只有两套hash结果一致的情况下会使用缓存，其余情况从数据库读，但写入缓存；
- 逐个客户端通知使用新配置。
Memcache 设计得比较早，导致在伸缩性高可用方面的考虑得不太周到。Redis 在这方面有不少改进，特别是 @ngaut 团队基于 redis 开发了 codis 这个软件，一次性地解决了缓存层的绝大部分问题。推荐大家考察一下。
数据库
在数据库层面实现伸缩，方法很多，文档也很多，此处不做过多赘述。大致方法为：水平拆分、垂直拆分和定期滚动。
总之，我们可以在入口层、业务层面、缓存层和数据库层四个层面，使用刚才介绍的方法和技术实现系统高可用和可伸缩性。具体为：在入口层用心跳来做到高可用，用平行部署来伸缩；在业务层做到服务无状态；在缓存层，可以减小一些粒度，以方便实现高可用，使用一致性Hash将有助于实现缓存层的伸缩性；数据库层的主从模式能解决高可用问题，拆分和滚动能解决可伸缩问题。