当年，我们是怎么平滑上云的？

今天，当年简单的滑上聊聊架构方案，我们是当年如何平滑进行机房迁移的。

【1】核心问题一，滑上被迁移的当年系统是一个什么样的架构呢?

上图是一个典型的互联网单机房系统架构：

上游是客户端，PC浏览器或者APP; 然后是滑上站点接入层，做了高可用集群; 接下来是当年服务层，服务层又分为两层，滑上业务服务层和基础服务层，当年也都做了高可用集群; 底层是滑上数据层，包含缓存与数据库;

该单机房分层架构，当年所有的滑上应用、服务、当年数据是滑上部署在同一个机房，其架构特点是当年“全连接”：

站点层调用业务服务层，业务服务复制了多少份，上层就要连接多少个服务; 业务服务层调用基础服务层，基础服务复制了多少份，上层就要连多少个服务; 服务层调用数据库，源码下载数据库冗余了多少份，就要连多少个数据库;

例如：站点接入层某一个应用有2台机器，业务服务层某一个服务有4台机器，那肯定是上游的2台会与下游的4台进行一个全相连。

全连接如何保证系统的负载均衡与高可用?

全连接架构的负载均衡与高可用保证，是通过连接池实现的。不管是NG连web，web连业务服务，业务服务连接基础服务，服务连接数据库，都是这样。

划重点1：单机房架构的核心是“全连接”。

【2】核心问题二，机房迁移的目标是什么?

单机房架构的特点是“全连接”，机房迁移要做一个什么样的事情呢?

如上图：迁移之前，系统部署在机房A(M6)内，是网站模板单机房架构。迁移之后，系统部署在机房B(阿里云)内，仍然是单机房架构，只是换了一个机房而已。

有什么好的迁移方案?最容易想到的一个方案，把所有服务在新机房全都部署一套，然后把流量切过来。

这个方案存在什么问题?问题1：得停止服务，丧失了可用性。

问题2：即使可以接受停服，当有几百台机器，几千个系统的时候，“部署一套，切流量”一步成功的概率很低，风险极高，因为系统实在太复杂了。

机房迁移的难点，是“平滑”迁移，整个过程不停服务，并能够“蚂蚁搬家”式迁移。

划重点2：机房迁移方案的设计目标是：

平滑迁移，不停服务; 可以分批迁移; 随时可以回滚;

【3】核心问题三，云服务器提供商暂时性的多机房架构能否避免?

如果想要平滑的迁移机房，不停服务，且逐步迁移，迁移的过程中，势必存在一个中间过渡阶段，两边机房都有流量，两边机房都对外提供服务，这就是一个多机房的架构。

迁移过程中，多机房架构不可避免。

前文提到的单机房架构，是一个“全连接”架构，能不能直接将单机房的全连架构套用到多机房呢?

如果直接将单机房“全连接”的架构复制到多机房，会发现，会有很多跨机房的连接：

站点层连接业务服务层，一半的请求跨机房; 业务服务层连接基础服务层，一半的请求跨机房; 基础服务层连数据层，一半的请求跨机房;

大量的跨机房连接会带来什么问题?同机房连接，内网的性能损耗几乎可以忽略不计。

一旦涉及到跨机房的访问，即使机房和机房之间有专线，访问的时延可能增加到几毫秒，甚至几十毫秒(跟机房间光纤距离有关)。

举个例子，假设户访问一个页面，需要用到很多数据，这些数据可能需要20次相互调用(站点调用服务，服务调用缓存和数据库等)，如果有一半调用跨机房(10次调用)，机房之间延迟是20毫秒，因为跨机房调用导致的请求迟延就达到了200毫秒，这个是绝不能接受的。

划重点3：想要平滑的实施机房迁移，临时性的多机房架构不可避免。

小结：

单机房架构的核心是“全连接”。 机房迁移方案的设计目标是：平滑迁移，不停服务;可以分批迁移;随时可以回滚; 想要平滑的实施机房迁移，临时性的多机房架构不可避免;

多机房架构应该如何设计?系统迁移步骤又该如何?今天累了，且听明天分解。

【本文为专栏作者“58沈剑”原创稿件，转载请联系原作者】

戳这里，看该作者更多好文