基于微服务的架构风格的兴起是不可否认的。 如果滚动浏览黑客新闻或浏览/ r / programming subreddit,您将在某处看到有关样式的提及。
许多人认为,基于微服务的体系结构是完善软件体系结构设计的目标。 对于许多应用程序来说,它确实是有道理的,它为您提供了许多关键优势,例如,提高了弹性,适度降级,弹性等。
但是,迁移我们的系统的过程将是一条漫长而艰巨的路,并且如果开发人员的心态,教育系统以及进入系统的高门槛(即分布式系统的复杂性)发生重大变化,我们可能永远无法达到理想的目标状态。
管理心态
渴望追求更好的建筑风格和重构现有整体的开发人员的数量正在增长。 问题不在于开发人员的想法,而在于高层管理人员。
在执行重构工作并提高团队技能以更好地处理分布式系统的复杂性的同时,无法进行新的工作。 在稳定的公司中,这可能不是已经拥有专用用户群的大问题,但对于希望削减市场份额的新公司而言,这可能是一个巨大的缺点。
在大多数情况下,高层管理人员会选择使用新功能或产品的新版本,以潜在地赚取更多的收入。 随后,他们追求短期收益,而不是巩固当前的软件生态系统并向新的体系结构风格迁移。
教育制度
为了使我们开始迁移到这种较新的体系结构,需要来自高层(管理层)和底层(毕业生)的压力。 这意味着刚进入工作场所的应届毕业生必须能够理解基于整体和基于微服务的架构风格之间的差异。
后来在大学期间,我们被教导了诸如设计模式和SDLC之类的关键概念,但是是否可以将更多的重点放在关注这种建筑风格上呢?
这是我很伤脑筋的事情,而架构的微服务风格似乎将继续存在,而不仅仅是一时的流行,这是否意味着我们对通过软件工程和计算机科学等课程学习的学生施加了更大的压力学习这些?
顺便说一句 :我强烈建议任何刚毕业的程序员萨姆·纽曼(Sam Newman)的书: 构建微服务:设计精细系统
分布式系统的复杂性
无疑,这是所有开发人员进入的最大障碍。 在普遍采用这种架构风格之前,我们需要全面改善工具,以简化管理这些分布式系统的人员的生活。
Zipkin,Kubernetes和Docker之类的工具肯定已经开始平稳过渡到这种架构风格,AWS的新EKS(弹性kubernetes服务)在进步方面迈出了一大步,但我们需要更多的参与者来加紧努力。
最终一致性与强一致性
涉及分布式系统的主要挑战之一是一致性。 与传统的体系结构样式相比,必须在整个技术堆栈中管理这种一致性构成了一个挑战,并且您必须意识到诸如“高一致性”之类的成本,以及在某些情况下它如何严重影响性能。
这仅是开发人员面临的最大问题之一,即开发人员设计的系统应遍及全球数百个或数千个微服务。
结论
这些只是我的一些想法,我对这些想法都不是一成不变的。 当我写这样的文章时,我绝不是说我所写的一切都是绝对的,我只是想开始对话。
如果您对我在上面写的内容有任何评论,请随时在下面的评论部分中告诉我,或者在Twitter上与我联系: Elliot Forbes 。
From: https://hackernoon.com/why-the-monolith-will-forever-reign-supreme-f9e144a034b1