开发流程中之技术架构评审的目标包括哪些方面?-问答-阿里云开发者社区-阿里云

开发者社区> 问答> 正文

开发流程中之技术架构评审的目标包括哪些方面?

Lee_tianbai 2020-12-30 18:32:35 107

开发流程中之技术架构评审的目标包括哪些方面?

分享到
取消 提交回答
全部回答(1)
  • Lee_tianbai
    2020-12-30 18:33:39

    互联网时代,大家提倡敏捷迭代,总嫌传统方式太重,流程复杂,影响效率,什 么都希望短平快,在扁平化的组织中,经常是需求火速分发到一线研发,然后就靠个 人折腾去了,其实技术架构评审这同样是一个非常重要的环节。架构评审或技术方案 评审的价值在于集众人的力量大家一起来分析看看方案里是否有坑,方案上线后是否会遇到不可逾越的重大技术问题,提前尽可能把一些事情先考虑到提出质疑其实对项 目的健康发展有很大的好处。 基于架构评审,我们的目标核心是要满足以下几点: 1. 设计把关,确保方案合格,各方面都考虑到了,避免缺陷和遗漏,不求方案 多牛,至少不犯错。 2. 保证架构设计合理和基本一致,符合整体原则。 3. 维持对系统架构的全局认知,避免黑盒效应。 4. 通过评审发掘创新亮点,推广最佳实践。 5. 架构设计既要保证架构设计的合理性和可扩展性,又要避免过度设计。架构设计 不仅仅是考虑功能实现,还有很多非功能需求,以及持续运维所需要的工作,需要工 程实践经验,进行平衡和取舍。 架构评审需要以下几点: 1. 技术选型:为什么选用 A 组件不选用 B、C 组件,A 是开源的,开源协议是 啥?基于什么语言开发的,出了问题我们自身是否能够维护?性能方面有没 有压测过?这些所有问题作为技术选型我们都需要考虑清楚,才能做最终决定。 2. 高性能:产品对应的 TPS、QPS 和 RT 是多少?设计上会做到的 TPS、 QPS 和 RT 是多少?而实际上我们整体随着数据量的增大系统性能会不会出 现明显问题?随着业务量、数据量的上升,我们的系统的性能如何去进一步 提高?系统哪个环节会是最大的瓶颈?是否有抗突发性能压力的能力,大概 可以满足多少的 TPS 和 QPS,怎么去做来实现高性能,这些问题都需要我 们去思考。 3. 高可用:是否有单点的组件,非单点的组件如何做故障转移?是否考虑过多活 的方案?是否有数据丢失的可能性?数据丢失如何恢复?出现系统宕机情况, 对业务会造成哪些影响?有无其他补救方案?这些问题需要想清楚,有相应 的解决方案。 4. 可扩展性:A 和 B 的业务策略相差无几,后面会不会继续衍生出 C 的业务策 略,随着业务的发展哪些环节可以做扩展,如何做扩展?架构设计上需要考 虑到业务的可扩展性。 5. 可伸缩性:每个环节的服务是不是无状态的?是否都是可以快速横向扩展的? 扩容需要怎么做手动还是自动?扩展后是否可以提高响应速度?这所有的问 题都需要我们去思考清楚,并有对应的解决方案。 6. 弹性处理:消息重复消费、接口重复调用对应的服务是否保证幂等?是否考虑 了服务降级?哪些业务支持降级?支持自动降级还是手工降级?是否考虑了 服务的超时熔断、异常熔断、限流熔断?触发熔断后对客户的影响?服务是 否做了隔离,单一服务故障是否影响全局?这些问题统统需要我们想清楚对 应的解决方案,才会进一步保证架构设计的合理性。 7. 兼容性:上下游依赖是否梳理过,影响范围多大?怎么进行新老系统替换?新 老系统能否来回切换?数据存储是否兼容老的数据处理?如果对你的上下游 系统有影响,是否通知到上下游业务方?上下游依赖方进行升级的方案成本 如何最小化?这些问题需要有完美的解决方案,稍有不慎会导致故障。 8. 安全性:是否彻底避免 SQL 注入和 XSS ?是否有数据泄露的可能性?是否 做了风控策略?接口服务是否有防刷保护机制?数据、功能权限是否做了控制?小二后台系统是否做了日志审计?数据传输是否加密验签?应用代码中 是否有明文的 AK/SK、密码?这些安全细节问题需要我们统统考虑清楚,安 全问题任何时候都不能轻视。 9. 可测性:测试环境和线上的差异多大?是否可以在线上做压测?线上压测怎 么隔离测试数据?是否有测试白名单功能?是否支持部署多套隔离的测试环 境?测试黑盒白盒工作量的比例是怎么样的?新的方案是否非常方便测试, 在一定程度也需要考量。 10. 可运维性:系统是否有初始化或预热的环节?数据是否指数级别递增?业务 数据是否需要定期归档处理?随着时间的推移如果压力保持不变的话系统需 要怎么来巡检和维护?业务运维方面的设计也需要充分考虑到。 11. 监控与报警:对外部依赖的接口是否添加了监控与报警?应用层面系统内部 是否有暴露了一些指标作监控和报警?系统层面使用的中间件和存储是否有 监控报警?只有充分考虑到各个环节的监控、报警,任何问题会第一时间通 知到研发,阻止故障进一步扩散。 其实不同阶段的项目有不同的目标,我们不会在项目起步的时候做 99.99% 的 可用性支持百万 QPS 的架构,高效完成项目的业务目标也是架构考虑的因素之一。 而且随着项目的发展,随着公司中间件和容器的标准化,很多架构的工作被标准化替 代,业务代码需要考虑架构方面伸缩性运维性等等的需求越来越少,慢慢的这些工作 都能由架构和运维团队来接。一开始的时候我们可以花一点时间来考虑这些问题,但 是不是所有的问题都需要有最终的方案。

    0 0
云计算
使用钉钉扫一扫加入圈子
+ 订阅

时时分享云计算技术内容,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。

推荐文章