人人都是架构师:面对风险

架构包含技术的选择,更多分层等于更高的复杂度,但是轻量级协同设计可以提高质量。最佳实践也是有使用条件限制的,面对架构要用于质疑。

系统的最大风险

外部接口是系统风险最高的部分之一。

- 关键的外部接口有哪些?接口的技术定义是什么?

- 哪些队列是通信组件?消息的格式是什么?

- 同步还是异步?异步连接是否有保障?能否乱序传输?

- 接口是否幂等?接口的可用性、性能、可伸缩性、安全性?

- 接口的所有权属?版本的升级处理?服务级别?

系统的常见风险

除了外部接口之外,其他的常见风险如下:

- 组件运行过慢

- 组件无法伸缩

- 关键组件崩溃

- 单点故障

- 数据被破坏

- 基础设施故障

- 磁盘满

- 新技术过于复杂

文档

架构需要以文档的方式回答质疑。

代码不会讲述完整的故事,轻量级文档来描述代码之外的问题,如

  • 这是关于什么的?希望能做什么?
  • 质量属性?约束?原则?
  • 软件架构?外部接口?
  • 数据(数据比软件本身更重要。)?
  • 基础设施架构?
  • 部署?运营和支持?
  • 决策日志
  • ……
时间: 2024-10-14 10:05:39

人人都是架构师:面对风险的相关文章

人人都是架构师

http://www.devdiv.com/blog-1895-57919.html 架构是什么?业界并没有权威的说法. 架构作为名词与结构相关,将产品分解为一系列组件.模块和交互.作为动词,是关于交流愿景和引入技术领导力的,简而言之,架构就是结构和愿景. 关于架构 应用程序的架构着重于软件和代码的组织,每个工程师的代码都是有架构的,只是自发和自觉的区别:系统架构描述从组件和服务到子系统等更高层次的抽象含软硬件,从代码结构到生产环境,与软件系统重要元素相关的所有东西就是软件架构.企业架构是一个截

人人都是架构师:非功能性需求

需求是最重要的事情,失去了功能,失去了客户的价值,软件将一无是处. 然而,功能的实现只是架构的开端. 架构首先来自需求,需求驱动架构,然后非功能性需求反映服务等级,面对客观环境的约束,自行引入的架构实现原则,是在高层次以上对需求.约束.和原则的理解和把握. 非功能性需求也可以称为质量属性,我所了解的非功能性需求主要有: 性能:响应时间或延迟 可伸缩性:更多用户,请求和数据的处理能力 可用性:99.9%意味着每天一分钟故障 安全性: 可以参考OWASP,open web application s

人人都是架构师: 约束和原则

约束 时间和预算是约束的基本条件. 技术约束 技术清单,现有系统的互操作性(兼容性),目标部署平台,技术成熟度(保守),开源技术,供应商关系(阿里云,还是AWS),过去的失败,内部知识产权 人员约束 团队规模,技能,团队扩展的速度,咨询和培训,运维团队的技能 组织约束 企业战略的影响,办公室政治的影响 约束条件也是有优先级的. 原则 开发原则 编码标准和规范,自动化单元测试,静态分析工具 架构原则 1)分层策略,如UI组件里没有数据访问的逻辑 2)业务逻辑的位置: 3)高内聚.低耦合:解耦合可以

每周荐书:我的世界、架构师、OpenStack(评论送书)

上周的荐书活动大家如此踊跃热情,看得出来在座各位都是爱书之人. 既然大家这么捧场,小编决定赠书数量翻倍,从这周开始每本书选出2位中奖用户. 先来公布一下上期中奖用户! Doem <Spring MVC实战> 工匠若水 <Python大战机器学习:数据科学家的第一个小目标> bit_kaki <Android移动性能实战> 中奖通知由CSDN官方发布站内消息,请关注消息通知~ 活动规则: 在文末评论里回复你对本周推荐图书的看法,或想要获得某本书的书名及理由 下期荐书更新时

App架构师成长路线

点击关注 异步图书,置顶公众号 每天与你分享 IT好书 技术干货 职场知识 参与文末话题讨论,每日赠送异步图书 --异步小编 架构师,软件技术领域一个高大上的名词,业界有言"人人都是产品经理",却很少听到"人人都是架构师".其本身涉及的复杂庞大的跨领域知识体系除外,对于架构一词,其实很难去完整地定义,我们也没必要过于纠结,就如我们为什么要登山,因为山在那里,执着前行,或许还未曾知晓路在何方,抑或你都不曾思考要去何方,但至少你已经在路上,while(!(succeed

架构师修练 I - 超级代码控

可实现的是架构,空谈是概念 So don't tell me the concepts show me the code!  “不懂编码的架构师不是好架构师” 好架构师都是超级代码控. 代码是最好的老师 从代码中学习设计的思想.方法是提升类库设计能力.印证你所了解的概念与理论这就是架构师看代码的观点. 基本准备 一个类库可能有数千个类上万个方法,应该如何去看呢? 在看代码前我们需要进行一些什么样的准备呢 ? 设计模式 - 最标准的23种设计模式基本上要有一个了解,可能一下子不能理解他们的用法,但

全栈软件工程师和系统架构师的异同

看完后.发现.不用怕....因为程序员不会看完.只有"架构师"才有耐心看这么长的. 一 每个好架构师都是一位出色的程序员(卓越的程序员) 架构师,听起来是如此神秘的一个称号.尤其是在开发领域刚入门不久的菜鸟级程序员眼中,架构师都是高手,都是牛人,都是如此高高在上的存在. 不过,在搞了四.五年编程之后,程序员们往往早已失去了当年对这些"高级"职位的神秘感,甚至会对自己所在项目的架构师抱怨不已,背后里称他们是一群水王.所以有江南白衣曾撰文述说:"国内的架构师到

架构师修炼 II - 表达思维与驾驭方法论

开篇之前我想先说说当年开发的那点事儿:大约10年前吧,我还是一个程序员的时候经常都是遇到这样的项目开发流程: 解决方案 :满足客户目的和投标用的一堆文档(不少还是互联网上抄的) ,是以Word为主的纯文字. 投标完成和客户付订金后项目组成立,通常为(0至1)个项目经理或者叫项目负责人+(1至N)个程序员 的项目组模式 设计:由项目的头或者经验最足的成员参与编写设计.倒霉的时候我们会得到一份按照软件工程学的纯中文形式的设计想法(抱歉我只能这样来形容),而更遭的情况是得到一份完全看不懂的Rose文档

架构师成长之路(1)--什么是架构师(目标)

前言: 哲学家常思考的问题:" 我是谁?"" 我从哪里来?"" 要到哪里去?不只是哲学家,我想每个人都有自己对这三个问题的认知. 如果我们要成为架构师,我们自己要面临的三大问题: 找准自己定位:我是谁?在哪里? 怎样做好架构师:我要做什么? 如何搭建架构师知识体系:我该怎么做? 这里面就是做事方法论:目标(我要做什么),方法(计划)(我该怎么做),  执行/行动 软件行业架构师两个定义 ?系统架构师是一个既需要掌控整体又需要洞悉局部瓶颈并依据具体的业务场景