系统架构
软件架构设计：程序员向架构师转型必备
什么是架构
什么是架构，这是一个困难且模糊不清的问题。总体上而言，架构的定义可以分成两派——组成派和决策派。
组成派的代表性定义是：
软件系统的架构将系统描述为计算组件及组件之间的交互。
基于这种定义，可以用比如UML图来描述一个系统的架构：
比如对于经典的MVC架构，采用MVC架构的软件包含了这样3种组件：Model、View、Controller。
这3种组件通过交互来协作：View创建Controller后，Controller根据用户交互调用Model的相应服务，而Model会将自身的改变通知View，View则会读取Model的信息以更新自身。从此例可以看出，“组件+交互”可以将MVC等“具体架构设计决策”高屋建瓴地抽象地表达出来。
决策派的代表性定义是：
架构是一系列重要决策的集合，这些决策与以下内容有关：软件的组织、构成系统的结构元素及其接口的选择，这些元素在相互协作中明确表现出的行为，这些结构元素和行为元素进一步组合所构成的更大规模的子系统，以及指导这一组织——包括这些元素及其接口、它们的协作和它们的组合——架构风格。
是一系列决策，用什么？
架构视图
一个架构视图是对于从某一视角或某一点上看到的系统所作的简化描述，描述中涵盖了系统的某一特定方面，而省略了与此方面无关的实体。
整个软件团队及客户在面对软件时，所关注的或看到的软件并不是一样的。
系统工程师：由于负责部署和运营维护，他们最关心软件系统基于何种操作系统上、依赖于哪些软件中间件、有没有集群或者备份等部署要求、驻留在不同机器上的软件部分之间的通信协议是什么等决策；
而开发人员：则最关心软件架构方案中关于模块划分的决定、模块之间的接口如何定义、甚至架构指定的开发技术和现成框架是不是最流行的等问题；
...
另一方面，软件架构是个复杂的整体，架构师可以“一下子”把它想清楚吗？当然不能。有关思维的科学研究表明，越是复杂的问题越需要分而治之的思维方式：
- 将“架构视图”作为 分而治之的手段，使架构师可以分别专注于架构的不同方面，相对独立地分析和设计不同“子问题”，这相当于将“整个问题”简化和清晰化了；
- 再也不必担心逻辑层、物理层、功能子系统、模块、接口、进程、线程、消息和协议等设计统统混为一谈了。
这个对科研和工作其实也很有启发。
无论软件架构，还是现实生活，运用“逻辑视图+物理视图”刻画大局，都方便有效。
那么，如何运用“逻辑视图+物理视图”设计一个系统的架构呢？
