如何衡量架构合理性

衡量架构的合理性

架构为业务服务,没有最优的架构,只有最合适的架构,架构始终以高效,稳定,安全为目标来衡量其合理性。

架构设计本质就是解决软件复杂度带来的问题,软件复杂度表现形式有很多种,比如业务复杂度、性能复杂度、可用性复杂度、可扩展性复杂度、安全复杂度等;任何一个系统都有它侧重解决的复杂度问题,理解每个架构方案背后需要真正解决的是软件复杂度的什么问题,是评判一个架构设计目的性的关键因素,这也是做架构设计中常提的系统约束条件。

业务复杂度体现的是如何来拆解业务,找到合适的软件元素和组件,按合适结构进行连接;性能复杂度体现的是找到软件元素,进行合适连接形成一定结构,达到高性能要求。比如说一个大型ERP系统,属于业务复杂度高的系统,你该如何去拆分它,拆分成一个个独立完备、具有明确业务边界的组件,这是做架构设计需要思考的。再比方说做一个秒杀系统,系统复杂度要求就是性能复杂度,怎么能扛住秒杀的洪峰,这是性能复杂度需要解决的问题。

合理的架构设计:

5.1. 业务需求角度

能解决当下业务需求和问题
高效完成业务需求: 能以优雅且可复用的方式解决当下所有业务问题
前瞻性设计: 能在未来一段时间都能以第2种方式满足业务,从而不会每次当业务进行演变时,导致架构翻天覆地的变化。

5.2. 非业务需求角度

①. 稳定性。指标:

高可用:要尽可能的提高软件的可用性,我想每个操作人都不愿意看到自己的工作无法正常进行。黑盒白盒测试、单元测试、自动化测试、故障注入测试、提高测试覆盖率等方式来一步一步推进。
②. 高效指标:

文档化:不管是整体还是部分的整个生命周期内都必须做好文档化,变动的来源包括但不限于BUG,需求。
可扩展:软件的设计秉承着低耦合的理念去做,注意在合理的地方抽象。方便功能更改、新增和运用技术的迭代,并且支持在适时对架构做出重构。
高复用:为了避免重复劳动,为了降低成本,我们希望能够重用之前的代码、之前的设计。这点对于架构环境的依赖是最大的。
③. 安全指标

安全:组织的运作过程中产生的数据都是具有商业价值的,保证数据的安全也是刻不容缓的一部分。以免出现XX门之类丑闻。加密、https等为普遍手段

本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
THE END
分享
二维码
< <上一篇
下一篇>>