课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
微服务架构相信大家应该都不陌生的吧,而今天我们就通过案例分析来了解一下,微服务架构应用都有哪些常见问题。
1、似乎很难监控整体
虽然单体应用程序也有其自身的挑战,但在单体中回滚一个“坏”版本的过程是相当简单的。在容器化应用中,事情就变得复杂许多。无论你是将单体应用逐步分解为微服务,还是从头开始构建一个新系统,你现在都有更多的服务需要监控。其中每一个都可能会:
使用不同的技术和/或语言。
运行在不同的机器和/或容器上
使用K8s或类似的技术进行容器化和编排
2、跨服务日志记录
在谈论监控应用程序时,先要提出的事情之一是:日志、日志、日志。服务器每天都会产生的IT日志相当于碳的排放量,终导致溢出的硬盘驱动器以及疯狂摄取、存储和工具成本。即使采用单体架构,你的日志也可能已经使你的工程师有些头疼。
使用微服务,日志变得更加分散。一个简单的用户业务现在可以通过许多服务进行,所有这些服务都有自己的日志记录框架。要解决问题,你必须从业务可能通过的所有服务中提取所有不同的日志,以了解问题所在。
3、难以找到问题的根本原因
在这一点上,你已经锁定了有问题的服务,提取了所有需要提取的数据,包括堆栈跟踪和日志中的一些变量值。你可能还有一些APM解决方案,比如NewRelic、AppDynamics或Dynatrace。从那里,你会得到一些额外的数据,关于一些相关方法的异常高处理时间。
4、版本管理
我们认为值得强调的问题是,从典型的单体架构中的层模型过渡到微服务的图模型。由于超过80%的应用程序代码通常是三方代码,因此在公司的不同微服务之间管理三方代码的共享方式成为避免陷入前所未有的“依赖地狱”的关键因素。
希望这辈子,最让你无悔的事情就是来达内学习!学习向来不是件易事,但无论过程多么艰难,希望你依然热爱生活,热爱学习!永远记得,达内将与你一同前行!现在扫码,立即领取万元课程礼包,助力0基础快速入行,为你梳理行业必备技能,全方位了解岗位发展前景!
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请在707945861群中学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。