|
|
51CTO旗下网站
|
|
移动端
创建专栏

当年,我们是怎么平滑上云的?

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

作者:58沈剑|2020-01-21 21:48

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

【1】核心问题一,被迁移的系统是一个什么样的架构呢?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【3】核心问题三,暂时性的多机房架构能否避免?

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

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

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

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

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

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

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

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

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

小结:

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

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

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

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

【编辑推荐】

  1. 为什么90%的“码农”做不了“架构师”?
  2. 苏宁砍价团高可用、高并发架构实践
  3. 互联网架构,究竟为什么需要配置中心?
  4. 宜信微服务架构落地及其演进|分享实录
  5. 架构选型,究竟啥时候选Redis?
【责任编辑:赵宁宁 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢