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

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

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

Image(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维度分库表的基础上,增长了以循环天分表的维度,造成了双维度分库表的特点

Image(10)

     蚂蚁金服的主要思路是:异步

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

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

Image(11)

     经过两家互联网巨头公司的方案能够看出一个共同的特色,就是指望经过分流的模式,把大流量切成小流量,从接入层开始,把原来部署在一个IDC中的系统集群,进一步分红多个更细粒度的部署单元 ,应对流量压力。这种架构下,不只仅解决了流量天花板问题,并且在系统总体可用性上有了一个质的变化。即便系统不可用,也是少部分服务单元出问题,不会影响全国业务。这不正是咱们求之不得的东西吗?高并发

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

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

Image(12)

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

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

Image(13)

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

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

Image(14)

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

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

相关文章
相关标签/搜索