2、应用架构（配置文件架构，也叫逻辑架构图）：

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

相似的：

应用架构：应用作为可独立部署的单元，为系统定义了清晰的边界，深刻影响着系统的功能组织、代码开发、部署和运维。应用架构定义了系统中有哪些应用，以及如何将应用划分为不同的应用。部分。这里所谓的应用程序，就是各个逻辑模块或者子系统。

应用程序架构图中有两个关键点：

1.职责划分：明确应用程序的边界（各个逻辑模块或子系统）

1）逻辑分层

2）子系统和模块定义。

3）重点类别。

2. 职责协作：

1）接口协议：用于向外界输出应用程序的接口。

2）协作关系：应用程序之间的调用关系。

有两种应用分层的方法：

一种是水平划分（​​ntal），按照功能处理的顺序来划分应用，比如将系统划分为web前端/中台服务/后端任务，这是面向业务纵深的划分。

另一种是垂直划分（），按照不同的业务类型划分应用。比如采购、销售、库存管理系统可以划分为三个独立的应用。这是基于业务广度的划分。

应用程序的协同性体现了应用程序如何协同完成复杂的业务案例，主要体现在应用程序之间的通信机制和数据格式上，通信机制可以是同步调用/异步消息/共享DB访问等，数据格式可以是文本。/XML/JSON/ 等。

应用的分离偏向于业务，体现的是业务架构，而应用的集成偏向于技术，影响的是技术架构。分离降低了业务复杂度，让系统更加有序，而集成则增加了技术复杂度，让系统更加紊乱。

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

系统的应用架构受业务复杂度的影响，包括企业发展阶段、业务特点等；也受技术的复杂度的影响，包括IT技术发展阶段、内部技术人员的水平等。带来了技术的复杂性，应用架构的目标是解决业务复杂性，同时避免过度的技术复杂性，保证业务架构的落地。

3.数据架构

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

4、代码架构（也叫开发架构）：

子系统代码架构主要为开发者提供实际指导，如果代码架构设计不完善，会影响整体架构设计，例如公司内部不同开发团队使用的技术栈或组件不同，导致公司整体架构设计不完整。它会失控。

代码架构主要定义：

1. 代码单元：

1.配置设计

2.框架与类库。

2. 代码单元组织：

1.编码标准和编码约定。

2.项目模块划分

3.顶层文件结构设计，例如MVC设计。

4.依赖项

5. 技术架构

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

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

系统架构的设计需要架构师对软件和硬件的功能和性能有扎实的了解，这也是架构设计中最困难的部分。

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

拓扑架构，包括架构中部署的节点数量、节点之间的关系、服务器的高可用性、网络接口和协议等，决定了应用程序的运行方式、性能、可维护性和可扩展性。它是所有架构的基础。此图主要是运维工程师的关注点。

物理架构主要考虑硬件的选择和拓扑、软件到硬件的映射以及软件和硬件之间的相互影响。

3. 应用架构演进

业务架构是生产力，应用架构是生产关系，技术架构是生产工具。业务架构决定应用架构，应用架构需要适应业务架构，随着业务架构​​而演进。同时，应用架构又依赖技术架构最终着陆。

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

1. 单体应用

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

典型的三层架构，前端（Web/移动端）+中间业务逻辑层+数据库层。这是一个典型的Java MVC或者框架应用。其架构图如下：

对于单片应用程序，非功能性要求：

1.性能需求：使用缓存提高性能

2. 并发需求：使用集群提高并发

3.读写分离：数据库读写分离

4.使用反向代理和CDN加速

5.使用分布式文件和分布式数据库

单片应用更易于部署和测试。在项目初期，单片应用可以运行良好。然而，随着需求的不断增加，越来越多的人加入开发团队，代码库迅速膨胀。慢慢的，单片应用变得越来越臃肿，可维护性和灵活性逐渐下降，维护成本越来越高。下面列举一些单片架构应用的缺点：

复杂度高：以一个拥有数百万行代码的单体应用为例，整个项目包含众多模块，模块之间边界模糊，依赖关系不明确，代码质量参差不齐，杂乱地堆砌在一起。我知道整个项目非常复杂，每次修改代码我都心惊胆战，哪怕是增加一个简单的功能或者修复一个bug，都会带来隐藏的缺陷。

技术债务：随着时间的推移、需求变化、人员变动，应用程序的技术债务会逐渐形成和积累。“如果没有坏，就不要去修”，这在软件开发中非常常见，而这在单片应用程序中尤其如此。这个想法甚至更加严重。所使用的系统设计或代码很难修改，因为应用程序中的其他模块可能会以意想不到的方式使用它。

部署频率低：随着代码的增加，构建和部署的时间也随之增加。在单片应用程序中，每次更改功能或修复缺陷都需要重新部署整个应用程序。全面部署耗时且影响很大而且风险较大，这就使得单体应用项目上线部署的频率较低，部署频率低导致两次发布之间有大量的功能变更和缺陷修复，错误率比较高。

可靠性差：应用程序的错误（例如无限循环或内存溢出）可能会导致整个应用程序崩溃。

扩展性有限：单体应用只能整体扩展，无法根据业务模块的需求进行扩展，比如应用中有些模块是计算密集型的，需要强大的CPU；有些模块是IO密集型的，需要更大的内存。由于这些模块部署在一起，因此在硬件选择上必须做出妥协。

阻碍技术创新：单体应用往往采用统一的技术平台或解决方案来解决所有问题，团队中每个成员都必须使用相同的开发语言和框架，因此很难引入新的框架或新的技术平台。

2.分布式

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

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

该架构相比单体架构，提供了负载均衡能力，大大提升了系统负载能力，解决了网站的高并发需求，同时还具有以下特点：

降低耦合：拆分模块，通过接口通信，降低模块间的耦合度。

职责明确：将项目拆分成若干个子项目，不同的团队负责不同的子项目。

扩展容易：若要增加功能，只需要添加子项目，调用其他系统的接口即可。

部署简便：可灵活进行分布式部署。

提高代码复用性：比如如果不采用分布式rest服务架构，那么手机Wap商城、微信商城、PC、iOS端都要各自写一层逻辑，这样会需要大量的开发和维护会比较困难。升级的话，这时候就可以使用分布式rest服务的方式，共用一层。

缺点：系统间交互需要远程通讯，界面开发增加了工作量，但优点大于缺点。

3. 微服务

随后商业模式变得越来越复杂，有订单、商品、库存、价格等深入的模块，例如根据会员等级、访问渠道（APP或PC）、销售方式（团购或拼团）进行价格差异化。价格促销方式也比较复杂，容易产生冲突，需要将分散到各个业务的价格逻辑统一起来，以基础价格服务的形式透明地提供给上层应用，从而形成微内核面向服务的架构。服务。

微服务的特点：

易于开发和维护：微服务只关注特定的业务功能，因此业务清晰，代码量少。单个微服务的开发和维护相对简单。整个应用由多个微服务组成。因此整个应用都将维持在可控状态。

单个微服务启动更快：单个微服务代码较少，因此启动速度更快。

本地修改使部署更简单：如果修改了单体应用，则必须重新部署整个应用。微服务解决了这个问题。一般来说，修改微服务，只需要重新部署服务即可。

不限技术栈：在微服务架构中，可以根据项目业务和团队的特点，合理选择技术栈。比如有些服务可以使用关系型数据库；有些微服务有图形计算需求，可以使用；根据需求，有些微服务可以使用Java开发，有些微服务可以使用Node.js开发。

尽管微服务有很多吸引人的特性，但它并不是免费的午餐。使用它是有代价的。使用微服务架构的挑战。

运维要求更高：服务越多，运维投入也就越大。单体架构下，只需要保证一个应用正常运行即可。微服务下，需要保证几十个甚至几百个服务的正常运行，运维难度很大。对操作和维护带来挑战。

分布式固有的复杂性：采用微服务构建分布式系统，对于分布式系统来说，系统容错、网络延迟、分布式事务等都会带来巨大的挑战。

接口调整成本高：微服务之间通过接口进行通信，如果修改某个微服务的API，所有使用该接口的微服务可能都需要调整。

重复工作：许多服务可能使用相同的功能，但此功能尚未达到分解为微服务的水平。在这种情况下，每个服务都可能开发此功能，从而导致代码重复。虽然可以使用共享库可以解决这个问题（比如可以将这个功能封装成一个公共组件，需要这个功能的微服务引用这个组件即可），但是在多语言环境下共享库可能就无法发挥作用。

4.衡量架构的合理性

架构是服务于业务的，没有最优的架构，只有最合适的架构，架构的合理性永远以效率、稳定、安全来衡量。

1.稳定性。指标：

1.高可用性：尽可能提高软件的可用性，我想每个运维人员都不希望看到自己的工作无法正常开展。黑盒测试、白盒测试、单元测试、自动化测试、故障注入测试、完善测试我们将通过提高覆盖率等方法一步步推进。

2、高效指标：

1. 文档：整个生命周期中都必须做文档，无论是全部还是部分。变更源包括但不限于 Bug 和需求。

2、可扩展：软件以低耦合的理念设计，注重在合理的地方进行抽象，方便功能的变更、增加，以及应用技术的迭代，支持架构的及时重构。

3.高复用性：为了避免重复工作，降低成本，我们希望复用以前的代码和设计。这个是最依赖于架构环境的。

3. 安全指标

1. 安全性：组织运营过程中产生的数据具有商业价值，保证数据的安全也是刻不容缓的一环。这是为了避免类似XX门这样的丑闻。加密等都是常用的手段

5. 常见的架构误解

误区一——架构是架构师的事，业务开发人员不需要关注：无论架构有多好，它仍然需要代码来实现，而且组织越大，实现起来就越困难实施。每个项目也有自己的架构，比如分层、设计模式等。如果每一块砖瓦都不够坚固，整个系统仍然有崩溃的风险。俗话说“千里之行，始于足下”。水坝因蚁洞而坍塌。”

误区二：架构师的工作在确定架构蓝图后就结束了：架构不是“空中楼阁”，最终必须实现。但是，如果架构师不去实践，他怎么知道“地面”在哪里呢？到前线去？他怎么执行？稳定性很牢固。

误区三：没有完美的架构设计就不要动工：世界上没有最好的架构，只有最适合的架构。不要试图一下子就实现一切。我们需要的不是造一辆车一次只能生产单轮车-->自行车-->摩托车，最后是汽车。想象一下，两年后才能生产出产品。那时市场还会存在吗？

误解 4——过度设计未来

误区五：努力工作，缺乏远见

6. 建筑知识体系

架构演进

初始阶段：LAMP，部署在一台服务器上

应用服务器与数据服务器分离

使用缓存来提高性能

使用集群提高并发性

数据库读写分离

使用反向代理和 CDN 来加速

使用分布式文件和分布式数据库

业务拆分

分布式服务

架构模式

分层：水平分层：应用层、服务层、数据层

细分：垂直细分：拆分功能和服务

分散式

分布式应用程序和服务

分布式静态资源

分布式数据和存储

分布式计算

集群：提高并发性和可用性

缓存：优化系统性能

内容分发网络

方向代理访问资源

本地缓存

分布式缓存

异步：减少系统耦合

提高系统可用性

响应时间更快

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

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

安全

架构的核心元素

高性能：网站的灵魂

性能测试

前端优化

应用程序优化

数据库优化

可用性：确保服务器不会宕机，通常通过冗余部署备份服务器来实现

负载均衡

数据备份

自动发布

灰度发布

监控报警

可扩展性：搭建集群的时候，能否快速应对海量的流量增长，并且轻松的添加新机器？

簇

负载均衡

缓存负载平衡

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

分布式消息传递

面向服务

安全性：网站受到的各种攻击，各种漏洞是否被封堵，架构是否可以限流，防止DDOS攻击。

xss 攻击

SQL 注入

CSR 攻击

Web防火墙漏洞

安全漏洞

安全套接字

7. 建筑书籍推荐

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

这是一本比较早、比较系统的介绍大型网站技术架构的书籍，通俗易懂，充满智慧，即使你之前没有接触过网站开发，也能快速掌握常见的网站技术架构及其应用读了前几章，场景。非常好。

2、亿级流量网站架构核心技术

相比于《大型网站技术架构》的高层概述，凯涛的《亿级流量网站架构核心技术》则落地到细节，包括网站架构中常用的各种技术，如缓存、队列、线程池、代理……，一切都涵盖了，并且附带核心代码。甚至包括配置！

如果您想找到实现高流量网站的参考技术和代码，这本书是最好的。

3. 建筑是未来

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

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

本书全面介绍了分布式服务架构的原理与设计，并结合作者在实现微服务架构的实践经验，总结出保证在线服务健康可靠的最佳解决方案，是此类书籍中一本重量级的著作。

5. 让我们谈谈建筑

这是一本很棒的架构书，讲了架构的起源，业务的拆分，架构的目的，架构师的角色，架构师如何实现架构……强烈推荐。

不过，对于那些没有实际建筑经验的人来说，可能会觉得这本书比较抽象，概念比较多，实践经验比较少。但如果你有过一两个项目的建筑经验，你会深深地同意这本书是一个很好的起点。追溯源头的建筑理念。

6. 软件架构师的 12 条准则

很多时候所谓的“技术玻璃天花板”其实只是缺乏软技能。这些技能是可以学习的，知识的缺乏可以通过做出改变的决心来弥补。

摘要参考：

《大型网站技术架构》

软件架构设计

建筑摆渡人，建筑师之路的指引者。本账号会定期分享建筑相关文章，关注建筑方向。关注我们，下一个建筑师可能就是你。