课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
单体架构与面向服务架构都是软件开发程序员在开发软件的时候会经常用到的一些软件架构方式,下面我们就通过案例分析来了解一下,单体架构与面向服务架构的区别。
单体设计并不意味着无法实现拥有单一责任的服务设计。实际上,因为在单体架构中,所有的模块都很易于访问,随着时间的推移,界限很变得非常模糊,如果需要的话,将系统拆分为更小的部分将会变得越来越难。
根据我的经验,单体架构在早期的迭代中速度会比较快,但是随着时间的推移,变更的迭代速度会变得越来越慢。对于如今的初创公司和小规模团队来讲,这个特点使得单体架构依然是一个很有价值的应用开发方式。
如果业务一切进展顺利的话,现在你需要每秒钟为大量的请求提供服务(因为你的产品有越来越多的客户),准确的说,在要求应用99.9%的时间都能正常访问的情况下,单体设计的局限性就开始出现了。
许多团队在达到某种状态时,都会面临相同模式的问题:
持续部署慢得令人痛苦,因为每个变更都需要构建整个包并重新部署。
缓慢的持续部署导致了缓慢的持续集成,这会导致在每次变更后运行的测试数量不断减少。
曾经的快速代码库变成了一个雷区,即便是微小的变更也是如此,因为工程人员无法知道他们所做的变更的影响是什么。
面向服务结构风格的优势恰好对应着单体架构局限性。这并不是一个巧合。当然,这种风格的设计带来的影响不仅仅是积极的,它们对基础设施设计的要求在增加。分布式系统实现起来并不容易。但是,面向服务架构的优点是多于缺点的:
更快的部署,每次部署之后都会有更高的测试执行率。
蓝-绿更新会很容易(相对来讲),这会限制每个服务的停机时间。
工程师对他们的变更的爆炸半径会更有信心,因为他们知道模块的依赖图。
进行扩展的时候不再局限于添加更多的机器来运行重复的单体应用,而是可以进行垂直扩展。
当我被问到这两种方式该选择哪种时,我一般倾向于回答“视情况而定”,随后我经常会得到一个不满意的表情。尽管如此,在有利于组织规模扩展方面,面向服务架构的优势是不容忽视的。
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。