关于架构师的一点理解

用户头像
石印掌纹
关注
发布于: 2020 年 06 月 10 日
关于架构师的一点理解

一直秉承一个观点:业务推动技术

我们追求完善的架构,可以处理数以百亿级的流量,多少多少万的并发,但是,当脱离业务的时候,再优秀的架构都毫无意义。就想我们不可能指望一个车管所后台系统可以达到淘宝的架构水平,那本身就没有任何意义。

架构绝非为了炫技。做技术要踏踏实实。

架构师其实并非一个职位。确实,当线上的流量突然激增,服务器告警,CPU飙升,接口500,服务雪崩,紧张万分,茫然无措,不知道饭碗还能不能捧得住。然后,开始解决问题,定位梳理,抽丝剥茧,绞尽脑汁。问题处理完继续想事故邮件怎么写,还有最重要的:我们之后如何避免?架构因此而演进。

没有经历过线上事故很难相信这个人会成为一个合格的架构师。刨除技术高低不谈,如果在慌乱一团的时候无法冷静,迅速,精确的定位解决问题,平常的侃侃而谈又有何意义?

不会可以学习,技术日新月异,既然入了编程的门,就意味着毕生学习。

工作为了赚钱这无可厚非,但如果心中无法像对待艺术品一般保持着对技术苛求与完美的追逐,势必也无法成为一名合格的架构师,个人理解这也是极客精神的一部分。



以下是本周知识点的总结:

  • 4+1试图模型:通过多种视图,层面,纬度对各个业务团队解析架构模型

  • 逻辑试图(Logic View),设计对象模型—>针对客户,开发组织管理者

  • 过程试图(Process View),捕捉设计的并发和同步特征—>性能优化,针对开发人员

  • 物理试图(Physical View),描述软件到硬件的映射,反映部署特性

  • 开发试图(Development View),描述开发环境中软件的组织结构—>针对开发设计人员

  • 场景视图(Scenarios),描述用例场景—>针对用户和开发人员,架构存在的意义

  • 结合现实业务场景,抽象架构模型

  • 为何要建模:为了阐述清楚产品架构最终要起到的目的,功能需求,实现过程,如同提纲目录,让开发者有效的了解用户需求

  • 部署图

  • 概要设计阶段:体现设计系统部署在哪些服务器,需要多少服务器

  • 时序图

  • 需求分析阶段(系统级时序图)

  • 概要设计阶段(组件和服务器之间的时序图)

  • 活动图

  • 需求分析阶段:通过活动图画出业务流程

  • 概要设计阶段:体现不同领域,模块,子系统之间的合作处理流程

  • 详细设计阶段:方法内部处理流程,如果较为复杂也可以用活动图体现

  • 组件图

  • 概要设计阶段:体现各组件依赖关系,动态交互关系,开发依赖关系

  • 架构设计建模顺序:部署图—>系统级时序图—>活动图—>组件图—>类图—>状态图

  • 架构设计评价:第一优先级是否适合场景,而不是技术难度



用户头像

石印掌纹

关注

还未添加个人签名 2018.11.22 加入

还未添加个人简介

评论

发布
暂无评论
关于架构师的一点理解