课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
微服务架构我们在前几期的文章中已经给大家介绍过很多次了,而本文我们就继续来了解一下,微服务架构技术应用常见问题分析。
微服务比单体服务更有吸引力的原因是可以减少在使用单体服务时遇到的问题。通常,单体服务的测试周期可以延续数天或数周,它们非常复杂,修改或扩展都非常有挑战性。如果你的团队能够一天添加一个新特性,那么你就不会受到测试周期、修改或复杂变更的阻碍。
但我们也听到了一些不同的声音,当我们向团队建议这种节奏时,他们就开始寻找为什么不能达到这种快速发布原因。他们开始讨论“敏捷”过程开销,比如持续数小时的站立会议,或者上层管理者命令他们使用Jira之类的工具减慢了他们的速度,或者比这些更糟,在将任何东西发布到生产环境之前,都需要经过变更委员会。
另一个适用于上限的常用试验是,如果微服务失败,检查一下业务功能的退化程度。如果失去的业务功能不只一个,要么说明你的微服务粒度太粗,应该重构,要么说明太多的业务流程依赖于这一特定微服务(它被放在几种不同的流的关键路径上)。
总结一下。微服务是一种出色的架构创新,它有可能彻底改变我们多年遇到的单体架构问题。当在适当的粒度级别上实现微服务架构时,系统会敏捷,并减少决策的影响范围,而且效果相当明显。
但微服务并不是万能药。在成功地应用微服务之前,团队在DevOps和敏捷实践方面必须已经相当成熟。微服务设计应该是一个迭代过程。如果你的团队不能采用该迭代过程,那么要么微服务不适合你的团队,要么你的团队需要改变。我们发现,在修改系统之前,我们通常并不真正知道一组微服务的粒度是否合适。如果你发现实现新业务功能需要修改多个业务微服务,那这种粒度可能不合适(粒度太细)。
【免责声明】本文系本网编辑部分转载,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题,请在30日内与管理员联系,我们会予以更改或删除相关文章,以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。