课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
微服务架构技术我们在前几期的文章中已经给大家介绍过很多次了,而本文我们就再来了解一下,微服务架构应用性能分析都有哪些方法。
简单系统不建议应用微服务。简单不仅指业务逻辑简单,还包括周边关系,也就是与其他系统交互少。在一项业务运行或者设计初期,尤其是在业务量不大且复杂性不高,并且追求快速响应、开拓服务、节省成本、提高效率时,单体架构是 优选择。但当业务进入扩展期,系统架构开始向服务架构转型,业务不断扩大,业务系统复杂性不断提高,使效率在不断下降时,再考虑微服务。
一致性要求高的业务系统慎重选择微服务。微服务的本质是分布式系统,业务对数据的一致性要求决定了系统是否可以采用分布式架构进行构建。需要评估微服务所产生的大量服务调用与服务间通信所带来的数据一致性的影响是否能满足业务场景的需求,同时评估服务治理框架能否应对大量的服务间通信。
实时性要求高的业务系统慎重选择微服务。分布式系统相较单体系统会带来额外的网络开销。需要评估目标业务在分布式架构下,网络带来的延迟能否满足业务需求,若时延容忍度高于毫秒级,微服务会严重应用运行性能。
微服务可以提升系统整体可用性。通过集群的方式可以提升服务的可用性,但取决于服务化的模块是否易于进行水平扩展。无状态的服务容易扩展到多个实例,而有状态的服务则成本较高。
微服务可以帮助团队优化交付周期。快速的交付有利于缩短获取用户反馈的周期,有利于团队实现敏捷开发及降低发布的风险。因此在进行架构改造前需要充分评估业务需求的快速变化以及交付周期的缩短是否可以显著提升业务竞争力。
微服务架构具有良好的可伸缩性。针对具有弹性伸缩能力需求的业务系统,而且水平伸缩模型可进行预测的场景适合进行微服务改造。
项目人员团队力量薄弱期不建议应用微服务。微服务是一项系统性工程,架构师需要构建微服务、前端、后端、测试等多个模块。另外要考虑是否有能力维护大量分布式的复杂服务,尤其当不同的服务采用不同的技术栈,服务间通信机制、认证、鉴权、证书管理也会异常复杂。
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。