成为架构师也许是大部分 IT 人士的目标, 我也不例外, 但在与同事 (同行) 的交流中, 我发现大部分人对架构的理解都是比较片面的, 例如:

• 运维人员会认为架构师的职责在于为系统提供一个可伸缩、高并发、高可靠的开发/生产环境;
• 而开发的眼中, 却认为架构师就是设计出高内聚低耦合、可维护、可扩展的程序代码, 甚至还有些人认为架构就是分层, 比如 “三层架构”（或者四层、五层…反正分层越多就说明项目越复杂而且架构就越牛）.

那哪种说法正确呢?

其实都正确, 只是所处的方向不同, 架构师是一个统称, 不同的架构方法论, 会将架构分为不同视图, 每个视图侧重某一个方面、领域的问题.

比如希赛推的 ADMEMS 架构体系, 分为以下几种视图:

• 物理架构: 描述机器的物理部署、网络拓扑方面.
• 数据架构: 描述数据的存储结构、格式等方面.
• 运行架构: 描述运行期线程、进程间的交互工作机制.
• 逻辑架构: 指如何将代码分成不同模块、组件, 以及之间的职责分配、交互行为.
• 开发架构: 主要指开发工具的选择, 程序单元的划分, 开发管理规范流程等方面. 例如分为哪些工程、项目, 源代码管理, 自动化编译构建、测试、部署等.

目前国际上运用比较广泛的是 TOGAF 架构体系, 它把架构分为业务架构、数据架构、应用架构、技术架构等几个方面.

实际上很少有公司是严格按照这五种视图去分工和设计的, 在我看来, 架构师大致分为两个方向: 系统架构师（有些企业叫运维架构师）和软件架构师. 前两种视图, 可以归纳为系统架构, 而后三种架构, 则归为软件架构.

• 系统架构师 (运维架构师)
  • 物理架构
  • 数据架构
• 软件架构师
  • 运行架构
  • 逻辑架构
  • 开发架构

在国内大部分中小型互联网公司, 基于处于这种现状, 有些牛逼的人士则身兼两职 (这是不是应该叫 CTO?), 我记得以前有人曾总结过: 天朝的架构师就是会运维的高级开发.

我的方向是软件架构师, 私认为一个软件架构师的职责应该会贯穿整个软件生命周期:
需求分析 -> 概要设计 -> 详细设计 -> 代码实现 -> 集成构建、QA -> 反复迭代 -> 项目交付.

• 概要设计是黑盒设计, 系统功能的实现可能需要一些外部参与者, 概要设计即表达出各系统间的关系及交互, 属于”外部”设计.
• 详细设计是白盒设计, 逻辑架构的划分 (分层)、模块的划分、模式的选择、接口的设计、数据库建模等等, 属于”内部”设计.

如果成为软件架构师? 参考: 从程序员到软件架构师

我的这篇 blog 的标题是 “浅聊”, 目的是为了让 IT 新人理解什么是架构师, 以及架构师的职责 (只是我个人的理解), 而至于到底要怎么设计, 就又是另一套可发散性的讨论话题了, 也根本没有什么固定标准可言, 但基本思想是相通的, 重要的东西还是需要以心传心~