加机器、切流量真的那么low吗

每当说到应对活动高峰流量的策略时，加机器这招总是会被认为很low，而同样，在另外一个场景中，当系统出现问题，通过切流量来快速恢复时，也会被认为很low，但这两个大招真的很low吗？

第一个点：加机器
首先说说加机器这回事，通常系统最早都是由一台应用机器再加一台或两台数据库机器组成，访问量高的情况下，自然最希望的就是靠加机器来解决。

简单分开看看，应用机器直接从一台变成两个，在技术上会有一些问题是要解掉的：
1. 应用的状态问题
例如最常见的会有用户的登录信息，也许还会有一些其他的状态信息，而如果不解决这些状态数据的问题，就会导致用户访问两台机器时不一致的现象；
2. 一台到两台组集群的问题
这里也将涉及到一堆的问题，例如负载均衡、健康检查等。

如果是数据库加机器呢，就更加复杂了，在技术上通常要解决分库分表的问题，如果不做分库，那么即使加数据库机器也分摊不了压力，分库通常是物理上的拆分，而如果是同一张表的压力，那么通常还需要做分表。

而随着应用机器数的增长，到数据库的连接池很容易成为瓶颈，这个时候通常会碰到有钱买机器，但不能加机器的致命现象，因此也是必须去解决掉的。

仅仅从上面这个最简单的过程就可以看到，系统要纯粹做到靠加机器就能支撑流量其实并不容易，是需要相当多的技术支撑的，就更不用说，当系统复杂到演变为下面的场景时：
当系统演变为由几百、几千个应用组成的时候，要做一次活动，请问到底要加多少机器，每个应用又加多少台呢；
加的机器一个机房都装不下的时候，那该怎么办呢；

很多时候架构演变要解决的主要问题就是怎么让系统能做到仅靠加机器就能支撑增长的流量，规模问题随着规模的数量级的变化，遇到的挑战会更加的大，从而也会导致系统的架构更加复杂。

这里还没有说加的机器实在太多了，成本该怎么控制住的问题，所以要做到加机器其实真心不low，一个极强的架构师，需要能根据人力的投入、规模增长的预期来权衡在一个架构版本中需要支撑到的规模级别，合理设计架构，从而确保在一个周期内可以仅靠加机器就解决，并同时又确保了在下一个周期到来前已经做好了各方面的技术积累和准备。

第二个点：切流量
有些人看到阿里这边碰到系统出问题的时候切流量这招，会觉得很low，但事实上我们简单来看下，切流量通常指的是把一个机房的流量切到另外一个机房，初级的版本是切流量到同城的另一个机房，这里要解决掉一些技术问题才能做到：
1. 数据库等的地址切换，当做流量切换时，通常是一个机房内出了不确定的故障，因此通常数据库也需要做好主备的切换，除了数据库外，可能还会有其他的一些指定的地址，这个时候都应该做到在不需要重启应用的情况下完成地址切换，这说实话如果在一开始系统简单的时候没有管理好这些地址类型的信息的话，等到系统复杂了再来做这个还是挺花时间的；
2. DNS disable vip，这里就是一个很容易被说到的点，DNS是没有健康检查的，因此当要拿掉一个机房的vip时，就必须等待dns生效，但其实这个是有一招可以来解掉的。

如果是异地的机房的流量切换，就更加复杂了，由于异地的情况下网络的延时会是一个大型分布式应用没法接受的，这个时候通常会启用异地多点写，而要做到这一点就已经非常不容易了，只有在做到这一点的情况下，才有得说异地机房切流量这一说，而在做到的情况下，怎么保障异地机房切流量时的数据的正确性是非常关键的点，感兴趣的可以看下我在 这片文章里讲的关于异地多活的技术点。

所以和加机器一样，我们可以看到切流量这招的背后也是需要有强大的技术支持的，我自己是认为切流量是提升系统可用性的极为有效的大招，在多个机房且可以快速切流量(要做到快其实也非常的难)的情况下，单个机房内无论出现任何故障，都可以仅仅靠切流量来应对，这对提升系统的可用时间是非常有帮助的。

欢迎大家讨论这里面讲的一些点，:)

=============================
欢迎关注微信公众号：hellojavacases
题目来源：http://www.bhmpics.com/wallpapers/low_battery_logo-1680×1050.jpg

关于此微信号：
分享Java问题排查的Case、Java业界的动态和新技术、Java的一些小知识点Test，以及和大家一起讨论一些Java问题或场景，这里只有Java细节的分享，没有大道理、大架构和大框架。

公众号上发布的消息都存放在http://hellojava.info上。