For investors
股价:
5.36 美元 %For investors
股价:
5.36 美元 %认真做教育 专心促就业
软件架构师是大多数软件开发程序员职业发展过程中都会选择的一个发展方向,而本文我们就通过案例分析来简单了解一下,软件架构重要性分析。
架构的本质由一组定义和约束产品技术面的决策组成。无论团队采用哪种方法,无论他们是有意识地还是心照不宣地做出决定,这些决定都是存在的。这些决策专注于产品如何处理质量属性需求(QAR)。
QAR也可以是显式或隐式的,尽管显式的更容易处理并可以确保产品契合它们。例如,用户通常希望在使用产品时能够得到及时响应,而不管有多少人也在使用该产品。显式地声明“响应性”需求以及产品可以支持多少并发用户而不会变成“无法应式”的,将有助于开发团队对他们的技术方法做出更好的决策,比如“系统的速度必须够快”或“系统必须是可伸缩的”这样的声明并不能帮助团队做出更好的技术决策。
评估质量属性需求和设计一个架构来实现这些需求涉及到一些前期规划,这些也是软件系统取得成功的关键驱动因素,原因如下:
软件架构是由质量属性需求驱动的,如果在初的迭代中没有考虑到它们,通常会在软件系统被部署到初始试验阶段之后(只有少量的用户)出现问题。因此,当必须满足关键的质量属性需求(如性能、安全性或可伸缩性)时,可能需要进行重要的架构、设计和代码重构,这可能会出现具有高度易变性的软件架构。此外,如果架构设计没有强有力地实现组件的抽象和隔离,重构的成本可能会飙升。
为解决紧急架构的局限性和满足初的质量属性需求,进行有意识的架构设计是有必要的。例如,除了提供关于系统实际使用情况的有用信息以及关于架构设计的反馈回路之外,在初始架构设计中加入一个简单的监控框架,这对于确保软件系统的弹性和正确性来说是至关重要的。
重构和过度的组件化会导致解决方案的碎片化,以至于没有人能完全理解发生了什么。有可能不知道正在使用的组件是什么版本,也可能没有记录每个组件的服务水平协议(ServiceLevelagreement,SLA)。微服务架构为每个服务使用了单独的数据存储,这可能会导致数据一致性问题。单体系统的可持续性较差,但具有高度的内部一致性。这两种架构各有优缺点。
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。