在实际工作中，我们经常听到“架构”和“架构师”这样的名词，并不新鲜，但是总让很多刚入门的人感觉很神秘，甚至是高深莫测。很少有人对“架构”有全面的了解和认识能并说清楚架构是什么，更谈不上掌握了。事实上，也只有极少数人能成为或者被冠以“架构师”这样的title。为此，笔者总结了对架构的一些理解，希望能够补充很多初入门的人在这方面认识上的不足，纠正一些误解。高手和老鸟就直接跳过吧。
- 架构的分类
对于“架构”来讲，理论上划分了5种架构视图，分别是：逻辑架构、开发架构、运行架构、物理架构、数据架构。根据名字，大家都可能大概能猜到其侧重点和含义。这里先用通俗的文字简单介绍下，便于大家理解，大家可以不必纠结概念和这些理论。
逻辑架构：逻辑架构关注的是功能，包含用户直接可见的功能，还有系统中隐含的功能。或者更加通俗来描述，逻辑架构更偏向我们日常所理解的“分层”，把一个项目分为“表示层、业务逻辑层、数据访问层”这样经典的“三层架构”。
开发架构：开发架构则更关注程序包，不仅仅是我们自己写的程序，还包括应用程序依赖的SDK、第三方类库、中间价等。尤其是像目前主流的Java、.NET等依靠虚拟机的语言和平台，以及主流的基于数据库的应用，都会比较关注。和逻辑架构有紧密的关联。
运行架构：顾名思义，更关注的是应用程序运行中可能出现的一些问题。例如并发带来的问题，比较常见的“线程同步”问题、死锁问题、对象创建和销毁（生命周期管理）问题等等。开发架构，更关注的是飞机起飞之前的一些准备工作，在静止状态下就能规划好做好的，而运行架构，更多考虑的是飞机起飞之后可能发生的一些问题。
物理架构：物理架构，更关注的系统、网络、服务器等基础设施。例如：如何通过服务器部署和配置网络环境，来实现应用程序的“可伸缩性、高可用性”。或者举一个实际的例子，如何通过设计基础设施的架构，来保障网站能支持同时10W人在线、7*24小时提供服务，当超过10W人或者低于10W人在线时，可以很方便的调整部署架构来支撑。
数据架构：数据架构，更关注的是数据持久化和存储层面的问题，也可能会包括数据的分布、复制、同步等问题。更贴切来讲，如何选择需要的关系型数据库、流行的NOSQL，如何保障数据存储层面的性能、高可用性、灾备等等。很多时候，和物理架构是有紧密联系的，但它更关注数据存储层面的，物理架构更关注整个基础设施部署层面。
上面讲了那么多，相信国内很少有公司是严格按照这五种视图去分工和设计的。其实在笔者眼中，架构大致分为两种：软件架构、系统架构。前三种视图，可以归纳为软件架构，而后两种架构，则归为系统架构。这也比较符合国内大部分中小型互联网公司的现状。
根据应用特性的不同，关注侧重点可能不同。例如，某些门户类的互联网应用，读多写少而且业务相对比较简单，则更加关注“高性能、可伸缩性、可用性”等方面。对于更加复杂的应用，例如电商类大规模交易型的应用，对每个层面和每个环节都会比较关注。对于业务型的系统，例如一些生产型企业使用的ERP，或者仅供企业内部使用的一些MIS、OA应用，通常更关注功能和复杂的业务和实现和扩展，而对性能等方面又可能不要太高，这类应用则更关注纯软件架构层面。这里，不展开做具体讨论。所以很多时候，架构师也需要是一个团队，而不是一个人“全栈”。
