软件架构（Software Architecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图。
通俗地来讲，技术架构就是对软件系统各个维度进行不同模块化的抽象，通过抽象使原本复杂的工程变得易于理解和分工实现。就像泰勒提出的科学管理，通过标准化的作业流程和分工，原本混沌复杂的软件工程被拆分出前端、后端、质量、运维等多个岗位。以后端为例，根据不同的岗位职责，按照康威定律又被拆分出不同的组织，比如订单组、用户组、交易组等，进而使整体的生产力大大提升。因此，架构的本质是抽象分类，进而指导软件系统的实现。
通常好的架构要能够支持高并发、高可用、高扩展。这些都是架构设计中应该关注的特性。除此之外，好的架构还应该关注如下特性。
- 可用性和可靠性。由于软件系统对于用户的商业经营和管理来说极为重要，因此软件系统必须非常可靠。可用性和可靠性虽然是两个不同的属性，但本质都是为了提升业务连续性，使企业的业务尽可能不中断。
- 高性能。高性能体现了架构在同样的物理配置下的业务支撑能力，更高的吞吐量、更低的响应时间意味着对用户更快速地响应。
- 易维护性。软件系统的维护包括两方面，一是排除现有的错误，二是将新的软件需求反映给现有系统。一个易于维护的系统可以有效降低技术支持的费用。
- 可扩展性。市场和用户总是在不断变化的，为了适应业务的高速迭代，尤其是一些2B企业的个性化需求，架构要求能够在最小的改动成本下满足更多的需求。这要求架构可以根据客户群的不同和市场需求的变化进行调整。
- 安全性。随着《个人信息保护法》和《数据安全法》的出台，信息安全已经成为架构设计中最重要的因素，安全合规不容小觑。
常听到各种关于架构的名词，比如业务架构、功能架构、应用架构、技术架构、物理架构等，这里简单梳理一下这几个架构的区别。
- 业务架构
业务架构一般是指业务的关键流程、组织形式、信息流。以电商为例，业务架构包括选品、采购、仓储、物流、供应商、订单等一系列的业务版块。业务架构体现的主要是业务模式和流程，核心是定义业务痛点，厘清功能需求和非功能性需求。
- 功能架构
功能架构一般是指产品具备的细分功能。例如，电商系统的功能架构可细分为用户管理、登录注册、商品管理、仓库管理、订单管理、购物车管理、支付管理等核心模块。功能架构图体现的是一个产品的核心功能模块。
- 应用架构
应用架构一般是指根据业务场景设计出应用的层次结构，制定好应用间的调用、交互方式，确保它们能够融合在一起并满足业务需要。比如，电商系统的应用架构可能有用户中心、权限中心、登录系统、商品中心、搜索引擎、推荐体系、订单系统、交易系统等。应用架构体现的是用什么样的微服务去支持功能的实现。
- 技术架构
技术架构一般是指实现应用架构的关键技术栈，如Spring Cloud、ZooKeeper、RocketMQ、Redis、MySQL、Elasticsearch等中间件，以及各种核心流程的时序图、状态图等信息。
- 物理架构
物理架构一般是指从物理视角来看IDC中的物理拓扑关系，如防火墙、Nginx、网络、应用服务器、数据库间的调用和数据流转关系。物理架构关注的是如何通过硬件配置硬件和网络来配合软件系统达到可靠性、高可用性、性能、安全性等方面的要求。
除了以上大家耳熟能详的架构分类，还有很多与架构相关的名词，如下所示。
- 框架（Framework）：通常指的是为了实现某个业界标准或完成特定基本任务的软件组件规范，往往是基于一组类库或工具，在特定领域里根据一定的规则组合而成。
- 组件（Component）：一组可以复用的业务功能的集合，包含一些对象及其行为。组件可以直接用作业务系统的组成部分，颗粒度一般小于模块，也是一种功能的聚合形式，比如日志组件、权限组件等。
- 模块（Module）：基于业务数据或一组相关功能按照特定维度的逻辑划分，也可以看作各种功能按照某种分类的聚合。例如，电商系统可以从业务上划分为用户模块、商品模块、订单模块、支付模块、物流模块等。模块使一个复杂的软件变得更加容易管理和维护。
- 服务（Service）：一组对外提供业务处理能力的功能，服务需要使用明确的接口方式（比如Web Service、RESTful等）。服务描述里应该包括约束和策略（比如参数、返回值、通信协议、数据格式等）。
- 平台（Platform）：一般来说，是一个领域或方向上的生态系统，是很多解决方案的集大成者，提供了很多服务、接口、规范、标准、功能、工具等。
