应用架构（剖面架构），也叫“逻辑架构图”

二、应用架构（截面架构，也叫逻辑架构图）：

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

相似的：

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

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

1、职责分工：定义应用的边界（每个逻辑模块或子系统）

1）逻辑层次结构

2）子系统，模块定义。

3）关键类。

2、职责之间的协作：

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

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

有两种应用分层的方法：

一种是横向划分（​​ntal），按照功能处理顺序对应用进行划分，比如将系统划分为web前端/中间服务/后端任务，是业务深度的划分。

另一种是垂直划分（ ），根据不同的业务类型来划分应用。例如，进销存系统可以分为三个独立的应用程序，这是针对业务广度的划分。

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

应用的划分偏向业务，体现业务架构，应用的整合偏向技术，影响技术架构。划分降低了业务复杂度，使系统更加有序，而合并增加了技术复杂度，使系统更加无序。

应用架构的本质是通过系统拆分来平衡业务和技术的复杂性，从而保证系统完好无损。

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

三、数据架构

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

四、代码架构（也称为开发架构）：

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

代码结构的主要定义：

一、代码单元：

1、配置设计

2、框架，类库。

二、代码单元组织：

1、编码约定，编码约定。

2、项目模块划分

3、顶层文件结构设计，如mvc设计。

4、依赖

五、技术架构

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

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

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

六、部署拓扑图（实际物理架构图）：

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

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

3、架构级别

我们使用金字塔的建筑层次来说明，上层包含下层：

系统级，即整个系统内各部分的关系以及如何治理：分层

应用层，即单个应用的整体架构及其与系统中单个应用的关系。

模块级，即应用程序内部的模块架构，如代码模块化、数据和状态管理等。

在代码层面，从代码层面保证架构的实现。

战略设计和战术设计

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

战略设计：业务架构用于指导架构师如何设计系统架构。

战术设计：应根据业务架构设计应用程序架构。

战术实现：应用架构确定后，就是技术选型。

4、应用架构演进

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

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

1、单个应用

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

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

对于单体应用，非功能性需求的实践：

1、性能要求：使用缓存提高性能

2、并发需求：使用集群提升并发

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

4、使用反向代理和cdn加速

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

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

高复杂度：

以单个百万行的应用为例，整个项目包含大量模块，模块边界模糊，依赖不明确，代码质量参差不齐，乱七八糟堆积。可以想象，整个项目非常复杂。每次修改代码，哪怕是添加一个简单的功能，或者修复一个bug，都会带来隐含的缺陷。

技术债务：随着时间的推移，需求变化和人员变化，应用程序的技术债务不断增加。“不要破坏，不要修复”在软件开发中很常见，在单体应用程序中更是如此。使用过的系统设计或代码很难修改，因为应用程序中的其他模块可能会以意想不到的方式使用它。

低部署频率：随着代码的增长，构建和部署时间也在增长。在单体应用程序中，每个功能更改或错误修复都会导致需要重新部署整个应用程序。全部署方式耗时长、影响范围大、风险高，使得单个应用项目上线部署的频率较低。部署频率低也导致两个版本之间有大量的功能变化和bug修复，错误率比较高。

可靠性差：应用程序中的一个bug，如死循环、内存溢出等，可能会导致整个应用程序崩溃。

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

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

2、分布式

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

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

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

减少耦合：拆分模块并使用接口通信来减少模块之间的耦合。

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

易于扩展：添加功能时，只需添加另一个子项目，调用其他系统的接口即可。

易于部署：可以灵活地进行分布式部署。

提高代码的复用性：比如不采用分布式的REST服务架构，手机Wap商城、微信商城、PC端、iOS端都要写一层逻辑，需要大量的发展和难以共同维护。升级，这个时候可以使用分布式的rest服务方式，可以使用普通层。

缺点：系统间交互需要使用远程通信，接口开发增加工作量，但利大于弊。

3、微服务

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

微服务的特点：

易于开发和维护：微服务只关注特定的业务功能，业务清晰，代码量少。开发和维护单个微服务相对简单。整个应用是由几个微服务构建的，所以整个应用也会保持在可控状态。

单个微服务启动更快：单个微服务的代码更少，所以启动会更快。

部分修改易于部署：只要修改了单个应用程序，就必须重新部署整个应用程序。微服务解决了这个问题。一般来说，要修改一个微服务，只需要重新部署该服务即可。

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

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

运维要求更高：服务越多，运维投入越大。在单体架构中，只需启动并运行一个应用程序。在微服务中，需要保证几十个甚至上百个服务的正常运行和协作，这给运维带来了很大的挑战。

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

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

重复工作：许多服务可能使用相同的功能，但该功能尚未分解为微服务。这时候每个服务都可能开发这个功能，导致代码重复。尽管可以使用共享库来解决这个问题（例如，可以将功能封装到一个公共组件中，供需要该功能的微服务引用），但共享库在多语言环境中并不一定可行。

5、衡量架构的健全性

该架构服务于业务。没有最优的架构，只有最合适的架构。架构总是以高效、稳定和安全为目标来衡量其合理性。

合理的架构设计：

一、业务需求视角

1、可以解决当前的业务需求和问题

2、高效完成业务需求：能以优雅、可复用的方式解决当前所有业务问题

3、前瞻设计：可以满足未来一段时间内第二种方式的业务，这样每次业务演进时，不会导致架构发生巨变。

二、非业务需求视角

(一），稳定性。指标：

1. 高可用性：为了尽可能提高软件的可用性，我想每个操作者都不愿意看到自己的工作不能正常进行。黑盒白盒测试、单元测试、自动化测试、故障注入测试、提高测试覆盖率是一步步推进的。

(二），高效指标：

1. 文档：无论是整个生命周期的一部分还是整个生命周期的一部分，都必须有据可查。变更的来源包括但不限于错误和需求。

2. 可扩展：软件设计坚持低耦合的理念，在合理的地方注意抽象。它促进了功能更改、添加和应用技术的迭代，并支持适时重构架构。

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

(三）, 安全指标

1. 安全性：组织运营过程中产生的数据具有商业价值，保证数据的安全性也是当务之急。为了避免像XX门这样的丑闻。加密、https等是常用手段

6、常见的架构错误

开车高走不现实

● 缺少关键约束和非功能性需求

● 为空虚的未来过度设计

● 过早做出关键决定

● 客户说什么就是什么，成为沟通者

● 工作努力，缺乏远见

● 架构设计还考虑系统可测试性

● 架构设计不应该一步到位

误区 1 - 架构完全由架构师完成，而不是由业务开发人员完成

架构再好，最终还是需要代码落地，而且组织越大越难落地。不仅是系统架构，每个解决方案、每个项目都有自己的架构，比如分层、设计模式等。如果每块砖都不够坚固，整个系统还是有崩溃的危险。所谓“千里之堤崩于蚁巢”。

误区二——一旦架构师确定了架构蓝图，任务就结束了

建筑不是“空中楼阁”，最终还是要落地，但建筑师根本不深入一线，怎么知道“地”在哪里？怎么可能稳稳的跌。

误区三——不要没有完美的建筑设计

世界上没有最好的建筑，只有最适合的建筑，不要试图一下子做完。我们需要的不是一次造车，而是从独轮车-->自行车-->摩托车，最后造车。想象一下将在 2 年内生产的产品。市场还存在吗？

误区 4 - 为空虚的未来过度设计

创业初期，很难把握业务场景和需求边界。产品需要快速迭代和变现，需求经常更新。此时需要的是快速实施。以后扩展不要想太多，可能功能做完了，效果不好，就没用了。如果业务模型和应用场景的边界比较清晰，那么未来的可扩展性设计就应该好好考虑。

误区 5 - 追随大公司的解决方案

由于大公司巨大成功的光环效应，再加上从大公司挖来的技术专家的影响力，网站在讨论架构决策时最有说服力的一句话是“淘宝这样做”或“腾讯就是这样做的” 。”

大公司的经验和成功模式很重要，值得借鉴，但如果你因此而盲目服从，你就会失去坚持自己的勇气，迟早会迷失在架构演进的道路上。

误区 6 - 为技术而技术，

技术是为商业而存在的，仅此而已。在技​​术选型和架构设计上，对时尚新技术的追求可能会带动技术发展，架构之路会越来越艰难。考虑实现成本、时间、人员等方面要综合考虑，理想与现实需要妥协。

7、架构知识体系

架构演变

建筑模式

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

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

分散式

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

缓存：优化系统性能

异步：减少系统的耦合

提供系统可用性

更快的响应时间

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

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

安全：

架构核心元素

高性能：网站的灵魂

可用性：保证服务器不宕机，通常通过冗余部署备份服务器

可扩展性：搭建集群，是否能快速响应大规模流量增长，是否容易添加新机器

簇

可扩展性：主要关注功能需求，响应业务扩展，快速响应业务变化。是否实行开闭原则，系统耦合取决于

安全性：对网站的各种攻击，各种漏洞是否被堵住，架构是否能限流防止ddos攻击。

8、建筑书籍推荐

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

这是一本比较早的书，系统地介绍了大型网站的技术架构。通俗易懂，充满智慧。即使您以前从未接触过网站开发，通过阅读前几章，您也可以快速掌握常见的网站技术架构及其应用。场景。很不错。

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

与“大型网站技术架构”的高层次建设相比，开淘的“亿级流量网站架构核心技术”实现了细节，以及缓存、队列等网站架构中常见的各种技术。 、线程池、代理……，什么都提到了，而且配备了核心代码。连 Nginx 配置都有！

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

3. “建筑就是未来”

这是一本超越具体技术层面的“魔法书”，重点分析架构问题的根本原因，帮助我们弄清楚如何管理、领导、组织和配置团队。

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

本书全面介绍了分布式服务架构的原理和设计，并结合作者在实现微服务架构过程中的实践经验，总结出保证在线服务健康可靠的最佳方案。是架构级、实用型的重量级作品。

5. “聊天架构”

这是一本关于建筑的神奇书。从架构的开始，从业务的拆分，到架构的目的，架构师的角色，架构师如何实现架构……强烈推荐。

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

6. 《软件架构师的 12 条实践》

很多时候所谓的“技术玻璃天花板”其实只是缺乏软技能。这些技能是可以学习的架构师，并且可以在决定改变的努力中弥补知识的不足。