一文搞懂架构（业务架构、数据架构、技术架构...）
在软件行业，对于什么是架构，都有很多的争论，每个人都有自己的理解。在不同的书籍上, 不同的作者, 对于架构的定义也不统一, 角度不同, 定义不同。此君说的架构和彼君理解的架构未必是一回事。因此我们在讨论架构之前，我们先讨论架构的概念定义, 因为概念是人认识这个世界的基础和用来沟通的手段，如果对架构概念理解不一样，那沟通起来自然不顺畅，本文根据相关资料进行总结。
一、架构是什么
Linux 有架构，MySQL 有架构，JVM 也有架构，使用 Java 开发、MySQL 存储、跑在 Linux 上的业务系统也有架构，应该关注哪一个？想要清楚以上问题需要梳理几个有关系又相似的概念：系统与子系统、模块与组建、框架与架构。
1、系统与子系统
系统：泛指由一群有关联的个体组成，根据某种规则运作，能完成个别元件不能独立完成的工作能力的群体，关键词：
关联：系统是由一群有关联的个体组成的，没有关联的个体堆在一起不能成为一个系统。例如，把一个发动机和一台 PC 放在一起不能称之为一个系统，把发动机、底盘、轮胎、车架组合起来才能成为一台汽车。
规则：系统内的个体需要按照指定的规则运作，而不是单个个个体各自为政。规则规定了系统内个体分工和协作的方式。例如，汽车发动机负责产生动力，然后通过变速器和传动轴, 将动力输出到车轮上，从而驱动汽车前进。
能力：系统能力与个体能力有本质的差别，系统能力不是是个体能力之和，而是产生了新的能力。例如，汽车能够载重前进，而发动机、变速器、传动轴、车轮本身都不具备这样的能力。
子系统：也是由一群关联的个体组成的系统，多半是在更大的系统中的一部分。
2、模块与组件
都是系统的组成部分，从不同角度拆分系统而已。模块是逻辑单元，组件是物理单元。
模块就是从逻辑上将系统分解， 即分而治之， 将复杂问题简单化。模块的粒度可大可小， 可以是系统，几个子系统、某个服务，函数， 类，方法、 功能块等等。划分模块的主要目的是职责分离。
组件可以包括应用服务、数据库、网络、物理机、还可以包括 MQ、容器、Nginx 等技术组件。划分组件的主要目的的是单元复用。"组件"的英文单词 Component，对应中文的"零件"一词，"零件"更容易理解一些。"零件"是一个物理的概念, 并且具备"独立且可替换"的特点。现在越来越多的 UI 设计使用组件化化和模块化。
3、框架与架构
框架通常指的是为了实现某个业界标准或完成特定基本任务的软件组件规范, 也指为了实现某个软件组件规范时，提供规范所要求之基础功能的软件产品。
框架是组件实现的规范，例如：MVC、MVP、MVVM 等，是提供基础功能的产品，例如开源框架：Ruby on Rails、Spring、Laravel、Django 等，这是可以拿来直接使用或者在此基础上二次开发。再例如,SpringMVC 是 MVC 的开发框架，除了满足 MVC 的规范,Spring 提供了很多基础功能来帮助我们实现功能，包括注解(@Controller 等)、Spring Security、SpringJPA 等很多基础功能。
框架是规范，架构是结构：框架和架构的区别还是比较明显的，框架关注的是"规范", 架构关注的是"结构"：
-
框架的英文是 Framework ，例如，SpringMVC 是"Web MVC Framework"；
-
架构的英文是 Architecture，例如，Linux 操作系统的架构。
在 TOGAF9 是这么定义：一个系统基本的构件(子系统, 模块, 组件)，体现在它的各个构件、构件间的相互关系、构件与环境间的关系，以及对系统设计和演进进行治理的原则中。两种含义：
-
一个系统的形式化描述，或指导系统实现的构件级的详细计划；
-
一组构件的结构、构件间的相互关系、以及对这些构件的设计和随时间演进的过程进行治理的一些原则和指导策略。
架构从字面意思上，是源于古代的建筑术语。把架构拆分成两个字“架”和“构”。“架”就是“加”和“木”的结合，把木头加起来、连接起来就是架。“构”就是结构的意思。所以，“架构”就是把“木“按照一定的结构连接起来。
对应到软件架构，“木”代表构件(要素)，“结构”代表架构的产物：
木就是系统中的要素，我们将他们称之为架构构件(要素)。架构要素可以是子系统、模块、应用服务、组件。
结构，是架构的产物。不同的软件系统会有不同的结构，这些结构是为解决不同场景而设计的。连接，通过定义架构元素之间的接口和交互关系、集成机制，实现架构元素之间的连接。连接可以是分布式调用、进程间调用、组件之间的交互关系等。
总结一下架构的组成 = 要素 + 结构 + 连接，将系统要素按照特定结构进行连接交互。我在这重新定义架构(见仁见智，自己独立思考)：软件架构指软件系统顶层结构设计。架构是经过系统性地思考, 权衡利弊之后在现有资源约束下的最合理决策, 最终明确的系统骨架: 包括子系统, 模块, 组件. 以及他们之间协作关系, 约束规范, 指导原则. 并由它来指导系统各方面的设计和指导团队中的每个人思想层面上的一致。
涉及四方面：
1、系统性思考的合理决策：比如技术选型、解决实施方案(包括执行目标计划)、成本评估、性价比评估等等。
2、结构：明确的系统骨架（结构）：明确系统有哪些构件组成。
3、连接：系统协作关系：各个组成部分如何协作来实现业务请求。
4、规范：约束规范和指导原则：保证系统有序，高效、稳定运行，包括规范、原则、流程等内容。
二、架构设计目的
如果没有架构设计，说明你的系统不够复杂。随着业务的增长，系统由单体应用渐进演化为分布式和微服务化。系统整体的复杂性越来越高，技术团队可能从一个团队变成多个专业化团队。假如没有架构设计，系统定会是一个无序失控的状态，带来的问题：
1、应用服务的边界不是很清晰：到底该怎么拆分没有一个明确的原则，研发人员为了所谓微服务化而拆分，而不是从当前业务考虑。导致系统无序的状态，开发效率低。
我们系统出现过类似的情况：一个简单项目拆分成 8 个子服务，问他为什么这么拆分，说微服务化是为了应对以后扩展方便。结果这个项目从 2017 年到现在都没有再修改过，接手人宁愿新开发一个项目也不愿重构。
2、应用服务层次不清晰，系统耦合严重：导致服务依赖出现网状依赖结构，牵一发动全身，后续修改和扩展困难。
3、系统应用服务跟踪问题：由于微服务化后，系统逻辑复杂，服务出现问题后，你很难快速的定位问题和修复。这是我们踩过不少坑，我们使用 dubbo 服务化，系统一旦出现问题，一推人手忙脚乱。
4、系统服务监控问题：由于研发人员基本没有服务监控意识，都是出现问题后再想办法如何添加服务监控接口。
5、技术体系失控问题：不同的开发团队使用不同的技术栈或者组件，造成公司内部的技术架构失控。甚至研发人员为追求时髦新潮技术，拿应用项目来试验新技术。
架构设计的目的是为了解决系统复杂性带来的问题，其本质就是对系统进行有序化地重构以致符合当前业务的发展，并可以快速扩展。从上面架构的定义，也知道架构设计的作用涉及四方面：
1、系统性思考的合理决策。
2、明确的系统骨架。
3、系统协作关系。
4、约束规范和指导原则。
架构的本质是管理和解决系统的复杂性，提高效率。管理复杂性：对系统进行有序化重构，不断减少系统的“熵”，使系统不断进化，改善软件质量为目的的内在结构性变化；提高效率：对系统进行有序化重构，以符合当前业务的发展，并可以快速扩展。
无论是何种变化，架构师通过理解业务，全局把控，权衡业务需求和技术实现，选择合适技术，解决关键问题、指导研发落地实施，促进业务发展，提高效率。那什么样的系统要考虑做架构设计? 技术不会平白无故的出和自驱动发展起来，而架构的发展和需求是基于业务的驱动：
-
需求相对复杂
-
非功能性需求在整个系统占据重要位置
-
系统生命周期长,有扩展性需求
-
系统基于组件或者集成的需要
-
业务流程再造的需要
三、架构分类
在 EA 架构领域，有两种常见架构方法 RUP 和 TOGAF，这两个框架也是我们常常了解架构分类的两个维度。从我个人的角度觉得 TOGAF 的分类方式更加广泛使用。
RUP4+1 架构视图
1995 年，Philippe Kruchten 在《IEEE Software》上发表了题为《The 4+1 View Model of Architecture》的论文，引起了业界的极大关注，并最终被 RUP 采纳。即 RUP4+1 架构方法。该方法主要采用用例驱动，在软件生命周期的各个阶段对软件进行建模,从不同视角对系统进行解读，从而形成统一软件过程架构描述。该方法的不同架构视图承载不同的架构设计决策，支持不同的目标和用途。
逻辑视图：用于描述系统软件功能拆解后的组件关系,组件约束和边界,反映系统整体组成与系统如何构建的过程。关注功能和逻辑层。
开发视图：描述系统的模块划分和组成,以及细化到内部包的组成设计,服务于开发人员,反映系统开发实施过程。
物理视图：描述软件如何映射到硬件，反映系统在分布方面的设计，系统的组件是如何部署到一组可计算机器节点上,用于指导软件系统的部署实施过程。
处理流程视图：用于描述系统软件组件之间的通信时序,数据的输入输出,反映系统的功能流程与数据流程,通常由时序图和流程图表示。关注进程、线程、对象等运行时概念以及相关的并发、同步、通信等问题。
运用 4+1 视图方法：针对不同需求进行架构设计。
TOGAF9 架构分类
TOGAF9 来对架构分类：
由于不同架构方法论，定义的架构分类也不同，RUP4+1 架构方法主要是以架构生命周期为视角进行描述，而 TOGAF9 按架构涉及内容维度来描述。因此我结合两者细分为业务架构、应用架构、数据架构、技术架构, 代码架构, 部署架构。
TOGAF 即 The Open Group Architecture Framework （开放组体系结构框架），是由致力于技术标准制定和推广的非盈利组织 The Open Group 制定的用于开发企业架构（Enterprise Architecture）的一套方法和工具。
业务架构是战略，应用架构是战术，技术架构是装备。其中应用架构承上启下，一方面承接业务架构的落地，另一方面影响技术选型。熟悉业务，形成业务架构，根据业务架构，做出相应的应用架构，最后技术架构落地实施。
1、业务架构（俯视架构）
包括业务规划，业务模块、业务流程，对整个系统的业务进行拆分，对领域模型进行设计，把现实的业务转化成抽象对象。业务架构是企业治理结构、商业能力与价值流的正式蓝图。业务架构明确定义企业的治理结构、业务能力、业务流程、业务数据。其中，业务能力定义企业做什么，业务流程定义企业怎么做。业务架构就是对企业的业务流程，进行根本性的再思考和在思考的彻底性再设计，从而获得成本、质量、速度等方面业绩的巨大的改善或提高。总结业务架构包含：
1、战略；2、企业业务流程(价值链)当前能力；3、未来能力；商业能力，IT 能力。
没有最优的架构，只有最合适的架构，一切系统设计原则都要以解决业务问题为最终目标，脱离实际业务的技术情怀架构往往会给系统带入大坑，任何不基于业务做异想天开的架构都是耍流氓。
所有问题的前提要搞清楚我们今天面临的业务量有多大，增长走势是什么样，而且解决高并发的过程，一定是一个循序渐进逐步的过程。合理的架构能够提前预见业务发展 1~2 年为宜。这样可以付出较为合理的代价换来真正达到技术引领业务成长的效果。
看看京东业务架构（网上分享图）：
2、产品架构
基础的产品框架脱胎于业务流程，但相比业务流程，更加注重产品功能的枚举、功能模块之间的分界。
当我们打开一个系统，我们会看到一个精美的页面，一些丰富的信息、导航。这些东西会引导我们去使用这个系统。这些东西就是这个系统的组成部分，就是这个系统的功能模块。产品架构，就是将这些不同用途的功能模块围绕特定的业务目标进行分类整合。
功能模块是用户能够完成一个操作的最小粒度的完整功能。比如一个展示可购买商品的列表页、一个修改用户密码的功能。在功能模块设计过程中，需要确保用户能通过一个功能模块完整的完成一项工作，而不是半个工作。
产品架构中，功能模块是根据其相互之间的关系来组织的。一个产品中不同的功能模块之间的关系分直接关系和间接关系。只有直接关系的功能模块才会被组织到一起，形成一个子系统。那些存在间接关系的模块，会在不同的层级通过直接关系的模块产生联系。
当具有直接关系的功能模块组合成一个子系统后，解决相同问题域的子系统就形成一个功能层级。功能层级按照接近用户实操的距离程度进行从上到下，或者从左至右的划分，这就形成了产品架构的分层。
3、应用架构（剖面架构，也叫逻辑架构图）：
硬件到应用的抽象，包括抽象层和编程接口。应用架构和业务架构是相辅相成的关系。业务架构的每一部分都有应用架构。
应用架构是要说明产品架构分哪些应用系统，应用系统间是如何集成的。这就是应用架构和应用集成架构。应用架构在产品架构的基础上考虑两个事情：第一、考虑的是子系统间的关系。第二、考虑将可复用的组件或模块进行下沉，沉淀到平台层，为业务组件提供统一的支撑。
类似：
应用架构：应用作为独立可部署的单元，为系统划分了明确的边界，深刻影响系统功能组织、代码开发、部署和运维等各方面. 应用架构定义系统有哪些应用、以及应用之间如何分工和合作。这里所谓应用就是各个逻辑模块或者子系统。
应用架构图关键有 2 点：
1、职责划分: 明确应用（各个逻辑模块或者子系统）边界
-
逻辑分层
-
子系统、模块定义。
-
关键类。
2、职责之间的协作：
-
接口协议：应用对外输出的接口。
-
协作关系：应用之间的调用关系。
应用分层有两种方式：
一种是水平分（横向），按照功能处理顺序划分应用，比如把系统分为 web 前端/中间服务/后台任务，这是面向业务深度的划分。
另一种是垂直分（纵向），按照不同的业务类型划分应用，比如进销存系统可以划分为三个独立的应用，这是面向业务广度的划分。
应用的合反映应用之间如何协作，共同完成复杂的业务 case，主要体现在应用之间的通讯机制和数据格式，通讯机制可以是同步调用/异步消息/共享 DB 访问等，数据格式可以是文本/XML/JSON/二进制等。
应用的分偏向于业务，反映业务架构，应用的合偏向于技术，影响技术架构。分降低了业务复杂度，系统更有序，合增加了技术复杂度，系统更无序。应用架构的本质是通过系统拆分，平衡业务和技术复杂性，保证系统形散神不散。
系统采用什么样的应用架构，受业务复杂性影响，包括企业发展阶段和业务特点；同时受技术复杂性影响，包括 IT 技术发展阶段和内部技术人员水平。业务复杂性（包括业务量大）必然带来技术复杂性，应用架构目标是解决业务复杂性的同时，避免技术太复杂，确保业务架构落地。
4、数据架构
数据架构指导数据库的设计. 不仅仅要考虑开发中涉及到的数据库，实体模型，也要考虑物理架构中数据存储的设计。
5、代码架构（也叫开发架构）：
子系统代码架构主要为开发人员提供切实可行的指导，如果代码架构设计不足，就会造成影响全局的架构设计。比如公司内不同的开发团队使用不同的技术栈或者组件，结果公司整体架构设计就会失控。
代码架构主要定义内容：
一、代码单元: 1、配置设计 2、框架、类库。
二、代码单元组织：1、编码规范，编码的惯例 2、项目模块划分 3、顶层文件结构设计，比如 mvc 设计 4、依赖关系
最好的样本是参考现有《阿里巴巴 Java 开发手册》。
6、技术架构
应用架构本身只关心需要哪些应用系统，哪些平台来满足业务目标的需求，而不会关心在整个构建过程中你需要使用哪些技术。技术架构是应接应用架构的技术需求，并根据识别的技术需求，进行技术选型，把各个关键技术和技术之间的关系描述清楚。
技术架构：确定组成应用系统的实际运行组件（lvs，nginx，tomcat，php-fpm 等），这些运行组件之间的关系，以及部署到硬件的策略。技术架构还要考虑系统的非功能性特征，对系统的高可用、高性能、扩展、安全、伸缩性、简洁等做系统级的把握。系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，这也是架构设计工作中最为困难的工作。
7、部署拓扑架构图（实际物理架构图）：
拓扑架构，包括架构部署了几个节点，节点之间的关系，服务器的高可用，网路接口和协议等，决定了应用如何运行，运行的性能，可维护性，可扩展性，是所有架构的基础。这个图主要是运维工程师主要关注的对象。
物理架构主要考虑硬件选择和拓扑结构，软件到硬件的映射，软硬件的相互影响。
四、架构级别
我们使用金字塔的架构级别来说明，上层级别包含下层：系统级、应用级、模块级、代码级。
系统级，即整个系统内各部分的关系以及如何治理：分层。
应用级，即单个应用的整体架构，及其与系统内单个应用的关系等。
模块级，即应用内部的模块架构，如代码的模块化、数据和状态的管理等。
代码级，即从代码级别保障架构实施。
战略设计与战术设计
基于架构金字塔，我们有了系统架构的战略设计与战术设计的完美结合：
战略设计：业务架构用于指导架构师如何进行系统架构设计。
战术设计：应用架构要根据业务架构来设计。
战术实施：应用架构确定以后，就是技术选型。
五、应用架构演进
业务架构是生产力，应用架构是生产关系，技术架构是生产工具。业务架构决定应用架构，应用架构需要适配业务架构，并随着业务架构不断进化，同时应用架构依托技术架构最终落地。
架构演进路程：单体应用->分布式应用服务化-> 微服务。
1、单体应用
企业一开始业务比较简单，只应用某个简单场景，应用服务支持数据增删改查和简单的逻辑即可，单体应用可以满足要求。
典型的三级架构，前端（Web/手机端）+中间业务逻辑层+数据库层。这是一种典型的 Java Spring MVC 或者 Python Django 框架的应用。其架构图如下所示：
针对单体应用，非功能性需求的做法：
1、性能需求：使用缓存改善性能
2、并发需求：使用集群改善并发
3、读写分离：数据库地读写分离
4、使用反向代理和 cdn 加速
5、使用分布式文件和分布式数据库
单体架构的应用比较容易部署、测试， 在项目的初期，单体应用可以很好地运行。然而，随着需求的不断增加， 越来越多的人加入开发团队，代码库也在飞速地膨胀。慢慢地，单体应用变得越来越臃肿，可维护性、灵活性逐渐降低，维护成本越来越高，下面是单体架构应用的一些缺点。
复杂性高：
以一个百万行级别的单体应用为例，整个项目包含的模块非常多、模块的边界模糊、 依赖关系不清晰、 代码质量参差不齐、 混乱地堆砌在一起。可想而知整个项目非常复杂。每次修改代码都心惊胆战， 甚至添加一个简单的功能， 或者修改一个 Bug 都会带来隐含的缺陷。
技术债务：随着时间推移、需求变更和人员更迭，会逐渐形成应用程序的技术债务， 并且越积 越多。“ 不坏不修”， 这在软件开发中非常常见， 在单体应用中这种思想更甚。已使用的系统设计或代码难以被修改，因为应用程序中的其他模块可能会以意料之外的方式使用它。
部署频率低：随着代码的增多，构建和部署的时间也会增加。而在单体应用中， 每次功能的变更或缺陷的修复都会导致需要重新部署整个应用。全量部署的方式耗时长、 影响范围大、 风险高， 这使得单体应用项目上线部署的频率较低。而部署频率低又导致两次发布之间会有大量的功能变更和缺陷修复，出错率比较高。
可靠性差：某个应用 Bug，例如死循环、内存溢出等， 可能会导致整个应用的崩溃。
扩展能力受限：单体应用只能作为一个整体进行扩展，无法根据业务模块的需要进行伸缩。例如，应用中有的模块是计算密集型的，它需要强劲的 CPU；有的模块则是 IO 密集型的，需要更大的内存。由于这些模块部署在一起，不得不在硬件的选择上做出妥协。
阻碍技术创新：单体应用往往使用统一的技术平台或方案解决所有的问题， 团队中的每个成员 都必须使用相同的开发语言和框架，要想引入新框架或新技术平台会非常困难。
2、分布式
随着业务深入，业务要求的产品功能越来越多，每个业务模块逻辑也都变得更加复杂，业务的深度和广度都增加，使得单体应用变得越来越臃肿，可维护性、灵活性逐渐降低，增加新功能开发周期越来越长，维护成本越来越高。
这时需要对系统按照业务功能模块拆分，将各个模块服务化，变成一个分布式系统。业务模块分别部署在不同的服务器上，各个业务模块之间通过接口进行数据交互。
该架构相对于单体架构来说，这种架构提供了负载均衡的能力，大大提高了系统负载能力，解决了网站高并发的需求。另外还有以下特点：
降低了耦合度：把模块拆分，使用接口通信,降低模块之间的耦合度。
责任清晰：把项目拆分成若干个子项目，不同的团队负责不同的子项目。
扩展方便：增加功能时只需要再增加一个子项目，调用其他系统的接口就可以。
部署方便：可以灵活的进行分布式部署。
提高代码的复用性：比如 Service 层，如果不采用分布式 rest 服务方式架构就会在手机 Wap 商城，微信商城，PC，Android，iOS 每个端都要写一个 Service 层逻辑，开发量大，难以维护一起升级，这时候就可以采用分布式 rest 服务方式，公用一个 service 层。
缺点：系统之间的交互要使用远程通信，接口开发增大工作量，但是利大于弊。
3、微服务
紧接着业务模式越来越复杂，订单、商品、库存、价格等各个模块都很深入，比如价格区分会员等级，访问渠道（app 还是 PC），销售方式（团购还是普通）等，还有大量的价格促销，这些规则很复杂，容易相互冲突，需要把分散到各个业务的价格逻辑进行统一管理，以基础价格服务的方式透明地提供给上层应用，变成一个微内核的服务化架构，即微服务。
微服务的特点：
易于开发和维护：一个微服务只会关注一个特定的业务功能，所以它业务清晰、代码量较少。开发和维护单个微服务相对简单。而整个应用是由若干个微服务构建而成的，所以整个应用也会被维持在一个可控状态。
单个微服务启动较快：单个微服务代码量较少， 所以启动会比较快。
局部修改容易部署：单体应用只要有修改，就得重新部署整个应用，微服务解决了这样的问题。一般来说，对某个微服务进行修改，只需要重新部署这个服务即可。
技术栈不受限：在微服务架构中，可以结合项目业务及团队的特点，合理地选择技术栈。例如某些服务可使用关系型数据库 MySQL；某些微服务有图形计算的需求，可以使用 Neo4j；甚至可根据需要，部分微服务使用 Java 开发，部分微服务使用 Node.js 开发。
微服务虽然有很多吸引人的地方，但它并不是免费的午餐，使用它是有代价的。使用微服务架构面临的挑战。
运维要求较高：更多的服务意味着更多的运维投入。在单体架构中，只需要保证一个应用的正常运行。而在微服务中，需要保证几十甚至几百个服务服务的正常运行与协作，这给运维带来了很大的挑战。
分布式固有的复杂性：使用微服务构建的是分布式系统。对于一个分布式系统，系统容错、网络延迟、分布式事务等都会带来巨大的挑战。
接口调整成本高：微服务之间通过接口进行通信。如果修改某一个微服务的 API，可能所有使用了该接口的微服务都需要做调整。
重复劳动：很多服务可能都会使用到相同的功能，而这个功能并没有达到分解为一个微服务的程度，这个时候，可能各个服务都会开发这一功能，从而导致代码重复。尽管可以使用共享库来解决这个问题（例如可以将这个功能封装成公共组件，需要该功能的微服务引用该组件），但共享库在多语言环境下就不一定行得通了。
六、衡量架构的合理性
架构为业务服务，没有最优的架构，只有最合适的架构， 架构始终以高效，稳定，安全为目标来衡量其合理性。
合理的架构设计：
1、业务需求角度
1、能解决当下业务需求和问题
2、高效完成业务需求: 能以优雅且可复用的方式解决当下所有业务问题
3、前瞻性设计: 能在未来一段时间都能以第 2 种方式满足业务，从而不会每次当业务进行演变时，导致架构翻天覆地的变化。
2、非业务需求角度
（一）、稳定性。指标：
1、高可用：要尽可能的提高软件的可用性，我想每个操作人都不愿意看到自己的工作无法正常进行。黑盒白盒测试、单元测试、自动化测试、故障注入测试、提高测试覆盖率等方式来一步一步推进。
（二）、高效指标：
1、文档化：不管是整体还是部分的整个生命周期内都必须做好文档化，变动的来源包括但不限于 BUG，需求。
2、可扩展：软件的设计秉承着低耦合的理念去做，注意在合理的地方抽象。方便功能更改、新增和运用技术的迭代，并且支持在适时对架构做出重构。
3、高复用：为了避免重复劳动，为了降低成本，我们希望能够重用之前的代码、之前的设计。这点对于架构环境的依赖是最大的。
（三）、安全指标
安全：组织的运作过程中产生的数据都是具有商业价值的，保证数据的安全也是刻不容缓的一部分。以免出现 XX 门之类丑闻。加密、https 等为普遍手段。
七、常见架构误区
● 开高走落不到实处
● 遗漏关键性约束与非功能需求
● 为虚无的未来埋单而过度设计
● 过早做出关键性决策
● 客户说啥就是啥成为传话筒
● 埋头干活儿缺乏前瞻性
● 架构设计还要考虑系统可测性
● 架构设计不要企图一步到位
误区 1——架构专门由架构师来做，业务开发人员无需关注
架构的再好，最终还是需要代码来落地，并且组织越大这个落地的难度越大。不单单是系统架构，每个解决方案每个项目也由自己的架构，如分层、设计模式等。如果每一块砖瓦不够坚固，那么整个系统还是会由崩塌的风险。所谓“千里之堤，溃于蚁穴”。
误区 2——架构师确定了架构蓝图之后任务就结束了
架构不是“空中楼阁”，最终还是要落地的，但是架构师完全不去深入到第一线怎么知道“地”在哪？怎么才能落的稳稳当当。
误区 3——不做出完美的架构设计不开工
世上没有最好架构，只有最合适的架构,不要企图一步到位。我们需要的不是一下子造出一辆汽车，而是从单轮车 --> 自行车 --> 摩托车，最后再到汽车。想象一下 2 年后才能造出的产品，当初市场还存在吗？
误区 4—— 为虚无的未来埋单而过度设计
在创业公司初期，业务场景和需求边界很难把握，产品需要快速迭代和变现，需求频繁更新，这个时候需要的是快速实现。不要过多考虑未来的扩展，说不定功能做完，效果不好就无用了。如果业务模式和应用场景边界都已经比较清晰，是应该适当的考虑未来的扩展性设计。
误区 5——一味追随大公司的解决方案
由于大公司巨大成功的光环效应，再加上从大公司挖来的技术高手的影响，网站在讨论架构决策时，最有说服力的一句话就成了“淘宝就是这么搞的”或者“腾讯 就是这么搞的”。
大公司的经验和成功模式固然重要，值得学习借鉴，但如果因此而变得盲从，就失去了坚持自我的勇气，在架构演化的道路上迟早会迷路。
误区 6——为了技术而技术
技术是为业务而存在的，除此毫无意义。在技术选型和架构设计中，脱离网站业务发展的实际，一味追求时髦的新技术，可能会将技术发展引入崎岖小道，架构之路越走越难。考虑实现成本、时间、人员等各方面都要综合考虑，理想与现实需要折中。
八、架构书籍推荐
1、《大型网站技术架构：核心原理与案例分析》
这是比较早，比较系统介绍大型网站技术架构的书，通俗易懂又充满智慧，即便你之前完全没接触过网站开发，通读前几章，也能快速获取到常见的网站技术架构及其应用场景。非常赞。
2、《亿级流量网站架构核心技术》
相比《大型网站技术架构》的高屋建瓴，开涛的这本《亿级流量网站架构核心技术》则落实到细节，网站架构中常见的各种技术，比如缓存、队列、线程池、代理……，统统都讲到了，而且配有核心代码。甚至连 Nginx 的配置都有！
如果你想在实现大流量网站时找参考技术和代码，这本书最合适啦。
3、《架构即未来》
这是一本“神书”啦，超越具体技术层面，着重剖析架构问题的根源，帮助我们弄清楚应该以何种方式管理、领导、组织和配置团队。
4、《分布式服务架构：原理、设计与实战》
这本书全面介绍了分布式服务架构的原理与设计，并结合作者在实施微服务架构过程中的实践经验，总结了保障线上服务健康、可靠的最佳方案，是一本架构级、实战型的重量级著作。
5、《聊聊架构》
这算是架构方面的一本神书了，从架构的原初谈起，从业务的拆分谈起，谈到架构的目的，架构师的角色，架构师如何将架构落地……强烈推荐。
不过，对于没有架构实践经验的小伙伴来讲，可能会觉得这本书比较虚，概念多，实战少。但如果你有过一两个项目的架构经验，就会深深认同书中追本溯源探讨的架构理念。
6、《软件架构师的 12 项修炼》
大多数时候所谓的“技术之玻璃天花板”其实只是缺乏软技能而已。这些技能可以学到，缺乏的知识可以通过决定改变的努力来弥补。
（本文来源腾讯技术工程，作者guisuhuang）
