弹性伸缩 && 多机房

弹性伸缩

这种模式主要解决突发流量的到来，导致无法横向扩展或者横向扩展太慢，进而影响业务，全站崩溃的问题。这个模式是一种相对来说比较高级的技术，也是各个大公司目前都在研究、试用的技术。截至今日，有这种思想的架构师就已经是很不错了，能够拿到较高薪资，更别提那些已经实践过的，甚至实现了底层系统的那些，所以，你懂得......

这种模式的一般设计见下图：

如上图所示，多了一个弹性伸缩服务，用来动态的增加、减少实例。原理上非常简单，但是这个模式到底解决什么问题呢？先说说由来和意义。

每年的双 11、六一八或者一些大促到来之前，我们都会为大流量的到来做以下几个方面的工作:

1. 提前准备 10 倍甚至更多的机器，即使用不上也要放在那里备着，以防万一。这样浪费了大量的资源。

2. 每台机器配置、调试、引流，以便让所有的机器都可用。这样浪费了大量的人力、物力，更容易出错。

3. 如果机器准备不充分，那么还要加班加点的重复上面的工作。这样做特别容易出错，引来领导的不满，没时间回家陪老婆，然后你的老婆就......(自己想)

在双十一之后，我们还要人工做缩容，非常的辛苦。一般一年中会有多次促销，那么我们就会一直这样，实在是烦！

最严重的，突然间的大流量爆发，会让我们触不及防，半夜起来扩容是在正常不过的事情，为此，我们偷懒起来，要更多的机器备着，也就出现了大量的 cpu 利用率为 1%的机器。

我相信，如果你是老板一定很震惊吧！！！

哈哈，那么如何改变这种情况呢？请接着看

为此，首先把所有的计算资源整合成资源池的概念，然后通过一些策略、监控、服务，动态的从资源池中获取资源，用完后在放回到池子中，供其他系统使用。

具体实现上比较成熟的两种资源池方案是 VM、docker，每个都有着自己强大的生态。监控的点有 CPU、内存、硬盘、网络 IO、服务质量等，根据这些，在配合一些预留、扩张、收缩策略，就可以简单的实现自动伸缩。怎么样？是不是很神奇？深入的内容我们会在的码农原创的公众号文章中详细介绍。

总结一下这种模式的优缺点的了，如下：

优点：弹性、随需计算，充分优化企业计算资源。

缺点：应用要从架构层做到可横向扩展化改造、依赖的底层配套比较多，对技术水平、实力、应用规模要求较高。

多机房

这种模式主要解决不同地区高性能、高可用的问题。

  随着应用用户不断的增加，用户群体分布在全球各地，如果把服务器部署在一个地方，一个机房，比如北京，那么美国的用户使用应用的时候就会特别慢，因为每一个请求都需要通过海底光缆走上个那么一秒钟(预估)左右，这样对用户体验及其不好。怎么办？使用多机房部署。

这种模式的一般设计见下图：

如上图所示，一个典型的用户请求流程如下：

1. 用户请求一个链接 A

2. 通过 DNS 智能解析到离用户最近的机房 B

3. 使用 B 机房服务链接 A

是不是觉得很简单，没啥？其实这里面的问题没有表面这么简单，下面一一道来。

首先是数据同步问题，在中国产生的数据要同步到美国，美国的也一样，数据同步就会涉及数据版本、一致性、更新丢弃、删除等问题。

其次是一地多机房的请求路由问题，典型的是如上图，中国的北京机房和杭州机房，如果北京机房挂了，那么要能够通过路由把所有发往北京机房的请求转发到杭州机房。异地也存在这个问题。

      所以，多机房模式，也就是异地多活并不是那么的简单，这里只是起了个头，具体的有哪些坑，会在另一篇文章中介绍。

总结一下这种模式的优缺点的了，如下：

优点：高可用、高性能、异地多活。