逻辑架构和物理架构

在实际工做中，咱们常常听到“架构”和“架构师”这样的名词，并不新鲜，可是总让不少刚入门的人感受很神秘，甚至是高深莫测。不多有人对“架构”有全面的了解和认识能并说清楚架构是什么，更谈不上掌握了。事实上，也只有极少数人能成为或者被冠以“架构师”这样的title。为此，笔者总结了对架构的一些理解，但愿可以补充不少初入门的人在这方面认识上的不足，纠正一些误解。高手和老鸟就直接跳过吧。html

• 架构的分类

对于“架构”来说，理论上划分了5种架构视图，分别是：逻辑架构、开发架构、运行架构、物理架构、数据架构。根据名字，你们均可能大概能猜到其侧重点和含义。这里先用通俗的文字简单介绍下，便于你们理解，你们能够没必要纠结概念和这些理论。程序员

逻辑架构：逻辑架构关注的是功能，包含用户直接可见的功能，还有系统中隐含的功能。或者更加通俗来描述，逻辑架构更偏向咱们平常所理解的“分层”，把一个项目分为“表示层、业务逻辑层、数据访问层”这样经典的“三层架构”。web

开发架构：开发架构则更关注程序包，不只仅是咱们本身写的程序，还包括应用程序依赖的SDK、第三方类库、中间价等。尤为是像目前主流的Java、.NET等依靠虚拟机的语言和平台，以及主流的基于数据库的应用，都会比较关注。和逻辑架构有紧密的关联。面试

运行架构：顾名思义，更关注的是应用程序运行中可能出现的一些问题。例如并发带来的问题，比较常见的“线程同步”问题、死锁问题、对象建立和销毁（生命周期管理）问题等等。开发架构，更关注的是飞机起飞以前的一些准备工做，在静止状态下就能规划好作好的，而运行架构，更多考虑的是飞机起飞以后可能发生的一些问题。数据库

物理架构：物理架构，更关注的系统、网络、服务器等基础设施。例如：如何经过服务器部署和配置网络环境，来实现应用程序的“可伸缩性、高可用性”。或者举一个实际的例子，如何经过设计基础设施的架构，来保障网站能支持同时10W人在线、7*24小时提供服务，当超过10W人或者低于10W人在线时，能够很方便的调整部署架构来支撑。设计模式

数据架构：数据架构，更关注的是数据持久化和存储层面的问题，也可能会包括数据的分布、复制、同步等问题。更贴切来说，如何选择须要的关系型数据库、流行的NOSQL，如何保障数据存储层面的性能、高可用性、灾备等等。不少时候，和物理架构是有紧密联系的，但它更关注数据存储层面的，物理架构更关注整个基础设施部署层面。安全

上面讲了那么多，相信国内不多有公司是严格按照这五种视图去分工和设计的。其实在笔者眼中，架构大体分为两种：软件架构、系统架构。前三种视图，能够概括为软件架构，然后两种架构，则归为系统架构。这也比较符合国内大部分中小型互联网公司的现状。服务器

根据应用特性的不一样，关注侧重点可能不一样。例如，某些门户类的互联网应用，读多写少并且业务相对比较简单，则更加关注“高性能、可伸缩性、可用性”等方面。对于更加复杂的应用，例如电商类大规模交易型的应用，对每一个层面和每一个环节都会比较关注。对于业务型的系统，例如一些生产型企业使用的ERP，或者仅供企业内部使用的一些MIS、OA应用，一般更关注功能和复杂的业务和实现和扩展，而对性能等方面又可能不要过高，这类应用则更关注纯软件架构层面。这里，不展开作具体讨论。因此不少时候，架构师也须要是一个团队，而不是一我的“全栈”。网络

• 架构设计究竟是什么

在长期的技术招聘面试中，我发如今不少人眼中，架构就是分层，架构设计就是“三层架构”（或者四层、五层...反正分层越多就说明项目越复杂并且架构就越牛），或许是受到诸如PetShop之类的示例项目的影响，这里暂时不去追究缘由了。架构

以前已经纠正过不少人的误解-架构不仅是软件架构。说一下通俗点的理解：

软件架构就是实用并且优雅的设计，它不在于分多少层，或者应用了多少种设计模式/架构模式等。它应该是以知足实现用户需求为前提，以开发人员广泛可接受为根本的，并且要符合系统特性和业务发展须要的，从软件设计的角度，可以达到层次清晰、可维护、可重用、可扩展...就很是优秀了，无需刻意去纠结分了多少层，是否使用了什么模式，有多么抽象等。以面向对象设计为例，基本目标是“高内聚、低耦合”，为此咱们可能会遵循一些常见的设计原则（例如经典的SOLID设计原则）。最后纠正一点，一般咱们所说的模式，其实又分为不少种，并非仅仅指的是“设计模式”（设计模式也有千千万，并非只有常见的GOF 23种设计模式）。一般包括：企业架构模式、设计模式、SOA模式、企业集成模式等等。

强调一下，架构要讲求“实用”，并且开发人员广泛可接受，要符合现状的。不然，再“优雅”的设计，都会沦为高成本的“花架子”，生搬硬套和过分设计只会让项目“流产”。

• 关于Tier和Layer

笔者曾屡次在一些技术社区和论坛看到一些关于Tier和Layer的争论，众说纷纭。其实最容易被普遍承认和接受的理解就是：Tier一般指的是物理上的分层，由执行一样功能的一台（或者一组）服务器定义。而Layer一般指的是逻辑上的分层，对于代码的组织，例如：咱们一般提到的“业务逻辑层，表现层，数据访问层”等等。

Tier指代码运行的位置，多个Layer能够运行在同一个Tier上的，不一样的Layer也能够运行在不一样的Tier上，固然，前提是应用程序自己支持这种架构。以J2EE和.NET平台为例，大多数时候，不一样的Layer之间都是直接经过DLL或者JAR包引用来完成调用的（例如：业务逻辑层须要引用数据访问层），这样部署的时候，也只能将多个Layer同时部署在一台服务器上。相反，不一样的Layer之间若是是经过RPC的方式来实现通讯调用的，部署的时候，即可以将不一样的Layer部署在不一样的服务器上面，这也是很常见的解耦设计。

以下图所示：

顺便再纠正一点，不少人问“到底什么是web服务器，什么是应用服务器”。这个恐怕没有标准答案的。有些人可能以为，处理静态资源的就是web服务器，处理动态请求的就是应用服务器，这实际上是不许确的。以互联网领域典型的SOA架构为例，上层Web应用所在的服务器，能够叫web服务器，web应用仅仅负责处理输入/输出，而提供服务宿主的服务器能够称为应用服务器（也包含对业务逻辑和数据访问的处理）。固然，服务的宿主方式能够有不少中，能够是系统服务，是可执行程序，是web应用，是Socket网络服务...

架构师每每是不少开发人员向往的职业，也不是像不少人想象中的那样（画一下PPT或者UML草图，而后交给程序员们去实现，而后本身就自由玩耍了）。国内不少公司，是没有架构师这种岗位定义的，一般是由技术优秀和经验比较丰富的开发人员担任，身兼多职的状况也并很多见（我见过不少小公司的骨干人员是身兼技术主管、系统分析师、项目经理、架构师、核心开发人员...）。值得纠正的就是，架构师和系统分析师不一样，系统分析师更侧重在项目早期的需求分析。而架构师，通常贯穿整个软件开发周期，与项目经理也是相辅相成的。微软对于架构师，又分为：软件架构师、系统架构师、解决方案架构师、企业架构师等。而其它一些厂商，可能又会划分:技术架构师、业务架构师、网络架构师、安全架构师、SOA架构师......

你们没必要对这些概念太纠结。按照笔者的理解，国内大互联网公司里，架构师通常只会分2-3个方向：软件架构师和系统架构师（有些企业叫运维架构师），有些企业对于比较资深DBA并且懂整个系统架构的，还会分出所谓的“数据架构师”。至于具体Title，大可没必要纠结，只需了解本身的兴趣，知晓了大体发展和定位，而后朝该方向努力便可。对于程序员而言，最基本的仍是先写出高质量的代码，在实战中逐步提高本身设计思惟。

限于笔者水平和理解有限，文中所有文字和描述等全凭笔者记忆和理解写出，不免出现错误，请热心的读者及时批评和指正。

因为时间有限，部分图片笔者画的比较粗糙，也请读者谅解。

本文出自http://www.cnblogs.com/dinglang，转载请注明出处。