物联网模式下的多活数据中心架构认识与实践

标签：决定   规划设计   管理   bug   今天   one   toc   登录   这不   

     做互联网应用很重要的一点是要保证服务可用性，特别是某些业务更是需要7*24小时不间断的对外提供服务，任何停机、宕机都会引起大面积的用户不满。持续可用性是把业务服务化时一个需要考虑的重要指标，很多时候我们都会牺牲一些功能来换取可用性。如何保证服务的持续可用性，是每个互联网架构师一直坚持不懈追求的目标。在不同行业、不同场景下都有不同的解决方案。今天就与大家聊聊特来电在物联网模式下的多活数据中心架构上的认识和实践。

     特来电是全球首家提出了将车联网、充电网、互联网三网融合的充电桩生态公司，拥有近18万个充电桩，覆盖了全国240多个城市，服务客户不仅有ToC端、ToB端，还有很多的社会运营车辆。在如此复杂的客户群面前，充电网每时每刻都有大量的充电用户，无论在静寂无声的夜晚，还是在节假日，充电永不停歇。用户入眠的时候，是我们充电网络最繁忙的时刻，可以说特来电的充电网必须要有99.9%甚至更高的可用性，才能满足业务的需要。特来电的充电网与其他厂商的充电桩还不一样，其完全构建在物联网之上的。每个充电终端都是智能的，都在时时刻刻与云平台保持着通讯，下面是业务全景图。

     像其他互联网公司一样，我们做多活也是迫不得已的事情：

1. 所有业务放到一个篮子里面，当出现严重故障时，整个充电云服务将完全宕机，无法满足SLA99.9%甚至更高的要求。
2. 云平台架构完全是分布式的，部署结构复杂，各产品功能不支持灰度发布，产品新功能上限频繁，产品中隐藏很深的bug，很容易引起大面积的云服务故障。
3. 因为架构和一些技术实现，一个数据中心服务负载总会有上限，在特定的一些条件下，增加虚拟数量也无法提升系统的服务水平（比如：TCP连接数是有上限的）

     基于以上考虑，以及填过无数坑的教训，我们决定必须要建立多活数据中心。既然要建多数据中心，那就要看看业界的一些主流做法和技术趋势。在众多的解决方案中我们找到了两篇非常富有代表性的文章：微信高并发资金交易系统设计方案——百亿红包背后的技术支撑、首席架构师揭秘蚂蚁金服互联网IT运维体系实践。

     微信红包的主要思路是：

1. 系统垂直SET化，分而治之。各个SET之间相互独立，互相解耦。并且同一个红包ID的所有请求，包括发红包、抢红包、拆红包、查详情详情等，垂直stick到同一个SET内处理，高度内聚。通过这样的方式，系统将所有红包请求这个巨大的洪流分散为多股小流，互不影响，分而治之。
2. 逻辑Server层将请求排队，解决DB并发问题。使拆红包的事务操作串行地进入DB，只需要将请求在Server层以FIFO（先进先出）的方式排队，就可以达到这个效果。从而问题就集中到Server的FIFO队列设计上。
3. 双维度库表设计，保障系统性能稳定。当单表数据量达到一定程度时，DB性能会有大幅度下降，影响系统性能稳定性。采用冷热分离，将历史冷数据与当前热数据分开存储。系统在以红包ID维度分库表的基础上，增加了以循环天分表的维度，形成了双维度分库表的特色

     蚂蚁金服的主要思路是：

     蚂蚁金服提出了“LDC”架构，其核心思想是：把数据水平拆分的思路，向上提升到接入层、终端层，从接入层开始，把原来部署在一个IDC中的系统集群，进一步分成多个更细粒度的部署单元。

1. 每个单元对外是封闭的，在一个单元内的系统调用链路和各类存储访问是局部化在本单元内的；
2. 每个单元的实时数据是独立不共享的；会员或配置类信息等对延时性要求不高的数据全局共享；
3. 单元间的通信统一管控，尽量以异步化消息进行通信；同步调用则通过单元间代理方案实现。

     通过两家互联网巨头公司的方案可以看出一个共同的特点，就是期望通过分流的模式，把大流量切成小流量，从接入层开始，把原来部署在一个IDC中的系统集群，进一步分成多个更细粒度的部署单元 ，应对流量压力。这种架构下，不仅仅解决了流量天花板问题，而且在系统整体可用性上有了一个质的变化。即使系统不可用，也是少部分服务单元出问题，不会影响全国业务。这不正是我们梦寐以求的东西吗？

     基于此我们规划设计了特来电云平台的多活系统架构。总体思路是分为三步走：

     第一步：中间件、技术平台要进行适应性改造，以支持多数据中心、多Set化的架构。不管后续部署结构如何变化，技术平台和组件都要可适应。下面是技术平台和中间件的架构图，图中的五个平台都需要改造。

     第二步：架设两个数据中心，每个数据中心部署一个服务单元，两个数据中心进行引流，验证总体架构和设想，实现双活架构。核心思路：

1. 上海、北京异地两数据中心双活，部分充电桩分流到上海数据中心。
2. 用户充电时，根据集控所在数据中心，下达充电指令。非充电业务，默认访问主数据中心
3. 当北京数据中心或上海数据中心宕机时，通过流量管理器自动切换到另一个数据中心。提升系统可用性。

     第三步：架设多个数据中心、多个服务单元，按照地区对流量进行切割，真正实施多活架构。核心思路：

1. 建立多活数据中心，每个数据中心多个服务单元。
2. 充电桩在接入云服务时，根据所在地区自动引流到对应的服务单元。
3. 用户充电时，根据登录地区，由流量管理器映射到对应的服务单元

     通过近半年的努力，我们不仅完成了第一步的工作，而且还完成了第二步规划。在2017-6-27日，上海数据中心正式激活并引流成功。至此，我们终于在多活架构上迈出了最坚实的一步。这标志着，我们不仅仅具备了完善了技术架构，而且这个架构是可以复制的、多活的，终于有可能把整个系统可用性做到100%。

      架构的变迁会随着业务的变化而变化，不同阶段有不同的需求。规划了这些、做了这些，也是只万里长征的第一步。2020年后才会真正迎来新能源汽车爆发式发展，届时会有50%以上的电动汽车在我们的平台下充电，每天都有可能数千万度电甚至数亿电在特来电的充电网上发生。架构的升级将会继续，会越来越快，也会越来越复杂，但是我们乐在其中，期望志同道合的战友一起战斗！！！

物联网模式下的多活数据中心架构认识与实践

标签：决定   规划设计   管理   bug   今天   one   toc   登录   这不   

原文地址：http://www.cnblogs.com/vveiliang/p/7156847.html