将如何影响网络安全？

最高层级的核心数据中心(全局中心)，部署有一套MEAO(全国统一MEC应用编排系统)，对边缘资源进行统一的全局调度。MEAO还对接集团 OSS、BSS、政企营销门户、NFVO、统一云管，对外提供开放接口供开发者及客户上传业务能力和应用。

部署在各省的区域中心机房，是中国联通MEC业务孵化基地的核心，部署了MEPM、MEP等系统或网元。MEPM(多接入边缘平台管理器)是MEAO调度能力的实际载体。它具备区域自治能力，可以支撑运维人员进行区域内所有边缘数据中心的管理，也能够对边缘资源进行控制。

而最底层的边缘机房，对应各个地市的核心/汇聚/现场接入机房节点，可以提供各种各样的底层能力，例如GPU加速、持久化存储等等，并在此基础上融合了CT和IT的VAS能力、IP分流能力和DNS分流能力等。

中国联通的边缘云平台，拥有强大的业务承载能力和高效的管理编排效率，这背后是基础软硬件平台和技术的强有力支撑。

软件方面，中国联通自主研发了运营平台，基于边缘平台编排器和管理器的协同，实现了资源的整体调度和统一管理，以及不同层级的云边协同无缝对接。

为了在多云和跨平台环境中具备更高效的编排能力，降低平台和网络基础设施的复杂度，联通自研的边缘平台参考了英特尔开源软件套件OpenNESS，基于微服务架构，集成了新的硬件增强、开源技术以及丰富的工具包，可以帮助用户更敏捷的开发边缘应用。

 

保证了最终一致性，通过在队列中存放任务保证它最终一定会执行。

最终一致性指的是两个系统的状态保持一致，要么都成功，要么都失败。当然有个时间限制，理论上越快越好，但实际上在各种异常的情况下，可能会有一定延迟达到最终一致状态，但最后两个系统的状态是一样的。

业界有一些为“最终一致性”而生的消息队列，如Notify(阿里)、QMQ(去哪儿)等，其设计初衷，就是为了交易系统中的高可靠通知。

以一个银行的转账过程来理解最终一致性，转账的需求很简单，如果A系统扣钱成功，则B系统加钱一定成功。反之则一起回滚，像什么都没发生一样。

然而，这个过程中存在很多可能的意外：

• A扣钱成功，调用B加钱接口失败。
• A扣钱成功，调用B加钱接口虽然成功，但获取最终结果时网络异常引起超时。
• A扣钱成功，B加钱失败，A想回滚扣的钱，但A机器down机。

可见，想把这件看似简单的事真正做成，真的不那么容易。所有跨JVM的一致性问题，从技术的角度讲通用的解决方案是：

• 强一致性，分布式事务，但落地太难且成本太高。
• 最终一致性，主要是用“记录”和“补偿”的方式。在做所有的不确定的事情之前，先把事情记录下来，然后去做不确定的事情，结果可能是：成功、失败或是不确定，“不确定”(例如超时等)可以等价为失败。成功就可以把记录的东西清理掉了，对于失败和不确定，可以依靠定时任务等方式把所有失败的事情重新搞一遍，直到成功为止。

回到刚才的例子，系统在A扣钱成功的情况下，把要给B“通知”这件事记录在库里(为了保证最高的可靠性可以把通知B系统加钱和扣钱成功这两件事维护在一个本地事务里)，通知成功则删除这条记录，通知失败或不确定则依靠定时任务补偿性地通知我们，直到我们把状态更新成正确的为止。

消息可能重复，注意消息的重复和幂等。

(3)广播

如果没有消息队列，每当一个新的业务接入时，我们都需要连接一个新接口;有了消息队列，我们只需要关系消息是否送到到消息队列，新接入的接口订阅相关的消息，自己去做处理就行了。

(4)错峰与流控

利用消息队列，转储两个系统的通信内容，并在下游系统有能力处理这些消息的时候再处理这些消息。试想上下游对于事情的处理能力是不同的。比如，Web前端每秒承受上千万的请求，并不是什么神奇的事情，只需要加多一点机器，再搭建一些LVS负载均衡设备和Nginx等即可。但数据库的处理能力却十分有限，即使使用SSD加分库分表，单机的处理能力仍然在万级。由于成本的考虑，我们不能奢求数据库的机器数量追上前端。

这种问题同样存在于系统和系统之间，如短信系统可能由于短板效应，速度卡在网关上(每秒几百次请求)，跟前端的并发量不是一个数量级。但用户晚上个半分钟左右收到短信，一般是不会有太大问题的。如果没有消息队列，两个系统之间通过协商、滑动窗口等复杂的方案也不是说不能实现。但系统复杂性指数级增长，势必在上游或者下游做存储，并且要处理定时、拥塞等一系列问题。而且每当有处理能力有差距的时候，都需要单独开发一套逻辑来维护这套逻辑。所以，利用中间系统转储两个系统的通信内容，并在下游系统有能力处理这些消息的时候，再处理这些消息，是一套相对较通用的方式。

总结

总而言之，消息队列不是万能的。对于需要强事务保证而且延迟敏感的，RPC是优于消息队列的。

对于一些无关痛痒，或者对于别人非常重要但是对于自己不是那么关心的事情，可以利用消息队列去做。

支持最终一致性的消息队列，能够用来处理延迟不那么敏感的“分布式事务”场景，而且相对于笨重的分布式事务，可能是更优的处理方式。

当上下游系统处理能力存在差距的时候，利用消息队列做一个通用的“漏斗”。在下游有能力处理的时候，再进行分发。

如果下游有很多系统关心你的系统发出的通知的时候，果断地使用消息队列吧。

（编辑：阿坝站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!