一次没有设计图的架构设计总结。架构设计其实并没有绝对统一的路径，这也是为什么有这么多不同架构设计文章的原因。讲解Spring原码可以是架构设计，讲解UML可以是架构设计，讲解领域驱动业务分析可以是架构设计，讲解Nginx代理服务器也可以是架构设计。
三高一低
“秒杀系统”是一种面试时很常用的问题系统，用来讨论架构设计和解决问题的思路，为什么秒杀系统这么典型呢？因为秒杀是一种平时遇不到的极端场景，这个极端场景包含了高并发、高可用，高并发高可用也变成了衡量技术能力的一个重要量化指标，就好像能够做到支撑并发10W的一定比支撑1W的优秀。当然有一定的道理，毕竟规模性也是衡量复杂度的一个重要维度。
三高一低是一种衡量软件系统优秀程度的方法。
| 维度 | 描述 |
|---|---|
| 高可用 | 在非正常情况下系统仍难能够提供正常服务的能力 |
| 高并发 | 在短时间大量用户访问系统时提供访问的能力 |
| 高扩展 | 系统应对业务或者技术变化的难易程度 |
| 低耦合 | 业务或者技术组件间耦合多少程度 |
“秒杀系统”天然具有高可用、高并发两个特性。
架构的描述
三高一低是一种架构设计方法，以前讨论过架构的基础是构件，下面是架构中一般的构件描述。
架构的一般构件
| 构件 | EN | 描述 |
|---|---|---|
| 框架 | Framework | 框架是基于一组类库或工具，在特定领域里根据一定的规则组合成的、开放性的应用骨架。比如Spring |
| 模块 | Module | 模块是业务或系统特定维度的一种切分，同时也可以看做是各种功能按照某种分类聚合的一种形式。例如一个电商系统，可以从业务上划分为用户模块、商品模块、订单模块、支付模块、物流模块等。 |
| 组件 | Component | 组件是一组可以复用的业务功能的集合，包含一些对象及其行为。组件可以直接被用做业务系统的组成部分，粒度一般小于模块，也是一种功能的聚合形式。比如日志组件、权限组件等。 |
| 插件 | Plugin | 插件是一组拥有相同生命周期定义的特殊组件，包含一些特定的公共行为。插件一般是在某一限制Context上下文内使用。比如管道过滤器架构的消息插件、过滤插件等。 |
| 服务 | Service | 服务是一组对外提供业务处理能力的功能，服务需要使用明确的接口方式。服务描述里应该包括约束和策略定义。比如 WebService 或 REST。 |
| 平台 | Platform | 平台一般来说，是一个领域或方向上的业务生态系统，是很多解决方案的集大成者，提供了很多的服务、接口、规范、标准、功能、工具等。 |
架构的一般演进
| 模式 | EN | 描述 |
|---|---|---|
| 单一应用架构 | Single | 业务体量小流量低 |
| 垂直应用架构 | --- | 部分业务抽象度高流量大 |
| 分布式服务架构 | RPC Service | 较大业务体量和团队人员 |
| 微服务架构 | Micro Service | 大流量和业务体量 |
| 服务网格架构 | Service Mesh | 微服务和云原生结合产物 |
设计的描述
三高一低的重点在于设计，针对于这几个设计维度，在不同的架构构件下有不同的设计方案，并且在不同的架构演进阶段也要有不同的适配方案。忽略演进阶段尝试填写下面的表格。
| 维度 | 高可用 | 高并发 | 高扩展 | 低耦合 |
|---|---|---|---|---|
| 框架 | / | 线程VS协程 | / | / |
| 模块 | / | / | 抽象类/接口 | 设计模式 |
| 组件 | / | / | / | 组件化抽象 |
| 插件 | / | / | 插件化设计 | / |
| 服务 | 集群网关 | 异步化 | / | / |
| 平台 | / | / | 领域生态 | 业务规范 |
注：没有标准答案
填写上面表格后会发现，在不同的构件上对三高一低有不同的支撑力度，当然每个人的关注点不同一定会有不同的答案，但是有一点肯定是相同的，需要不同的构件解决不同维度的复杂性问题，而解决复杂性问题的过程就是软件架构设计。
架构设计不同构件应对不同维度的设计约束，从而解决架构设计中的整体复杂性问题。
