2.2. 应用架构（剖面架构，也叫逻辑架构图）：

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

类似：

应用架构：应用作为独立可部署的单元，为系统划分了明确的边界，深刻影响系统功能组织、代码开发、部署和运维等各方面. 应用架构定义系统有哪些应用、以及应用之间如何分工和合作。这里所谓应用就是各个逻辑模块或者子系统。

应用架构图关键有2点：

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

②. 职责之间的协作：

应用分层有两种方式：

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

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

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

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

2.3. 数据架构

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

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

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

代码架构主要定义：

①. 代码单元:

②. 代码单元组织：

2.5. 技术架构

技术架构：确定组成应用系统的实际运行组件（lvs，nginx，tomcat，php-fpm等），这些运行组件之间的关系，以及部署到硬件的策略。

技术架构主要考虑系统的非功能性特征，对系统的高可用、高性能、扩展、安全、伸缩性、简洁等做系统级的把握。

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

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

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

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

三. 架构级别

我们使用金字塔的架构级别来说明,上层级别包含下层：

战略设计与战术设计

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

四. 应用架构演进

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

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

4.1. 单体应用

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

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

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

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

4.2. 分布式

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

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

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

4.3. 微服务

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

微服务的特点：

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

五. 衡量架构的合理性

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

合理的架构设计：

5.1. 业务需求角度

5.2. 非业务需求角度

①. 稳定性。指标：

②. 高效指标：

③. 安全指标

六. 常见架构误区

开高走落不到实处

常见误区

七. 架构知识体系

7.1. 架构演进

7.2. 架构模式

分层：横向分层：应用层，服务层，数据层

分割：纵向分割：拆分功能和服务

分布式

集群：提高并发和可用性

缓存：优化系统性能

异步：降低系统的耦合性

冗余：冷备和热备，保证系统的可用性

自动化：发布，测试，部署，监控，报警，失效转移，故障恢复

安全：

7.3. 架构核心要素

高性能：网站的灵魂

可用性：保证服务器不宕机，一般通过冗余部署备份服务器来完成

伸缩性：建集群，是否快速应对大规模增长的流量，容易添加新的机器

集群

可扩展性：主要关注功能需求，应对业务的扩展，快速响应业务的变化。是否做法开闭原则，系统耦合依赖

安全性：网站的各种攻击，各种漏洞是否堵住，架构是否可以做到限流作用，防止ddos攻击。

八. 架构书籍推荐

1. 《大型网站技术架构：核心原理与案例分析》

这是比较早，比较系统介绍大型网站技术架构的书，通俗易懂又充满智慧，即便你之前完全没接触过网站开发，通读前几章，也能快速获取到常见的网站技术架构及其应用场景。非常赞。

2. 《亿级流量网站架构核心技术》

相比《大型网站技术架构》的高屋建瓴，开涛的这本《亿级流量网站架构核心技术》则落实到细节，网站架构中常见的各种技术，比如缓存、队列、线程池、代理……，统统都讲到了，而且配有核心代码。甚至连 Nginx 的配置都有！

如果你想在实现大流量网站时找参考技术和代码，这本书最合适啦。

3. 《架构即未来》

这是一本“神书”啦，超越具体技术层面，着重剖析架构问题的根源，帮助我们弄清楚应该以何种方式管理、领导、组织和配置团队。

4. 《分布式服务架构：原理、设计与实战》

这本书全面介绍了分布式服务架构的原理与设计，并结合作者在实施微服务架构过程中的实践经验，总结了保障线上服务健康、可靠的最佳方案，是一本架构级、实战型的重量级著作。

5. 《聊聊架构》

这算是架构方面的一本神书了，从架构的原初谈起，从业务的拆分谈起，谈到架构的目的，架构师的角色，架构师如何将架构落地……强烈推荐。

不过，对于没有架构实践经验的小伙伴来讲，可能会觉得这本书比较虚，概念多，实战少。但如果你有过一两个项目的架构经验，就会深深认同书中追本溯源探讨的架构理念。

6. 《软件架构师的12项修炼》

大多数时候所谓的“技术之玻璃天花板”其实只是缺乏软技能而已。这些技能可以学到，缺乏的知识可以通过决定改变的努力来弥补。

作者 |规速

来源丨/hguisu/article/details/