边缘计算与边云协同

一、此边缘非彼边缘

现在这个阶段与其说边缘计算，不如说算力下沉。其实IT也会遵循大势，分久必合合久必分，从最初的大机时代的算力集中，到X86和小机时代以资源建设为目的的算力分散，再到后来从加强集约化管理出发的IT大集中，再到后来云平台的兴起进一步推动的算力集中。现在这个阶段显然出现了反思和回潮，开始革除一味集中，从管理的角度开始考虑算力适度分散。

从管理视角来说，业务集约带来的IT基础设施算力集约，这本身没错，现在之所以出现回潮，其实是IT管理的需要，分支企业和分支节点需要保留部分算力和IT设施，用于处理个性化业务和本地任务，这跟技术没关系，是管理的诉求和考虑。从这个角度说，应该算是分布式数据中心。物理上分布，逻辑上集中，依然接受总部的统一管理和调度。

二、又是一次自下而上的革命

从大的趋势来说，现在算力会更往数据侧去输出，也就贴源侧。目前边缘计算核心的应用场景主要是包括IOT类和视频类，这里说的大的分类，也许你会想到很多场景，比如车联网、比如柔性制造、比如智慧医疗、比如智慧城市等等，这些场景属于次生场景，都可以归类到以上两种核心场景里面。引入边缘层的目的更多是为了降低时延，提升服务感知。比如，来自IOT设备的数据，在网关侧时延是1~2毫秒，如果送到云平台侧，如果是公有云一般时延会在50ms左右，在很多次生场景下，这种时延是不能接受的。如果引入边缘层，在边缘云侧根据边缘层的位置不同，一般会有10毫秒以内的时延，就极大缓解这种尴尬。但是这又带来了另外一个问题，单纯靠边缘层只能解决一部分问题，边缘侧还是离不开云侧的支撑，也就是需要边缘侧与云侧的协同

三、从CS到CES，从边缘计算到边云协同

其实随着IT与业务的深入结合，云呈现持续落地的态势，算力跟业务的结合度越来越高。在具体的行业场景里面，对算力布局调整的呼声也越来越高。传统的云管端架构CS架构，随着边缘计算的到来，变成了CES，在中间管道贴近端侧的位置，增加边缘处理层，从这个角度来说，边云协同是对算力的重新分布。 边缘计算与云计算需要通过紧密协同才能更好地满足各种需求场景的匹配，从而最大化边缘计算和云计算的应用价值。边缘计算既靠近执行单元，更是云端所需高价值数据的采集和初步处理单元，可以更好地支撑云端应用；反之，云计算通过大数据分析优化输出的业务规则也可以下发到边缘侧，边缘计算基于新的业务规则进行业务执行的优化处理。具体来说，我个人理解的边云协同主要有以下几个层面：

1、资源层面： 主要是边缘计算与云平台在资源层进行协同，实现边缘侧资源的统一纳管，以及边缘侧云资源的调度和爆发等等；

2、数据层面： 这部分是协同的重点，也是边缘计算的重点应用场景，边缘侧靠近执行单元和端侧设备，靠近数据源，边缘计算负责数据采集和预处理，比如数据整形和粗粒度的分析和汇总，提升数据价值密度等等，以达到节省网络资源和提高效率的目的；云平台侧负责全局角度的数据分析和数据能力平台的打造和服务输出；

3、应用层面： 这个层面主要包括业务和应用两部分，业务层面主要是面向业务流程的业务编排协同，一个完整的业务流，需要根据边缘侧和云侧的分工不同进行拆分，这一点在柔性制造领域体现的比较明显；应用部分主要是对于应用架构和功能的拆分，实现分布式的部署和运行；

4、服务层面： 服务的协同，我个人理解应该是边云协同的最终目的，希望通过边云协同打造服务的重分布和流程再造，从而实现业务的创新。

四、说一点个人的理解和建议：

1、管理层面的算力下沉和边缘化，可以适度的推进，这一点其实也是跟集中式数据中心向分布式数据中心演进的趋势一致；

2、当前边缘计算有点过热，凡是靠近端侧和用户侧的应用都被冠以边缘计算的帽子，我个人建议还是应该理性处理，一定得需求出发，从典型的应用场景出发，综合衡量成本和实际效果，逐步探索算力下沉到边缘侧；

3、一定注意边云协同，切忌盲目推进算力边缘化，严防形成的新的孤岛。