关于架构师的一点理解

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

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

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

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

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

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

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



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

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

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

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

• 物理试图（Physical View），描述软件到硬件的映射，反映部署特性

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

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

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

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

• 部署图

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

• 时序图

• 需求分析阶段（系统级时序图）

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

• 活动图

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

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

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

• 组件图

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

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

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