公司新闻

阿里云的这款产品给了一剂提升微服务幸福感的良药

微服务开展至今,因其高内聚、低耦合等特性,以及许多开源计划带来的开放性,已成为提高架构功率的最佳实践之一。当一项技能或一个结构成为事实标准之后,咱们会把更多的注意力聚集在运维功率和使用可用性的持续提高上。信任下面这些场景咱们或多或少都遇到过。

场景一:当事务到达必定的规划之后,微服务的数量和单个微服务实例的数就会变的许多,然后导致微服务注册中心需求办理许多服务地址,一起还需求给一切的上下游供给服务注册和服务发现的才干。

场景二:发布是天大的工作,每一次的发布,都会呈现履行到一半的恳求中断掉,上游持续调用现已下线的节点导致报错的现象。发布时收到各种报错,一起还影响用户的体会,发布后又需求修正履行到一半的脏数据。

上述场景仍是在新版本没有任何问题的情况下,假如新版本有问题,则会导致许多事务直接恳求到有问题的新版本,轻则修正数据,重则严重影响用户体会,乃至发生资损。最终不得不每次发版都安排在清晨两三点发布,心惊胆颤,睡眠不足,苦不可言。

场景三:大深夜某个服务节点呈现反常,上游依旧不断地调用,呈现许多反常和各种报警短信。被报警惊醒后,想直接在线上修正,有点难,想保存现场又惧怕拖垮整个使用,只好先重启为上。

可是这仅仅治标不治本的方法,由于很难复现然后无法有用定位,或许明日又被惊醒,持续重启。上述场景仍是建立在报警体系比较完善的情况下,假如没有完善的报警体系,严重情况或许整个事务体系都被单机反常拖垮。

场景四:公司事务强大了,部分安排变杂乱后,微服务模块越来越多。我不清楚发布的服务究竟被谁调用了,所以我不知道能否安全地下线一个服务。我这个使用的这个接口是个灵敏接口,我只期望得到我授权的使用才干调用,而不是直接从服务注册中心得到我的地址就能直接调用,可是现在如同还做不到。

面临以上这些场景,能够经过投入更多的开发和运维资源来处理,但关于大部分期望专心于事务开发的企业来说,假如能有一款合适企业本身需求,支撑组件化的商业化产品,将会是更好的挑选。

接下来,咱们就来具体分析下阿里云微服务MSE是怎么处理以上问题的。

比较根据Zookeeper/Nacos/Eureka来自建注册中心,MSE 供给了以下这些差异化竞争力。

联系我们

CONTACT US

联系人:张先生

手 机:

电 话:

邮 箱:

地 址: