点击上方“掌上编程”，选择“置顶或者星标” php

优质文章第一时间送达！html

一. 什么是架构和架构本质前端

在软件行业，对于什么是架构，都有不少的争论，每一个人都有本身的理解。此君说的架构和彼君理解的架构未必是一回事。所以咱们在讨论架构以前，咱们先讨论架构的概念定义，概念是人认识这个世界的基础，并用来沟通的手段，若是对架构概念理解不同，那沟通起来天然不畅。

Linux有架构，MySQL有架构，JVM也有架构，使用Java开发、MySQL存储、跑在Linux上的业务系统也有架构，应该关注哪个？想要清楚以上问题须要梳理几个有关系又类似的概念：系统与子系统、模块与组建、框架与架构。

1.1. 系统与子系统nginx

系统：泛指由一群有关联的个体组成，根据某种规则运做，能完成个别元件不能独立完成的工做能力的群体。git
子系统：也是由一群关联的个体组成的系统，多半是在更大的系统中的一部分。github

1.2. 模块与组件web

都是系统的组成部分，从不一样角度拆分系统而已。模块是逻辑单元，组件是物理单元。面试
模块就是从逻辑上将系统分解，即分而治之，将复杂问题简单化。模块的粒度可大可小，能够是系统，几个子系统、某个服务，函数，类，方法、功能块等等。数据库
组件能够包括应用服务、数据库、网络、物理机、还能够包括MQ、容器、Nginx等技术组件。编程

1.3. 框架与架构

框架是组件实现的规范，例如：MVC、MVP、MVVM等，是提供基础功能的产品，例如开源框架：Ruby on Rails、Spring、Laravel、Django等，这是能够拿来直接使用或者在此基础上二次开发。

框架是规范，架构是结构。我在这从新定义架构：软件架构指软件系统的顶层结构。

架构是通过系统性地思考, 权衡利弊以后在现有资源约束下的最合理决策, 最终明确的系统骨架: 包括子系统, 模块, 组件. 以及他们之间协做关系, 约束规范, 指导原则.并由它来指导团队中的每一个人思想层面上的一致。涉及四方面：

系统性思考的合理决策：好比技术选型、解决方案等。
明确的系统骨架：明确系统有哪些部分组成。
系统协做关系：各个组成部分如何协做来实现业务请求。
约束规范和指导原则：保证系统有序，高效、稳定运行。

所以架构师具有能力：理解业务，全局把控，选择合适技术，解决关键问题、指导研发落地实施。架构的本质就是对系统进行有序化地重构以至符合当前业务的发展，并能够快速扩展。

那什么样的系统要考虑作架构设计技术不会无缘无故的出和自驱动发展起来，而架构的发展和需求是基于业务的驱动。架构设计彻底是为了业务：

需求相对复杂
非功能性需求在整个系统占据重要位置.
系统生命周期长,有扩展性需求.
系统基于组件或者集成的须要.
业务流程再造的须要.

二. 架构分层和分类

架构分类可细分为业务架构、应用架构、技术架构, 代码架构, 部署架构

业务架构是战略，应用架构是战术，技术架构是装备。其中应用架构承上启下，一方面承接业务架构的落地，另外一方面影响技术选型。

熟悉业务，造成业务架构，根据业务架构，作出相应的应用架构，最后技术架构落地实施。

如何针对当前需求，选择合适的应用架构，如何面向将来，保证架构平滑过渡，这个是软件开发者，特别是架构师，都须要深刻思考的问题。

2.1. 业务架构（俯视架构）

包括业务规划，业务模块、业务流程，对整个系统的业务进行拆分，对领域模型进行设计，把现实的业务转化成抽象对象。

没有最优的架构，只有最合适的架构，一切系统设计原则都要以解决业务问题为最终目标，脱离实际业务的技术情怀架构每每会给系统带入大坑，任何不基于业务作异想天开的架构都是耍流氓。

全部问题的前提要搞清楚咱们今天面临的业务量有多大，增加走势是什么样，并且解决高并发的过程，必定是一个按部就班逐步的过程。合理的架构可以提早预见业务发展1~2年为宜。这样能够付出较为合理的代价换来真正达到技术引领业务成长的效果。

看看京东业务架构（网上分享图）

2.2. 应用架构（剖面架构或逻辑架构图）

硬件到应用的抽象，包括抽象层和编程接口。应用架构和业务架构是相辅相成的关系。业务架构的每一部分都有应用架构。

应用架构：应用做为独立可部署的单元，为系统划分了明确的边界，深入影响系统功能组织、代码开发、部署和运维等各方面. 应用架构定义系统有哪些应用、以及应用之间如何分工和合做。

这里所谓应用就是各个逻辑模块或者子系统。应用架构图关键有2点：

① 职责划分：明确应用（各个逻辑模块或者子系统）边界

逻辑分层；子系统、模块定义；关键类。

②职责之间的协做：

接口协议：应用对外输出的接口。
协做关系：应用之间的调用关系。

应用分层有两种方式：

一种是水平分（横向），按照功能处理顺序划分应用，好比把系统分为web前端/中间服务/后台任务，这是面向业务深度的划分。
另外一种是垂直分（纵向），按照不一样的业务类型划分应用，好比进销存系统能够划分为三个独立的应用，这是面向业务广度的划分。

应用的合反映应用之间如何协做，共同完成复杂的业务case，主要体如今应用之间的通信机制和数据格式，通信机制能够是同步调用/异步消息/共享DB访问等，数据格式能够是文本/XML/JSON/二进制等。

应用的分偏向于业务，反映业务架构，应用的合偏向于技术，影响技术架构。分下降了业务复杂度，系统更有序，合增长了技术复杂度，系统更无序。

应用架构的本质是经过系统拆分，平衡业务和技术复杂性，保证系统形散神不散。

系统采用什么样的应用架构，受业务复杂性影响，包括企业发展阶段和业务特色；同时受技术复杂性影响，包括IT技术发展阶段和内部技术人员水平。业务复杂性（包括业务量大）必然带来技术复杂性，应用架构目标是解决业务复杂性的同时，避免技术太复杂，确保业务架构落地。

2.3. 数据架构

数据架构指导数据库的设计，不只仅要考虑开发中涉及到的数据库，实体模型，也要考虑物理架构中数据存储的设计。

2.4. 代码架构（也叫开发架构）

子系统代码架构主要为开发人员提供切实可行的指导，若是代码架构设计不足，就会形成影响全局的架构设计。好比公司内不一样的开发团队使用不一样的技术栈或者组件，结果公司总体架构设计就会失控。

代码架构主要定义：

① 代码单元：

配置设计；框架、类库。

②代码单元组织：

编码规范，编码的惯例；项目模块划分
顶层文件结构设计，好比mvc设计。
依赖关系

2.5. 技术架构

技术架构：肯定组成应用系统的实际运行组件（lvs，nginx，tomcat，php-fpm等），这些运行组件之间的关系，以及部署到硬件的策略。技术架构主要考虑系统的非功能性特征，对系统的高可用、高性能、扩展、安全、伸缩性、简洁等作系统级的把握。

系统架构的设计要求架构师具有软件和硬件的功能和性能的过硬知识，这也是架构设计工做中最为困难的工做。

2.6. 部署拓扑架构图（实际物理架构图）

拓扑架构，包括架构部署了几个节点，节点之间的关系，服务器的高可用，网路接口和协议等，决定了应用如何运行，运行的性能，可维护性，可扩展性，是全部架构的基础。这个图主要是运维工程师主要关注的对象。

物理架构主要考虑硬件选择和拓扑结构，软件到硬件的映射，软硬件的相互影响。

三. 架构级别

咱们使用金字塔的架构级别来讲明，上层级别包含下层：

系统级：即整个系统内各部分的关系以及如何治理：分层
应用级：即单个应用的总体架构，及其与系统内单个应用的关系等。
模块级：即应用内部的模块架构，如代码的模块化、数据和状态的管理等。
代码级：即从代码级别保障架构实施。

战略设计与战术设计：基于架构金字塔，咱们有了系统架构的战略设计与战术设计的完美结合：

战略设计：业务架构用于指导架构师如何进行系统架构设计。
战术设计：应用架构要根据业务架构来设计。
战术实施：应用架构肯定之后，就是技术选型。

四. 应用架构演进

业务架构是生产力，应用架构是生产关系，技术架构是生产工具。业务架构决定应用架构，应用架构须要适配业务架构，并随着业务架构不断进化，同时应用架构依托技术架构最终落地。

架构演进路程：单体应用->分布式应用服务化->微服务。

4.1. 单体应用

企业一开始业务比较简单，只应用某个简单场景，应用服务支持数据增删改查和简单的逻辑便可，单体应用能够知足要求。

典型的三级架构，前端（Web/手机端）+中间业务逻辑层+数据库层。这是一种典型的Java Spring MVC或者Python Django框架的应用。其架构图以下所示：

针对单体应用，非功能性需求的作法：

性能需求：使用缓存改善性能
并发需求：使用集群改善并发
读写分离：数据库地读写分离
使用反向代理和cdn加速；使用分布式文件和分布式数据库

单体架构的应用比较容易部署、测试，在项目的初期，单体应用能够很好地运行。然而，随着需求的不断增长，愈来愈多的人加入开发团队，代码库也在飞速地膨胀。慢慢地，单体应用变得愈来愈臃肿，可维护性、灵活性逐渐下降，维护成本愈来愈高。下面是单体架构应用的一些缺点：

复杂性高：以一个百万行级别的单体应用为例，整个项目包含的模块很是多、模块的边界模糊、依赖关系不清晰、代码质量良莠不齐、混乱地堆砌在一块儿。可想而知整个项目很是复杂。每次修改代码都心惊胆战，甚至添加一个简单的功能，或者修改一个Bug都会带来隐含的缺陷。
技术债务：随着时间推移、需求变动和人员更迭，会逐渐造成应用程序的技术债务，而且越积越多。“ 不坏不修”，这在软件开发中很是常见，在单体应用中这种思想更甚。已使用的系统设计或代码难以被修改，由于应用程序中的其余模块可能会以意料以外的方式使用它。
部署频率低：随着代码的增多，构建和部署的时间也会增长。而在单体应用中，每次功能的变动或缺陷的修复都会致使须要从新部署整个应用。全量部署的方式耗时长、影响范围大、风险高，这使得单体应用项目上线部署的频率较低。而部署频率低又致使两次发布之间会有大量的功能变动和缺陷修复，出错率比较高。
可靠性差：某个应用Bug，例如死循环、内存溢出等，可能会致使整个应用的崩溃。
扩展能力受限：单体应用只能做为一个总体进行扩展，没法根据业务模块的须要进行伸缩。例如，应用中有的模块是计算密集型的，它须要强劲的CPU；有的模块则是IO密集型的，须要更大的内存。因为这些模块部署在一块儿，不得不在硬件的选择上作出妥协。
阻碍技术创新：单体应用每每使用统一的技术平台或方案解决全部的问题，团队中的每一个成员都必须使用相同的开发语言和框架，要想引入新框架或新技术平台会很是困难。

4.2. 分布式

随着业务深刻，业务要求的产品功能愈来愈多，每一个业务模块逻辑也都变得更加复杂，业务的深度和广度都增长，使得单体应用变得愈来愈臃肿，可维护性、灵活性逐渐下降，增长新功能开发周期愈来愈长，维护成本愈来愈高。

这时须要对系统按照业务功能模块拆分，将各个模块服务化，变成一个分布式系统。业务模块分别部署在不一样的服务器上，各个业务模块之间经过接口进行数据交互。

该架构相对于单体架构来讲，这种架构提供了负载均衡的能力，大大提升了系统负载能力，解决了网站高并发的需求。另外还有如下特色：

下降了耦合度：把模块拆分，使用接口通讯,下降模块之间的耦合度。
责任清晰：把项目拆分红若干个子项目，不一样的团队负责不一样的子项目。
扩展方便：增长功能时只须要再增长一个子项目，调用其余系统的接口就能够。
部署方便：能够灵活的进行分布式部署。
提升代码的复用性：好比Service层，若是不采用分布式rest服务方式架构就会在手机Wap商城，微信商城，PC，Android，iOS每一个端都要写一个Service层逻辑，开发量大，难以维护一块儿升级，这时候就能够采用分布式rest服务方式，公用一个service层。
缺点：系统之间的交互要使用远程通讯，接口开发增大工做量，可是利大于弊。

4.3. 微服务

紧接着业务模式愈来愈复杂，订单、商品、库存、价格等各个模块都很深刻，好比价格区分会员等级，访问渠道（app仍是PC），销售方式（团购仍是普通）等，还有大量的价格促销，这些规则很复杂，容易相互冲突，须要把分散到各个业务的价格逻辑进行统一管理，以基础价格服务的方式透明地提供给上层应用，变成一个微内核的服务化架构，即微服务。

微服务的特色：

易于开发和维护：一个微服务只会关注一个特定的业务功能，因此它业务清晰、代码量较少。开发和维护单个微服务相对简单。而整个应用是由若干个微服务构建而成的，因此整个应用也会被维持在一个可控状态。
单个微服务启动较快：单个微服务代码量较少，因此启动会比较快。
局部修改容易部署：单体应用只要有修改，就得从新部署整个应用，微服务解决了这样的问题。通常来讲，对某个微服务进行修改，只须要从新部署这个服务便可。
技术栈不受限：在微服务架构中，能够结合项目业务及团队的特色，合理地选择技术栈。例如某些服务可以使用关系型数据库MySQL；某些微服务有图形计算的需求，可使用Neo4j；甚至可根据须要，部分微服务使用Java开发，部分微服务使用Node.js开发。

微服务虽然有不少吸引人的地方，但它并非免费的午饭，使用它是有代价的。使用微服务架构面临的挑战。

运维要求较高：更多的服务意味着更多的运维投入。在单体架构中，只须要保证一个应用的正常运行。而在微服务中，须要保证几十甚至几百个服务服务的正常运行与协做，这给运维带来了很大的挑战。
分布式固有的复杂性：使用微服务构建的是分布式系统。对于一个分布式系统，系统容错、网络延迟、分布式事务等都会带来巨大的挑战。
接口调整成本高：微服务之间经过接口进行通讯。若是修改某一个微服务的API，可能全部使用了该接口的微服务都须要作调整。
重复劳动：不少服务可能都会使用到相同的功能，而这个功能并无达到分解为一个微服务的程度，这个时候，可能各个服务都会开发这一功能，从而致使代码重复。尽管可使用共享库来解决这个问题（例如能够将这个功能封装成公共组件，须要该功能的微服务引用该组件），但共享库在多语言环境下就不必定行得通了。

五. 衡量架构的合理性

架构为业务服务，没有最优的架构，只有最合适的架构，架构始终以高效，稳定，安全为目标来衡量其合理性。合理的架构设计：

5.1. 业务需求角度

能解决当下业务需求和问题
高效完成业务需求: 能以优雅且可复用的方式解决当下全部业务问题
前瞻性设计: 能在将来一段时间都能以第2种方式知足业务，从而不会每次当业务进行演变时，致使架构翻天覆地的变化。

5.2. 非业务需求角度

①稳定性指标：

高可用：要尽量的提升软件的可用性，我想每一个操做人都不肯意看到本身的工做没法正常进行。黑盒白盒测试、单元测试、自动化测试、故障注入测试、提升测试覆盖率等方式来一步一步推动。

②高效指标：

文档化：无论是总体仍是部分的整个生命周期内都必须作好文档化，变更的来源包括但不限于BUG，需求。
可扩展：软件的设计秉承着低耦合的理念去作，注意在合理的地方抽象。方便功能更改、新增和运用技术的迭代，而且支持在适时对架构作出重构。
高复用：为了不重复劳动，为了下降成本，咱们但愿可以重用以前的代码、以前的设计。这点对于架构环境的依赖是最大的。

③安全指标

安全：组织的运做过程当中产生的数据都是具备商业价值的，保证数据的安全也是刻不容缓的一部分。以避免出现XX门之类丑闻。加密、https等为广泛手段

六. 常见架构误区

遗漏关键性约束与非功能需求
为虚无的将来埋单而过分设计
过早作出关键性决策
客户说啥就是啥成为传话筒
埋头干活儿缺少前瞻性
架构设计还要考虑系统可测性
架构设计不要企图一步到位

常见误区

误区1——架构专门由架构师来作，业务开发人员无需关注：架构的再好，最终仍是须要代码来落地，而且组织越大这个落地的难度越大。不仅仅是系统架构，每一个解决方案每一个项目也由本身的架构，如分层、设计模式等。若是每一块砖瓦不够坚固，那么整个系统仍是会由崩塌的风险。所谓“千里之堤，溃于蚁穴”。
误区2——架构师肯定了架构蓝图以后任务就结束了：架构不是“空中楼阁”，最终仍是要落地的，可是架构师彻底不去深刻到第一线怎么知道“地”在哪？怎么才能落的稳妥当当。
误区3——不作出完美的架构设计不开工：世上没有最好架构，只有最合适的架构,不要企图一步到位。咱们须要的不是一会儿造出一辆汽车，而是从单轮车→自行车→摩托车，最后再到汽车。想象一下2年后才能造出的产品，当初市场还存在吗？
误区4—— 为虚无的将来埋单而过分设计：在创业公司初期，业务场景和需求边界很难把握，产品须要快速迭代和变现，需求频繁更新，这个时候须要的是快速实现。不要过多考虑将来的扩展，说不定功能作完，效果很差就无用了。若是业务模式和应用场景边界都已经比较清晰，是应该适当的考虑将来的扩展性设计。
误区5——一味追随大公司的解决方案：因为大公司巨大成功的光环效应，再加上从大公司挖来的技术高手的影响，网站在讨论架构决策时，最有说服力的一句话就成了“淘宝就是这么搞的”或者“腾讯就是这么搞的”。大公司的经验和成功模式当然重要，值得学习借鉴，但若是所以而变得盲从，就失去了坚持自个人勇气，在架构演化的道路上早晚会迷路。