细谈八种架构设计模式及其优缺点概述( 五 ) _架构设计

文章插图

如上图所示，多了一个弹性伸缩服务，用来动态的增加、减少实例。原理上非常简单，但是这个模式到底解决什么问题呢？先说说由来和意义。
每年的双11、六一八或者一些大促到来之前，我们都会为大流量的到来做以下几个方面的工作:
提前准备10倍甚至更多的机器，即使用不上也要放在那里备着，以防万一。这样浪费了大量的资源。
每台机器配置、调试、引流，以便让所有的机器都可用。这样浪费了大量的人力、物力，更容易出错。
如果机器准备不充分，那么还要加班加点的重复上面的工作。这样做特别容易出错，引来领导的不满，没时间回家陪老婆，然后你的老婆就......(自己想)
在双十一之后，我们还要人工做缩容，非常的辛苦。一般一年中会有多次促销，那么我们就会一直这样，实在是烦！
最严重的，突然间的大流量爆发，会让我们触不及防，半夜起来扩容是在正常不过的事情，为此，我们偷懒起来，要更多的机器备着，也就出现了大量的cpu利用率为1%的机器。
我相信，如果你是老板一定很震惊吧！！！
哈哈，那么如何改变这种情况呢？请接着看
为此，首先把所有的计算资源整合成资源池的概念，然后通过一些策略、监控、服务，动态的从资源池中获取资源，用完后在放回到池子中，供其他系统使用。
具体实现上比较成熟的两种资源池方案是VM、Docker，每个都有着自己强大的生态。监控的点有CPU、内存、硬盘、网络IO、服务质量等，根据这些，在配合一些预留、扩张、收缩策略，就可以简单的实现自动伸缩。怎么样？是不是很神奇？深入的内容我们会在的码农原创的公众号文章中详细介绍。
该总结一下这种模式的优缺点的了，如下：

优点：弹性、随需计算，充分优化企业计算资源。
缺点：应用要从架构层做到可横向扩展化改造、依赖的底层配套比较多，对技术水平、实力、应用规模要求较高。

十、多机房模式这种模式主要解决不同地区高性能、高可用的问题。
随着应用用户不断的增加，用户群体分布在全球各地，如果把服务器部署在一个地方，一个机房，比如北京，那么美国的用户使用应用的时候就会特别慢，因为每一个请求都需要通过海底光缆走上个那么一秒钟(预估)左右，这样对用户体验及其不好。怎么办？使用多机房部署。
这种模式的一般设计见下图：

文章插图

如上图所示，一个典型的用户请求流程如下：
用户请求一个链接A
通过DNS智能解析到离用户最近的机房B
使用B机房服务链接A
是不是觉得很简单，没啥？其实这里面的问题没有表面这么简单，下面一一道来。
首先是数据同步问题，在中国产生的数据要同步到美国，美国的也一样，数据同步就会涉及数据版本、一致性、更新丢弃、删除等问题。
其次是一地多机房的请求路由问题，典型的是如上图，中国的北京机房和杭州机房，如果北京机房挂了，那么要能够通过路由把所有发往北京机房的请求转发到杭州机房。异地也存在这个问题。
所以，多机房模式，也就是异地多活并不是那么的简单，这里只是起了个头，具体的有哪些坑，会在另一篇文章中介绍。
该总结一下这种模式的优缺点的了，如下：