在双十一之后，我们还要人工做缩容，非常的辛苦 。一般一年中会有多次促销，那么我们就会一直这样，实在是烦！
最严重的，突然间的大流量爆发，会让我们猝不及防，半夜起来扩容是正常不过的事情，为此，我们偷懒起来，要更多的机器备着，也就出现了大量CPU利用率为1%的机器 。
相信我，如果你是老板一定很震惊吧！
哈哈，那么如何改变这种情况呢？请接着看
为此，首先把所有的计算资源整合成资源池的概念，然后通过一些策略、监控、服务，动态的从资源池中获取资源，用完后再放回到池子中，供其他系统使用 。具体实现上比较成熟的两种资源池方案是VM、Docker，每个都有着自己强大的生态 。监控点有CPU、内存、硬盘、网络IO、服务质量等，根据这些，再配合一些预留、扩张、收缩策略，就可以简单的实现自动收缩 。怎么样？是不是很神奇？深入的内容我会在后面的文章中详细的讲述，该总结以下这种模式的优缺点了 。如下：
优点：弹性、随需计算，充分优化企业计算资源 。
缺点：应用要从架构层做到可横向扩展化改造、依赖的底层配套比较多，对技术水平、实力、应用规模要求比较高 。
十、多机房模式这种模式主要解决不同地区高性能、高可用的问题
随着应用用户的不断增加，用户群体分布在全球各地，如果把服务器都部署在一个地方，一个地方，比如北京，那么美国的用户使用应用的时候会特别慢，因为每个请求都需要通过海底光缆走上那么一秒钟左右，这样对用户体检及其不好，怎么办？使用多机房部署 。这种模式一般设计如下图所示：
文章插图
如上图所示，一个典型的用户请求流程如下：
用户请求一个连接A
通过DNS智能解析到离用户最近的机房B
使用B机房服务连接A
是不是觉得很简单，没啥？其实这里面的问题没有表面这么简单，下面一一道来，
首先是数据同步问题，在中国产生的数据要同步到美国，美国的也一样，数据同步就会涉及数据版本、一致性、更新丢弃、删除等问题 。
其次是一地多机房的请求路由问题，典型的是如上图，中国的北京机房和杭州机房，如果北京机房挂了，那么要能够通过路由把所有发往北京机房的请求转发到杭州机房，异地也存在这个问题 。
所以，多机房模式，也就是异地多活并不是那么的简单，这里只是起了个头，具体的有哪些坑，会在后面的文章中介绍 。
该总结以下这种模式的优缺点了，如下：
优点：高可用、高性能、异地多活 。
缺点：数据同步、数据一致性、请求路由 。
推荐阅读
- 处理器|打破x86/ARM垄断：第三大CPU架构RISC-V的春天来了
- gRPC入门知识
- Node.js架构剖析
- 健身训练后，加快身体恢复的8种方法
- 架构师修炼之微服务部署 - 深入理解Docker镜像
- 扩展我们的AWS基础架构
- SaaS 架构设计的参考指南
- 高并发秒杀系统架构解密，不是所有的秒杀都是秒杀！
- 适合春天饮用的8种花茶,花茶不只是女人专属
- 8种运动能“治”病，一动见效!