
课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
我们在前几期的文章中给大家简单介绍了微服务架构开发技术应用的优势与常见问题等内容,而本文我们就再来学习一下,微服务架构开发性能优化方法。
假设用户想要看推荐。请求转到推荐服务,它查询用户数据来了解用户详情,并将推荐存储在其数据库中(不在图片上),而且由于这是用户相关的数据,所以它们可能需要将其加密。
现在,如果数据加密服务挂了会发生什么?我们还能做推荐吗?肯定不能,因为我们不能加密用户数据,所以我们自然会说,嘿,伙计,我们现在不能给你推荐,请5分钟后再试。这个故障影响到系统中的推荐服务,系统会以无法立即提供推荐的事实来优雅地做出回应。
但是你知道要优雅地处理这类情况需要做多少工作吗?非常多。
让我们再举一个例子。用户尝试使用登录服务来登入系统。数据加密服务仍在故障,登录服务调用分析服务来获取在一个时间区间内有多少用户正在尝试登入的指标,以及其它一些虚构的指标。不过,分析服务也在与数据加密服务通信,因为这些数据也需要加密。
现在,编写分析服务的团队正忙着,没有时间来实现适当的异常处理,因此数据加密服务的问题会转而影响到登录服务。显然,登录服务是在几个月前完成的,这个服务没有准备好处理来自分析服务的底层错误,因此即使不关键的分析服务失败也会导致用户登录被拒绝。
而且我知道你是怎么想的。是的,实现登录服务的团队不负责为处理这种情况做准备,但是如果他们认为分析服务会优雅地处理这个异常呢?这已经写在分析服务的API合约中,但它没有那样生效。
那么,当你在一个单体应用程序中,会发生什么呢?一个服务崩溃在这个上下文中并没有真正的意义,但假定由于某种原因,连接到数据加密的数据库表不可访问了。
在这种情况下,异常处理非常简单,因为你只需要准备一个exception就可以了。但是在过分赞扬单体应用前,需要说的是,单体应用也有缺点,如果单体应用挂了,什么东西都不可用了。因此,这是一个平衡问题,需要问问你自己。是实现一个try-catch代码块更容易,还是处理一个同步HTTP调用异常或异步消息异常更容易?
我记得,对于80+微服务,标准化异常处理是非常了不起的事情,它需要一个团队花费数月来完成。这甚至不意味着在每个地方都引入异常处理,而只是将现有的异常用我们使用的一个自定义库重写,这样我们就可以减少未来异常处理场景所需的繁琐工作。
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。