2017-05-12 21:53:30 horsefoot 阅读数 22195
  • 平台分布式调度系统的演进

    深度介绍公有云后台的内部架构设计与实现。首先从云计算的核心挑战开始,分析在大规模集群当中云的分布式调度系统需要解决哪些主要问题,然后详细讲述业界的一个发展历程,尤其是OpenStack在这个历程中的意义和价值,以及一些新兴的开源软件对云调度系统的总结和反思。后会重点讲述腾讯云VStation基于腾讯的海量后台经验,如何设计腾讯云的后台架构和经验总结,并与OpenStack做一个对比。

    1086 人正在学习 去看看 CSDN讲师

为什么需要集群管理与调度

上文我们简单介绍了深度学习、分布式CPU+GPU集群的实现原理,以及分布式深度学习的原理,我们简单回顾一下:

分布式CPU+GPU集群的实现:


GPU集群并行模式即为多GPU并行中各种并行模式的扩展,如上图所示。节点间采用InfiniBand通信,节点间的GPU通过RMDA通信,节点内多GPU之间采用基于infiniband的通信。

分布深度学习框架的实现:

如下图所示,在tensorflow中,计算节点称做worker节点,Worker节点主要完成模型的训练与计算。参数服务器可以是多台机器组成的集群,类似分布式的存储架构,涉及到数据的同步,一致性等等, 一般是key-value的形式,可以理解为一个分布式的key-value内存数据库,然后再加上一些参数更新的操作,采取这种方式可以几百亿的参数分散到不同的机器上去保存和更新,解决参数存储和更新的性能问题。

在分布式深度学习框架运行时,可以将深度学习框架部署到具体的物理集群,PS服务器可以挑选如下图中的node0、node1…,worker节点可以挑选如下图中的node i,node N-1


集群的具体配置,参数服务器可以不用GPU,worker节点因为需要进行模型计算,所在的服务器需要配置GPU卡。

至此,我们基本搭建了一个深度学习的硬件集群,同时也将深度学习框架部署到了深度学习的服务器集群,但是,整个深度学习集群(包括软硬件),可能是公司内部的共享资产,每个项目组都需要使用,那么,采取上述方式部署便会带来如下问题:

1.   要求项目组必须使用统一的深度学习框架,统一的深度学习框架的版本,否则不同项目组完成的训练代码有可能不工作,如果每次为了适应某个项目组的要求去重新部署框架,工作量巨大,而且耗时耗力;

2.   其中一个项目组在使用集群时,其他项目组往往需要等待,导致集群的资源使用率较低;

3.   服务器集群中任何一台硬件出现问题,都会影响整个集群的使用。

集群管理与调度实现的两种思路

基于Kubernetes平台

Kubernetes是Google开源的容器集群管理系统,其提供应用部署、维护、 扩展机制等功能,利用Kubernetes能方便地管理跨机器运行容器化的应用,其主要功能如下:

1) 使用Docker对应用程序包装(package)、实例化(instantiate)、运行(run)。

2) 以集群的方式运行、管理跨机器的容器。

3) 解决Docker跨机器容器之间的通讯问题。

4) Kubernetes的自我修复机制使得容器集群总是运行在用户期望的状态。

Kubernetes自1.3开始支持GPU,但当时只能最多支持单GPU的调度,自1.6开始,已经支持多GPU的调度,更多关于Kubernetes的与GPU介绍可以参考本系列未来的第3篇:分布式机器学习的两种集群方案介绍之基于Kubernetes的实现,这里不太多赘述。

如果要完成基于Kubernetes的集群调度管理深度学习框架,需要将深度学习框架运行到容器之中。系统整体架构图将变为:

这里面涉及到一个Kubernetes集群调度的问题,即Kubernetes如何将ps、worker所在容器所需要的CPU、GPU、内存、存储进行调度,以满足需求。

集群经过Kubernetes进行管理以后,分布式深度学习框架运行在容器中,容器通过Kubernetes进行调度以满足所需的模型训练资源,因此能够很好的满足集群资源多部门共享的要求。我们看对以下问题的解决。

1.   要求项目组必须使用统一的深度学习框架,并要求统一版本,否则不同项目组完成的训练代码有可能不工作,如果每次为了适应某个项目组的要求去重新部署框架,工作量巨大,而且耗时耗力;

解决:基于容器+ Kubernetes平台,每个项目组可以很容易的申请自己所需要的深度学习框架,tensorflow、caffe等,同时同一种深度学习框架的多种版本支持也不在话下。

2.   其中一个项目组在使用集群时,其他项目组往往需要等待,即使集群的资源使用率较低;

解决:只要集群有利用率没达到100%,便可以方便地为其他项目组部署深度学习环境。

3.   服务器集群中任何一台硬件出现问题,都会影响整个集群的使用;

解决:通过Kubernetes的调度,完成底层硬件的容错。

天云软件基于Kubernetes平台研发的SkyForm ECP平台,已经完整的支持了GPU调度,同时也集成了tensorflow,caffe等深度学习框架。

基于MPI并行调度

我们此处引入HPC领域中的MPI集群作业调度管理解决方案,因为在神经元网络(也包括含更多隐层的深度学习场景下),上一层神经元计算完成以后才能进行下一层神经元网络的计算,这与MPI的计算思路不谋而合。MPI是高性能计算(HPC)应用中广泛使用的编程接口,用于并行化大规模问题的执行,在大多数情况下,需要通过集群作业调度管理软件来启动和监视在集群主机上执行的MPI任务。此方法的主要目标是使集群作业调度管理软件能够跟踪和控制组成MPI作业的进程。

一些集群作业调度管理软件,如IBM Platform LSF、天云软件SkyForm OpenLava等,可以跟踪MPI任务的CPU、内存、GPU的使用。我们把每个深度学习的计算作为MPI作业,通过天云软件OpenLava作业调度管理软件进行集群统一的资源管理与分配,具体的实现思路如下:


基于集群作业调度管理的解决方案,也能很好的满足深度学习集群多部门共享,多作业并发运行的特性,且能兼顾效率。

其中天云软件SkyForm Openlava是一个增强的、基于开源OpenLava并兼容IBM® Spectrum LSFTM的企业级工作负载调度器,并针对半导体研发、深度学习等的工作负载做了设计与优化。不论是现场物理集群部署,虚拟基础设施部署,还是云中部署,客户都不用支付高昂的许可证费用。具体的openlava介绍,可参考网站openlava.net。

另外,在深度学习框架需要基于MPI方式运行时,往往需要进行重新编译,并不是所有的版本都支持。
2014-02-13 17:13:33 tenfyguo 阅读数 1329
  • 平台分布式调度系统的演进

    深度介绍公有云后台的内部架构设计与实现。首先从云计算的核心挑战开始,分析在大规模集群当中云的分布式调度系统需要解决哪些主要问题,然后详细讲述业界的一个发展历程,尤其是OpenStack在这个历程中的意义和价值,以及一些新兴的开源软件对云调度系统的总结和反思。后会重点讲述腾讯云VStation基于腾讯的海量后台经验,如何设计腾讯云的后台架构和经验总结,并与OpenStack做一个对比。

    1086 人正在学习 去看看 CSDN讲师
小结一下自己的思考,自己心目中的云和云计算的几个技术特点:
1,高度抽象的服务封装;
   个人觉得这个是最重要的,任何工作和架构,只有能够足够抽象化才能做到“不变应万变”,但这个也是最难的,需要对业务和需求的场景的深度和广度有
   非常深刻的理解,并且能够抽象建模。


2,基于资源池的调度;
   举一个简单的例子,如某个节点的机器坏了,可以直接从资源池中拿一台替换,并且是自动甚至是智能的,而无需去修好机器后再换上。 
   
3,按需获取;
4,弹性扩展:
   由于是基于高度抽象的服务,因此弹性扩展是一个延伸的特性了


5,低成本:
   云化的一个很重要的目的,在于资源复用的效率会更高,因此成本也会更低,举一个例子,如   


6,分布式:
   分布式是一个潜在的需求,从资源复用,全局调度,弹性扩展等要求都需要分布式的支持
   
7,安全性:
   云化后的服务和部署应该是已经内置了安全支持的了,对服务的使用者来说,无需过多关注这块的运营安全性,监控,调度,防攻击,智能流量切换等均是重要的能力。
2017-09-25 10:12:49 csdngkk 阅读数 44
  • 平台分布式调度系统的演进

    深度介绍公有云后台的内部架构设计与实现。首先从云计算的核心挑战开始,分析在大规模集群当中云的分布式调度系统需要解决哪些主要问题,然后详细讲述业界的一个发展历程,尤其是OpenStack在这个历程中的意义和价值,以及一些新兴的开源软件对云调度系统的总结和反思。后会重点讲述腾讯云VStation基于腾讯的海量后台经验,如何设计腾讯云的后台架构和经验总结,并与OpenStack做一个对比。

    1086 人正在学习 去看看 CSDN讲师
云平台分布式调度系统的演进—658人已学习
课程介绍    
201709251009275852.jpg
    深度介绍公有云后台的内部架构设计与实现。首先从云计算的核心挑战开始,分析在大规模集群当中云的分布式调度系统需要解决哪些主要问题,然后详细讲述业界的一个发展历程,尤其是OpenStack在这个历程中的意义和价值,以及一些新兴的开源软件对云调度系统的总结和反思。后会重点讲述腾讯云VStation基于腾讯的海量后台经验,如何设计腾讯云的后台架构和经验总结,并与OpenStack做一个对比。
课程收益
    愿意了解云平台内部实现的技术人员。
讲师介绍
    CSDN公开课更多讲师课程
    CSDN线上公开课全掌握!
课程大纲
  第1章:云平台分布式调度系统的演进
    1.云平台分布式调度系统的演进  47:58
大家可以点击【查看详情】查看我的课程
2016-04-10 22:45:57 GH234505 阅读数 6171
  • 平台分布式调度系统的演进

    深度介绍公有云后台的内部架构设计与实现。首先从云计算的核心挑战开始,分析在大规模集群当中云的分布式调度系统需要解决哪些主要问题,然后详细讲述业界的一个发展历程,尤其是OpenStack在这个历程中的意义和价值,以及一些新兴的开源软件对云调度系统的总结和反思。后会重点讲述腾讯云VStation基于腾讯的海量后台经验,如何设计腾讯云的后台架构和经验总结,并与OpenStack做一个对比。

    1086 人正在学习 去看看 CSDN讲师

  由于GPU目前在各行各业的广泛应用,无论是深度学习、大数据、云计算等都离不开GPU的并行加速,前阵子自学了Cuda-c编程,希望将来的研究工作能够用得上。
  Cuda系列总共有4篇,这里主要用于记录本人学习过程中的一些问题的思考和总结,及网上汇总摘录的别人的一些总结、看法等,并不适合新手入门。如有错误,欢迎各位指正。  

sm流处理器簇对blocks的调度策略

  在cuda中,GPU中的SM(GTX650M有2个sm处理器)被GPU调度器把线程块逐个分配到SM上,每个SM同时处理这些被分配的线程块block,但是每次每个时刻都只能处理一个warp线程束,由于有时会存在内存读取等操作导致等待,那么SM会转而处理其他的warp来掩盖这个延迟。并且这些warp不一定都是在同一个线程块block内的,另之所以每次同时处理多个block而不是只处理一个block并把该block内的线程个数设置成支持的最大的线程个数,一是可以允许其在支持不同线程个数的不同型号的显卡上都能处理相同的程序;二是由于gpu并行运算一般存在成千上万个线程,并且线程块个数远远大于SM,所以不会存在同一个SM内的线程块几乎同时执行完毕,而最终执行最后一个被调度的线程块而造成等待时间大于之前sm执行的时间所导致的效率低下。

附录1:

  GPU线程以网格(grid)的方式组织,而每个网格中又包含若干个线程块,在G80/GT200系列中,每一个线程块最多可包含512个线程,Fermi架构中每个线程块支持高达1536个线程。同一线程块中的众多线程拥有相同的指令地址,不仅能够并行执行,而且能够通过共享存储器(Shared memory)和栅栏(barrier)实现块内通信。这样,同一网格内的不同块之间存在不需要通信的粗粒度并行,而一个块内的线程之间又形成了允许通信的细粒度并行。这些就是CUDA的关键特性:线程按照粗粒度的线程块和细粒度的线程两个层次进行组织、在细粒度并行的层次通过共享存储器和栅栏同步实现通信,这就是CUDA的双层线程模型。
  在执行时,GPU的任务分配单元(global block scheduler)将网格分配到GPU芯片上。启动CUDA 内核时,需要将网格信息从CPU传输到GPU。任务分配单元根据这些信息将块分配到SM上。任务分配单元使用的是轮询策略:轮询查看SM是否还有足够的资源来执行新的块,如果有则给SM分配一个新的块,如果没有则查看下一个SM。决定能否分配的因素有:每个块使用的共享存储器数量,每个块使用的寄存器数量,以及其它的一些限制条件。任务分配单元在SM的任务分配中保持平衡,但是程序员可以通过更改块内线程数,每个线程使用的寄存器数和共享存储器数来隐式的控制,从而保证SM之间的任务均衡。任务以这种方式划分能够使程序获得了可扩展性:由于每个子问题都能在任意一个SM上运行,CUDA程序在核心数量不同的处理器上都能正常运行,这样就隐藏了硬件差异。
  对于程序员来说,他们需要将任务划分为互不相干的粗粒度子问题(最好是易并行计算),再将每个子问题划分为能够使用线程处理的问题。同一线程块中的线程开始于相同的指令地址,理论上能够以不同的分支执行。但实际上,在块内的分支因为SM构架的原因被大大限制了。内核函数实质上是以块为单位执行的。同一线程块中的线程需要SM中的共享存储器共享数据,因此它们必须在同一个SM中发射。线程块中的每一个线程被发射到一个SP上。任务分配单元可以为每个SM分配最多8个块。而SM中的线程调度单元又将分配到的块进行细分,将其中的线程组织成更小的结构,称为线程束(warp)。在CUDA中,warp对程序员来说是透明的,它的大小可能会随着硬件的发展发生变化,在当前版本的CUDA中,每个warp是由32个线程组成的。SM中一条指令的延迟最小为4个指令周期。8个SP采用了发射一次指令,执行4次的流水线结构。所以由32个线程组成的Warp是CUDA程序执行的最小单位,并且同一个warp是严格串行的,因此在warp内是无须同步的。在一个SM中可能同时有来自不同块的warp。当一个块中的warp在进行访存或者同步等高延迟操作时,另一个块可以占用SM中的计算资源。这样,在SM内就实现了简单的乱序执行。不同块之间的执行没有顺序,完全并行。无论是在一次只能处理一个线程块的GPU上,还是在一次能处理数十乃至上百个线程块的GPU上,这一模型都能很好的适用。

附录2:

硬件基本架构
  实际上在 nVidia 的 GPU 里,最基本的处理单元是所谓的 SP(Streaming Processor),而一颗 nVidia 的 GPU 里,会有非常多的 SP 可以同时做计算;而数个 SP 会在附加一些其他单元,一起组成一个 SM(Streaming Multiprocessor)。几个 SM 则会在组成所谓的 TPC(Texture Processing Clusters)。
  在 G80/G92 的架构下,总共会有 128 个 SP,以 8 个 SP 为一组,组成 16 个 SM,再以两个 SM 为一个 TPC,共分成 8 个 TPC 来运作。而在新一代的 GT200 里,SP 则是增加到 240 个,还是以 8 个 SP 组成一个 SM,但是改成以 3 个 SM 组成一个 TPC,共 10 组 TPC。下面则是提供了两种不同表示方式的示意图。(可参考《NVIDIA G92终极状态!!》、《NVIDIA D10U绘图核心》)

对应到 CUDA
  而在 CUDA 中,应该是没有 TPC 的那一层架构,而是只要根据 GPU 的 SM、SP 的数量和资源来调整就可以了。
  如果把 CUDA 的 Grid - Block - Thread 架构对应到实际的硬件上的话,会类似对应成 GPU - Streaming Multiprocessor - Streaming Processor;一整个 Grid 会直接丢给 GPU 来执行,而 Block 大致就是对应到 SM,thread 则大致对应到 SP。当然,这个讲法并不是很精确,只是一个简单的比喻而已。

SM 中的 Warp 和 Block
  CUDA 的 device 实际在执行的时候,会以 Block 为单位,把一个个的 block 分配给 SM 进行运算;而 block 中的 thread,又会以「warp」为单位,把 thread 来做分组计算。目前 CUDA 的 warp 大小都是 32,也就是 32 个 thread 会被群组成一个 warp 来一起执行;同一个 warp 里的 thread,会以不同的数据,执行同样的指令。此外,在 Compute Capability 1.2 的硬件中,还加入了 warp vote 的功能,可以快速的进行 warp 内的简单统计。
  基本上 warp 分组的动作是由 SM 自动进行的,会以连续的方式来做分组。比如说如果有一个 block 里有 128 个 thread 的话,就会被分成四组 warp,第 0-31 个 thread 会是 warp 1、32-63 是 warp 2、64-95 是 warp 3、96-127 是 warp 4。
  而如果 block 里面的 thread 数量不是 32 的倍数,那他会把剩下的 thread 独立成一个 warp;比如说 thread 数目是 66 的话,就会有三个 warp:0-31、32-63、64-65。由于最后一个 warp 里只剩下两个 thread,所以其实在计算时,就相当于浪费了 30 个 thread 的计算能力;这点是在设定 block 中 thread 数量一定要注意的事!
  一个 SM 一次只会执行一个 block 里的一个 warp,但是 SM 不见得会一次就把这个 warp 的所有指令都执行完;当遇到正在执行的 warp 需要等待的时候(例如存取 global memory 就会要等好一段时间),就切换到别的 warp 来继续做运算,藉此避免为了等待而浪费时间。所以理论上效率最好的状况,就是在 SM 中有够多的 warp 可以切换,让在执行的时候,不会有「所有 warp 都要等待的情形发生;因为当所有的 warp 都要等待时,就会变成 SM 无事可做的状况了~
  下图就是一个 warp 排程的例子。一开始是先执行 thread block 1 的 warp1,而当他执行到第六行指令的时候,因为需要等待,所以就会先切到 thread block 的 warp2 来执行;一直等到存取结束,且刚好有一个 warp 结束时,才继续执行 TB1 warp1 的第七行指令。

这里写图片描述

  实际上,warp 也是 CUDA 中,每一个 SM 执行的最小单位;如果 GPU 有 16 组 SM 的话,也就代表他真正在执行的 thread 数目会是 32x16 个。不过由于 CUDA 是要透过 warp 的切换来隐藏 thread 的延迟、等待,来达到大量平行化的目的,所以会用所谓的 active thread 这个名词来代表一个 SM 里同时可以处理的 thread 数目。
  而在 block 的方面,一个 SM 可以同时处理多个 thread block,当其中有 block 的所有 thread 都处理完后,他就会再去找其他还没处理的 block 来处理。假设有 16 个 SM、64 个 block、每个 SM 可以同时处理三个 block 的话,那一开始执行时,device 就会同时处理 48 个 block;而剩下的 16 个 block 则会等 SM 有处理完 block 后,再进到 SM 中处理,直到所有 block 都处理结束。
  为一个多处理器指定了一个或多个要执行的线程块时,它会将其分成warp块,并由SIMT单元进行调度。将块分割为warp的方法总是相同的,每个warp都包含连续的线程,递增线程索引,第一个warp中包含全局线程过索引0-31。每发出一条指令时,SIMT单元都会选择一个已准备好执行的warp块,并将指令发送到该warp块的活动线程。Warp块每次执行一条通用指令,因此在warp块的全部32个线程执行同一条路径时,可达到最高效率。如果一个warp块的线程通过独立于数据的条件分支而分散,warp块将连续执行所使用的各分支路径,而禁用未在此路径上的线程,完成所有路径时,线程重新汇聚到同一执行路径下,其执行时间为各时间总和。分支仅在warp块内出现,不同的warp块总是独立执行的–无论它们执行的是通用的代码路径还是彼此无关的代码路径。

建议的数值?
  在 Compute Capability 1.0/1.1 中,每个 SM 最多可以同时管理 768 个 thread(768 active threads)或 8 个 block(8 active blocks);而每一个 warp 的大小,则是 32 个 thread,也就是一个 SM 最多可以有 768 / 32 = 24 个 warp(24 active warps)。到了 Compute Capability 1.2 的话,则是 active warp 则是变为 32,所以 active thread 也增加到 1024。
  在这里,先以 Compute Capability 1.0/1.1 的数字来做计算。根据上面的数据,如果一个 block 里有 128 个 thread 的话,那一个 SM 可以容纳 6 个 block;如果一个 block 有 256 个 thread 的话,那 SM 就只能容纳 3 个 block。不过如果一个 block 只有 64 个 thread 的话,SM 可以容纳的 block 不会是 12 个,而是他本身的数量限制的 8 个。
  因此在 Compute Capability 1.0/1.1 的硬件上,决定 block 大小的时候,最好让里面的 thread 数目是 warp 数量(32)的倍数(可以的话,是 64 的倍数会更好);而在一个 SM 里,最好也要同时存在复数个 block。如果再希望能满足最多 24 个 warp 的情形下,block 里的 thread 数目似乎会是 96(一个 SM 中有 8 个 block)、128(一个 SM 中有 6 个 block)、192(一个 SM 中有 4 个 block)、256(一个 SM 中有 3 个 block) 这些数字了~
  Compute Capability 1.0/1.1 的硬件上,每个grid最多可以允许65535×65535个block。每个block最多可以允许512个thread,但是第三维上的最大值为64。而官方的建议则是一个 block 里至少要有 64 个 thread,192 或 256 个也是通常比较合适的数字(请参考 Programming Guide)。
  但是是否这些数字就是最合适的呢?其实也不尽然。因为实际上,一个 SM 可以允许的 block 数量,还要另外考虑到他所用到 SM 的资源:shared memory、registers 等。在 G80 中,每个 SM 有 16KB 的 shared memory 和 8192 个 register。而在同一个 SM 里的 block 和 thread,则要共享这些资源;如果资源不够多个 block 使用的话,那 CUDA 就会减少 Block 的量,来让资源够用。在这种情形下,也会因此让 SM 的 thread 数量变少,而不到最多的 768 个。
  比如说如果一个 thread 要用到 16 个 register 的话(在 kernel 中宣告的变量),那一个 SM 的 8192 个 register 实际上只能让 512 个 thread 来使用;而如果一个 thread 要用 32 个 register,那一个 SM 就只能有 256 个 thread 了~而 shared memory 由于是 thread block 共享的,因此变成是要看一个 block 要用多少的 shread memory、一个 SM 的 16KB 能分给多少个 block 了。
  所以虽然说当一个 SM 里的 thread 越多时,越能隐藏 latency,但是也会让每个 thread 能使用的资源更少。因此,这点也就是在优化时要做取舍的了。

2018-02-05 11:15:52 weixin_34235457 阅读数 74
  • 平台分布式调度系统的演进

    深度介绍公有云后台的内部架构设计与实现。首先从云计算的核心挑战开始,分析在大规模集群当中云的分布式调度系统需要解决哪些主要问题,然后详细讲述业界的一个发展历程,尤其是OpenStack在这个历程中的意义和价值,以及一些新兴的开源软件对云调度系统的总结和反思。后会重点讲述腾讯云VStation基于腾讯的海量后台经验,如何设计腾讯云的后台架构和经验总结,并与OpenStack做一个对比。

    1086 人正在学习 去看看 CSDN讲师

点击关注 InfoQ,置顶公众号

接收程序员的 8 点技术早餐

1 写在前面

当前,传统企业的 IT 系统以单体架构为主,在面对互联网业务的冲击时,系统架构的性能瓶颈逐渐显现。云计算、Docker、DevOps、持续交付等概念的深入人心,以 Spring Cloud 为代表的微服务框架日渐兴起,微服务架构成为传统 IT 架构转型的集中趋势。

在微服务化的行业汹涌浪潮里,腾讯云历经五年磨砺,整合外部开源框架和内部 PaaS 平台,完成了王者荣耀全球同服的毫秒级延时和春节红包的高并发交易等性能需求,以日 5 万亿次的惊人调度次数,支撑腾讯内部海量业务的构建与发展。

微服务改造的核心思想,指通过 IT 架构的微服务化,将复杂的单体架构,重组为小而美的独立服务,从而降低系统的复杂性,让企业更便捷的构建基于云计算的大规模分布式架构。

本文结合腾讯云微服务架构体系的构建原理、技术选型和改造实践,为你讲讲如何解决微服务部署、实施、监控余位中面临的难题。

2 传统企业 IT 架构面临的痛点

单体架构通常在一个归档包里容纳了所有功能的应用程序,整个项目包含的模块种类繁杂,模块边界界定模糊,每个模块之间具有强耦合性,项目复杂。大多数传统企业在上云的过程中,由于单体架构的固定属性,会面临着 IT 系统复杂、升级迭代慢、运维扩展性差、海量用户支撑能力薄弱、数据孤岛等一系列问题。

如传统企业在做电子政务、智能零售、工业 4.0 等智能化转型,或者想要开发人脸识别 / 支付系统、关联小程序等热门应用时,应用体系的改变以及用户量级的爆发式增长,都会对单体系统的性能瓶颈会提出极大的挑战。

不同于构建单一、庞大的应用,微服务架构以小型服务的方式开发独立应用系统,将应用拆分为一套小且互相关联的服务,每个小型服务都运行在自己的进程中,各服务之间采用 HTTP 资源 API 轻量的机制进行通信。相对于单体架构,微服务体系在迭代速度、系统吞吐量、扩展性以及技术栈的多样性上均有明显的优势。

日调度5万亿次 腾讯云微服务架构体系TSF深度解读

由于单体架构的缺陷日益明显,越来越多的公司采用微服务架构范式构建复杂应用。但在微服务的部署实施过程中,亦存在着架构与运维复杂、部署实施难度较高、问题定位困难等挑战。

  • 运维要求较高。更多的服务意味着更多的运维投入,单体架构中只需要保证一个应用的正常运行;而在微服务中,需要保证几十甚至几百个服务的正常运行与协作;

  • 分布式固有的复杂性。使用微服务构建的是分布式系统,对于一个分布式系统,系统容错、网络延迟、分布式事务等对于开发者而言都是巨大的挑战;

  • 接口调整成本高。微服务之间通过接口进行通信,如果修改某个微服务的 API,可能所有使用了该接口的微服务都需要做调整;

  • 重复劳动。很多服务可能都会使用到相同的功能。而这个功能并没有达到分解为一个微服务的程度,这个时候,可能各个服务都会开发这一功能,导致代码重复。

3 腾讯云微服务架构体系及其技术选型策略

互联网企业的微服务转型经验,可为传统行业开发者提供经验参考。腾讯云基于自身的海量业务需求,通过 IT 架构的微服务化,将紧耦合的塔式架构,重组为小而简的独立服务系统,打磨出一套可用的微服务架构平台和微服务构建方法论,实现业务之间解耦和技术栈独立,允许低成本试错,使团队迭代更敏捷。

微服务构建的五大核心要素

微服务构建的初衷不外乎实现敏捷迭代、灵活扩展、服务复用三大功能,腾讯云在构建微服务的过程提炼出了以下五大方法论:

  • 在线协同:对外的 API 文档就是一份公共的说明,常有发布新的不兼容接口,因此,如何跨团队协同、通知至关重要,这方面需要通过 swagger UI 做在线的接口定义,以此公共契约;

  • 部署原则:在真实环境里,Docker 应用还未完全普及,服务的部署耗时费力。可以尝试提供批量的自动化工具,做微服务独立打包,批量的部署,包括启动、停止、升级、回滚、下线等操作 ;

  • 拆分原则:如常见的线上房地产交易门户商品中心,包含运营相关的子系统如二手房推荐系统等,服务拆分得过细会带来不必要的分布式事务、调用环节冗长等问题。各系统的拆分原则上可强调“抓大放小”;

  • 数据扁平化:服务升级过程中,要注重数据模型的统一。首先,各微服务的数据层要允许有完善的权限管理系统,支持多种数据格式转换、数据清洗、数据同步等,便于业务高效地挖掘数据的价值 ;

  • 渐进性架构:大多企业和开发者很难从一开始高瞻远瞩 ,规划处 3、5 年不变的微服务架构,因此,需要有长期的演进迭代以及小规模团队维护,允许小团队技术栈独立,来拥抱业务团队的快速试错。

腾讯云微服务中间件 TSF 框架解析

TSF 分布式框架,历经腾讯内部最严苛、最复杂的生产级环境打磨,基于上述方法论,对其中核心性能的提炼,形成了一套具备无限扩展、高性能、高可靠的一站式微服务架构解决方案,可以为云计算开发者提供极具价值的经验参考。

如下图为腾讯云微服务中间件 TSF 一站式解决方案,最底层是云基础资源平台,包括云服务器、云数据库、云存储和专线加速几大模块,用作数据的存储和调用;同时,作为围绕微服务的 PaaS 平台,TSF 服务框架底层也融合了腾讯云内部大量的中间件服务,提供企业云化架构所必需的消息队列、Kafka、负载均衡、API 网关、全局配置服务等全套中间件。

日调度5万亿次 腾讯云微服务架构体系TSF深度解读

在此之上,TSF 支持应用的全生命周期管理功能,如对于虚拟机应用,提供代码包打包上传,批量发布、变更,版本切换等产品生命周期功能;对于火热的 Docker 应用,提供基于行业主流编排框架 Kubernetes 的全流程自动化持续集成和持续交付。

对于已经在使用 Dubbo 框架的用户,可以通过修改 pom.xml 中的依赖,平滑地迁移到 TSF。其中,Dubbo 存量系统迁移方式包含两种:

  1. 将业务发布包中的 dubbo-registry-zookeeper.jar 包替换为 tsf-registry-consul.jar 包;

  2. 修改 dubbo 配置项:adress 部分替换成腾讯云提供的 url 即可使用腾讯 TSF 服务。

<dubbo:registry id="×××1" address="×××://ip:port":/> <!-- 定义注册中心 -->

另外,在微服务运行与治理框架方面,TSF 为应用提供了自动注册、发现、治理,隔离,调用分析等一系列微服务治理能力,用以屏蔽微服务系统带来的复杂度。整个 TSF 框架基于 Spring Cloud,支持分布式服务发布与注册、服务调用、服务鉴权、服务降级、服务限流、配置管理、调用链跟踪等功能。

TSF 微服务框架技术选型策略

RPC 高性能服务框架

TSF 基于 Spring Cloud 生态,提供标准 restful 服务框架,同时,鉴于分布式服务框架对性能和可靠性等能力具有极高的要求,腾讯云 TSF 在设计之初,就基于 gRPC 提供高性能 RPC 服务框架,系统地考虑了分布式服务发现、路由管理、安全、负载均衡等细节问题,满足 100 万 +QPS 的服务压力。

日调度5万亿次 腾讯云微服务架构体系TSF深度解读

如上图所示,TSF 服务注册发现包括三个角色,服务提供者,服务调用者和服务注册中心。服务提供者和服务调用者将地址信息注册到服务注册中心,并从服务注册中心获取所有注册服务的实例列表。TSF 使用 Consul 作为服务注册中心,提供金融级别的两地三中心容灾部署能力。

构建可视化控制台

应用是 TSF 管理的基本单位,支持 Java jar 包,docker 镜像及其他语言应用(通过 service mesh)等,一个应用下面通常包含了多台机器,TSF 提供了完整的可视化控台,完善应用的生命周期管理机制,对分布式系统应用进行发布和管理,减少部署时间,提升部署效率。

在 TSF 控制台上,可以设置自定义 JVM 参数。TSF 将每次操作记录下来,用户可以在应用的变更记录页面中查看和搜索变更记录。

  1. 通过控制台发布应用,包括创建、部署、启动应用,也支持查看应用的部署状态。

  2. 通过控制台管理应用,包括回滚应用、手动扩容、缩容、删除应用。

日调度5万亿次 腾讯云微服务架构体系TSF深度解读

全链路调用跟踪

在监控层面,TSF 采取的策略是通过全链路调用跟踪技术打造一站式监控平台,以可视化的形式,准确掌握平台各项指标。具体实现如下图,通过对日志埋点的收集和分析,得到一次请求在各个服务间的调用链关系,帮助梳理应用的请求入口与服务的调用来源、依赖关系。当遇到请求耗时较长的情况,通过调用链分析调用瓶颈,快速定位异常。

日调度5万亿次 腾讯云微服务架构体系TSF深度解读

监控方面包括 IaaS 基础监控和应用监控。IaaS 基础监控的指标有实例 CPU、内存、网络和磁盘等,应用监控的指标包括应用的 QPS, 请求时间和请求出错率等。

分布式调用链分析包括调用链查询和调用链详情。调用链查询用于查看系统中的调用链路状态,尤其是慢业务和出错业务,避免后端雪崩;调用链详情是为了定位在分布式链路调用过程中每个环节的耗时和异常,用户可以根据时间范围和服务名等条件来查询一组调用链,有助于提前发现架构的瓶颈点。

自研 TDTS 分布式事务服务

金融场景下,对数据一致性有着严苛要求,通常一笔交易将会跨多个业务集群。TSF 采用自研分布式事务服务中间件 TDTS,基于 TCC 模式,提供无业务侵入性、无改造数据库改造成本的最终一致性中间件,保证每一笔交易可靠达成。

日调度5万亿次 腾讯云微服务架构体系TSF深度解读

TCC 模式通过应用层的两阶段提交,可以解决数据库的两阶段并发性能差、数据库对 XA 协议的支持可能不完善、以及部分情况下主业务系统智能间接操作数据库等问题。其实现原理是先执行 try, 再执行 confirm;若 try 失败,则执行 cancel。具体事务执行流程如下:

  1. 依次调用从业务系统的 Try 接口;

  2. 若 Try 阶段成功,则依次调用从业务系统的 Confirm 接口;

  3. 若在 Try 阶段出现失败,则调用从业务系统的 Cancel 接口,对 Try 接口的操作进行恢复;

  4. 若在 Confirm 阶段出现失败,则重试,设置重试次数。若重试仍然失败,则需要事后处理;

  5. 若调用 Cancel 接口失败,也进行重试操作;

这里,值得一提的是,TSF 可以与腾讯云多款成熟中间件产品打通,包括腾讯云 API Gateway、消息队列 CMQ 、CKafka 等。腾讯云微服务 API Gateway 通过建立路径到微服务 ID 的映射方式,用以提供负载均衡、熔断等能力。

4 TSF 在传统企业的微服务改造实践

腾讯云的 TSF 分布式微服务框架雏形可追溯至 2013 年,其初期以 Devops 服务系统的形式,支撑了包括财付通、腾讯游戏、手机 QQ 等内部核心业务的架构升级。2017 年,腾讯云整合内部微服务体系,提炼出了具备金融级容灾能力,高性能、高可靠的微服务解决方案,帮助传统企业快速解决在微服务改造过程中遇到的问题。此处以某房地产为例,简单讲述 TSF 在传统企业的微服务改造实践。

传统房地产企业面临的问题

传统房地产企业在互联网转型升级过程中,IT 系统架构极为复杂。因为单体 IT 架构的固有属性,其 IT 子系统各自为战,标准不一,无法相互通信,如会员信息、订单信息、消费者行为记录等多套系统链接分散,一旦涉及到业务变更情况,经常数百人加班参与,对后续的系统迭代带来了巨大挑战。

国家新型化城镇化规划出台后,“城市配套服务商”的战略一时引发热潮,围绕系列新业务,包括:装修、社区教育、酒店、商办(写字楼)、长租公寓、养老地产、物流地产等系统协同发展,此时,传统的 IT 架构显然已经无法满足新的业务发展需求。

腾讯云 TSF 微服务改造方案

腾讯云在原有的 IT 系统上,梳理出关键模块和关键资源,同时,在云中间件的平台上,搭建了系列抽象出来的中间件系统,包括负载均衡、API 网关服务、分布式配置、分布式事务、消息列队服务、分布式数据库以及腾讯云的 IaaS 能力,将独立的 IT 系统通过微服务的方式进行管理,对于关键资源通过合并调用减少调用册数,对于非关键资源同步异化处理,减少实施强依赖。

日调度5万亿次 腾讯云微服务架构体系TSF深度解读

通过微服务改造,将房地产的业务拆分成一手房销售系统、土地拍卖系统、营销包装系统与认筹系统,每个系统底下都有自己独立的运行进程,各系统之间通过轻量级的方式进行通信,每个系统独立而又相互连接。

此时,可以在公有云或者其他小程序上,根据自身业务需求,开发出新的应用或者系统如管家微信小程序、在线家政预约服务等,因为每个系统的运行相互独立,新的应用即便呈现爆发式增长,也不会影响其他模块的运行。

据悉,通过搭建分布式微服务中间件 TSF,该房地产的 IT 系统在 80 天内完成微服务架构改造上线,版本迭代平均周期从一个月变为两周, 当有新应用时,可以快速上线互联网应用。目前,系统每天能够稳定处理超过 5000 万次的系统查询,超过 1000 万次的订单落地。

当然,这个项目的整体改造过程并非一蹴而就,前期主要是将一些核心系统迁移,当完成主体架构搭建后,后期再根据需求进行适当的迭代和更新。

因此,对于传统企业的微服务架构引入策略上,建议在开始时可以考虑引入部分合适的微服务架构原则,对已有系统进行改造或新建微服务应用,然后逐步探索及积累微服务架构经验,而非全盘实施微服务架构。

没有更多推荐了,返回首页