今天简单说一下架构方案，我们是如何顺利迁移机房的。[1]核心问题1，迁移后的系统是什么架构？上图是典型的互联网单间系统架构：上游为客户端、PC浏览器或APP；然后是站点接入层，接下来要做的是服务层，分为两层，业务服务层和基础服务层，都有高可用集群；底层是数据层，包括缓存和数据库；单机房是分层架构，所有应用、服务、数据都部署在同一个机房??，其架构特点是“全连接”：站点层调用业务服务层，业务服务多少份被复制，有多少服务连接到上层；业务服务层调用基础服务层，基础服务复制多少份，上层必须接入多少服务；服务层调用数据库，有多少副本的数据库是冗余的，必须连接多少个数据库；举个例子：站点访问层的一个应用有2台，如果业务服务层某个服务有4台机器，那肯定是上游的2台机器和下游的4台机器全连接。全连接如何保证系统的负载均衡和高可用？全连接架构的负载均衡和高可用保障是通过连接池来实现的。无论是NG连接web，web连接业务服务，业务服务连接基础服务，服务连接数据库，都是如此。重点一：单体机房架构的核心是“全连接”。[2]核心问题2，机房迁移的目标是什么？单体机房架构的特点是“全连接”，机房迁移应该做哪些事情？如上图所示：迁移前，系统部署在A机房（M6）内，为单机房结构。迁移后系统部署在B机房（阿里云），仍然是单机房结构，只是换了一个机房。什么是好的迁移计划？最容易想到的方案就是把所有业务都部署在新机房，然后切流量。这个解决方案有什么问题？问题1：必须停止服务并且失去可用性。问题2：即使服务关闭可以接受，但是当有几百台机器和几千个系统时，第一步“部署一套，切换流量”成功的概率很低，风险极高，因为系统太复杂了。机房迁移的难点在于“平滑”迁移、全程不间断服务、“蚂蚁搬家”迁移。要点2：机房迁移方案的设计目标是：平滑迁移，不间断服务；分批迁移；随时回滚；[3]核心问题3、临时多机房架构能否避免？如果想要机房的平滑迁移，不间断服务，逐步迁移，在迁移的过程中，必须有一个中间过渡阶段，两个机房都有流量，两个机房都对外提供服务，这是一个多机房架构。在迁移过程中，多机房架构是不可避免的。上面提到的单机房架构是一种“全连接”的架构。单机房的全连接架构能否直接应用于多机房？如果直接把单机房的“全连接”架构复制到多机房，你会发现，会有很多跨机房的连接：站点层连接业务服务层，一半跨机房的请求；业务服务层对接基础服务层，一半请求跨机房；基础服务层连接数据层，一半请求跨机房；跨机房连接会带来哪些问题？在同一个机房??连接时，内网的性能损失几乎可以忽略不计。一旦涉及跨机房访问，即使机房之间有专线，访问时延也可能增加到几毫秒，甚至几十毫秒（与机房光纤距离有关）。例如，假设用户访问一个页面并需要使用大量数据。这些数据可能需要20次相互调用（站点调用服务、服务调用缓存和数据库等），如果一半调用是跨机房（10次调用），则机房请求之间的延迟为20毫秒，因为跨机房调用造成的请求延迟达到200毫秒，这是绝对不能接受的。重点3：要想顺利实施机房迁移，临时多机房架构是必然的。总结：单体机房架构的核心是“全连接”。机房迁移方案的设计目标是：平滑迁移，不间断服务；批量迁移；随时回滚；要想顺利实施机房迁移，临时多机房架构是必然的；多机房架构应该如何设计？系统迁移步骤呢？今天累了，明天听分解。【本文为专栏作者《58神剑》原创稿件，转载请联系原作者】点此阅读更多该作者好文
