逻辑架构、开发架构、运⾏架构、物理架构、数据架构
在实际⼯作中，我们经常听到“架构”和“架构师”这样的名词，并不新鲜，但是总让很多刚⼊门的⼈感觉很神秘，甚⾄是⾼深莫测。很少有⼈对“架构”有全⾯的了解和认识能并说清楚架构是什么，更谈不上掌握了。事实上，也只有极少数⼈能成为或者被冠以“架构师”这样的title。为此，笔者总结了对架构的⼀些理解，希望能够补充很多初⼊门的⼈在这⽅⾯认识上的不⾜，纠正⼀些误解。⾼⼿和⽼鸟就直接跳过吧。
架构的分类
对于“架构”来讲，理论上划分了5种架构视图，分别是：逻辑架构、开发架构、运⾏架构、物理架构、数据架构。根据名字，⼤家都可能⼤概能猜到其侧重点和含义。这⾥先⽤通俗的⽂字简单介绍下，便于⼤家理解，⼤家可以不必纠结概念和这些理论。
逻辑架构：逻辑架构关注的是功能，包含⽤户直接可见的功能，还有系统中隐含的功能。或者更加通俗来描述，逻辑架构更偏向我们⽇常所理解的“分层”，把⼀个项⽬分为“表⽰层、业务逻辑层、数据访问层”这样经典的“三层架构”。
开发架构：开发架构则更关注程序包，不仅仅是我们⾃⼰写的程序，还包括应⽤程序依赖的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之间如果是通过RP
C的⽅式来实现通信调⽤的，部署的时候，便可以将不同的Layer部署在不同的服务器上⾯，这也是很常见的解耦设计。
如下图所⽰：
顺便再纠正⼀点，很多⼈问“到底什么是web服务器，什么是应⽤服务器”。这个恐怕没有标准答案的。有些⼈可能觉得，处理静态资源的就是web服务器，处理动态请求的就是应⽤服务器，这其实是不准确的。以互联⽹领域典型的SOA架构为例，上层Web应⽤所在的服务器，可以叫web服务器，web应⽤仅仅负责处理输⼊/输出，⽽提供服务宿主的服务器可以称为应⽤服务器（也包含对业务逻辑和数据
访问的处理）。当然，服务的宿主⽅式可以有很多中，可以是系统服务，是可执⾏程序，是web应⽤，是Socket⽹络服务...
逻辑分层和物理分层的好处
逻辑分层的好处：
1. 代码组织更清晰
2. 更易于维护
3. 更好的代码重⽤性
4. 更好的团队开发体验性
5. 更⾼的代码清晰度
在线代码运行器物理分层的好处：
1. 性能
2. 可伸缩性
3. 容错性
4. 安全性
架构师的分类
架构师往往是很多开发⼈员向往的职业，也不是像很多⼈想象中的那样（画⼀下PPT或者UML草图，然后交给程序员们去实现，然后⾃⼰就⾃由玩耍了）。国内很多公司，是没有架构师这种岗位定义的，通常是由技术优秀和经验⽐较丰富的开发⼈员担任，⾝兼多职的情况也并不少见（我见过很多⼩公司的⾻⼲⼈员是⾝兼技术主管、系统分析师、项⽬经理、架构师、核⼼开发⼈员...）。值得纠正的就是，架构师和系统分析师不同，系统分析师更侧重在项⽬早期的需求分析。⽽架构师，⼀般贯穿整个软件开发周期，与项⽬经理也是相辅相成的。微软对于架构师，⼜分为：软件架构师、系统架构师、解决⽅案架构师、企业架构师等。⽽其它⼀些⼚商，可能⼜会划分：技术架构师、业务架构师、⽹络架构师、安全架构师、SOA架构师......
⼤家不必对这些概念太纠结。按照笔者的理解，国内⼤互联⽹公司⾥，架构师⼀般只会分2-3个⽅向：软件架构师和系统架构师（有些企业叫运维架构师），有些企业对于⽐较资深DBA⽽且懂整个系统架构的，还会分出所谓的“数据架构师”。⾄于具体Title，⼤可不必纠结，只需了解⾃⼰的兴趣，知晓了⼤致发展和定位，然后朝该⽅向努⼒即可。对于程序员⽽⾔，最基本的还是先写出⾼质量的代码，在实
战中逐步提升⾃⼰设计思维。
限于笔者⽔平和理解有限，⽂中全部⽂字和描述等全凭笔者记忆和理解写出，难免出现错误，请热⼼的读者及时批评和指正。
由于时间有限，部分图⽚笔者画的⽐较粗糙，也请读者谅解。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。