有一个稳定运行的采集硬件设备信息的平台,现在有一个需要使用root
用户下发命令采集数据的需求,但系统默认设置为通用用户权限操作,只能操作一些常见的命令去采集运行时的状态和设置非高危的配置参数。
初步确定的解决方案为:①修改系统功能项以长期支持此类任务;②以脚本的形式外挂任务。第一种方案适用于真需求,此后有大量这类任务需要执行的情况,缺点是开发周期长和成本高。第二种方案适用于期望需求或者临时使用,特点是能短时间内解决问题和成本相对较低,缺点是定制化要求高,要求平台文档齐全对平台业务逻辑熟悉。
但现实情况是第一种方案容易影响到原有的采集任务,而且还会影响到另外一个数据平台,涉及的两个平台的重构。而第二种方法目前显然更加受到青睐,挑战依然存在,绕过登录模块后与其他模块对接是否会对系统造成安全威胁?平台是否预留这样的API接口?外挂脚本稳定性能否得到保证?
这里我突然就想到了软件架构评估
中提到的:敏感点、权衡点。下面先从网上找一个对软件架构评估
几个点描述最清楚的文字。
敏感点:为实现某一特定质量属性,一个或多个构件(或构件之间的关系)的特性。
权衡点:是影响多个质量属性的特征,是多个质量属性的敏感点。
风险点:架构设计中潜在的、存在问题的架构决策所带来的隐患。
非风险点:是指不会带来隐患,一般以“xxx要求是可以实现(或接受)的”方式表达。
敏感点举例:
1.燃油效率:这关系到日常使用时的油耗成本,是一个重要的质量属性。
2.安全性:车辆的安全特性也是一个重要的质量属性,涉及乘坐人员的安全。
3.购车预算:这是另一个质量属性,它影响你的选择范围和购车的可能性。
权衡点举例:
1.购车预算与车辆性能:购车时的预算与车辆性能之间的选择是一个权衡点。你可能会在购买一辆价格昂贵、配置高级的新车和一辆价格适中、配置适中的车之间进行权衡。
2.空间与便利性:对于有孩子的家庭,车辆的空间是一个重要因素,但大车可能在城市中不那么方便停车和驾驶。
在这个例子中,假设你正在考虑购买新车,并且有以下需求:燃油效率要高(敏感点),安全性要好(敏感点),但预算有限(权衡点)。这时,你可能会发现一些燃油效率高的车型可能安全性评分不高,或者符合前两个条件的车型超出了你的预算。
最终,你可能需要选择一个符合预算(成本效益),同时在燃油效率和安全性方面表现平衡的车型。这就是一个生活中的权衡点,你需要根据个人或家庭的具体需求和限制来决定最佳选择。
商城类项目的敏感点和权衡点通常体现在不同的系统组件和架构设计中。以下是一些具体的例子:
敏感点举例:
1.数据库性能:对于商城系统来说,数据库的读写性能是一个敏感点,因为它直接关系到用户在浏览商品、下单等操作时的响应速度。
2.支付系统安全性:支付系统的安全性是另一个敏感点,需要确保用户的交易信息不被泄露或篡改。
3.搜索功能的准确性:商城中的搜索功能准确性也是一个敏感点,它影响着用户能否快速找到想要的商品。
权衡点举例:
1.缓存策略:缓存策略是一个典型的权衡点,它同时影响系统的响应速度和数据的实时性。例如,增加缓存可以提高性能,但可能会导致数据更新延迟。
2.服务器配置:服务器的配置也是一个重要的权衡点,高性能的服务器可以提高系统的整体响应速度,但也会增加成本。
3.库存显示策略:商城中库存显示的策略也是一个权衡点,实时更新库存可以提供准确的信息给用户,但这可能会对数据库造成较大压力。
总的来说,通过这些例子可以看到,商城类项目中的敏感点通常是针对单一质量属性的特定设计或组件,而权衡点则涉及到多个质量属性之间的平衡。在实际的架构设计中,工程师需要根据项目的具体需求和资源限制来确定最佳的设计方案。
着重看敏感点
和权衡点
在案例中的体现。首先敏感点中描述:一个或多个构件可以类比为小平台与其他平台整合后的关系。所共有的特性,在于我们修改本平台的功能项会影响到其他的平台,因为多个平台都是使用相同的思想和实现逻辑以及对本平台的依赖。如果修改其中一个平台而不修改其他的平台相应功能的思想和实现逻辑,那就失去了一致性,在今后的数据对接和维护以及复用方面会受到影响。敏感点
理论主要是站在构件的角度去看待问题,在这个案例中,一方面需要满足新的业务需求,另一方面要考虑修改构件
所带来的影响。所以构件
的敏感点也就是:
1.平台间的一致性(是否影响其他平台);
2.平台的安全性(外挂脚本是否破坏安全行)。
其次就是权衡点中的描述:是影响多个质量属性的特征,而且还是多个质量属性的敏感点,这里有些抽象我在网上参考的解释是:权衡点
理论主要就是站在构件交互的角度来看待问题的,重点在于交互
和关系
上。那么此次案例中的权衡点应该是:
1.完善性维护(对原有功能的补充);
2.可修改性(人力、时间成本高低)。
所以对于这个功能需求可能带来的挑战,不仅仅只是一次功能的开发,还要站在架构师的角度,用专业理论作为依据动态的评判方案的优劣。