1.2 架构设计的目标
要衡量一个架构设计的优劣程度，就需要一些指标，如系统的性能、可用性、可扩展性以及可维护性。
下面就针对这些指标，详细阐述架构设计要达到的具体目标。
1.2.1 高性能
在架构设计的过程中，性能往往是非常重要的，它可以有效提升用户的操作体验，有助于实现对服务资源的高效利用。图1-1展示的是一种常见的高性能架构。
图1-1 高性能架构
当然，不是每个系统都具有这样的架构，具体细节可能会有不同，但高性能架构一般都有如图1-1中所示的几个特点。
常见的高性能架构一般采用Nginx作为接入网关，并且水平扩展，通过Nginx连接更多的接入服务，以使系统实现水平扩展。一般来说，接入服务可以划分为3种模式。
- 实时同步接入：一般采取远程过程调用（remote procedure call，RPC），高效地实现后端业务逻辑的扩展，提升调用性能。
- 实时异步接入：一般采取消息队列，其时延不高并且可以有效地降低请求达到高峰时对系统造成的过大压力。
- 近线接入：一般采取流式处理，可以高效地处理高并发、大体量的数据以及计算，例如常见的基于Flink的流式处理。
逻辑服务访问数据存储，实现对数据存储介质中数据的访问操作。如果并发访问请求量过大时仍采取直接访问数据存储介质的话，会导致数据处理瓶颈。为了解决数据处理瓶颈问题，一般有以下两种方案。
- 读写切分：考虑对数据库进行切分（如分库、分表操作），或者让数据库读写分离等。
- 添加缓存：在数据库和业务逻辑间建立起一层缓存数据，让更多数据可以直接通过缓存返回，这样可以有效避免对数据库造成直接访问的压力。
1.2.2 高可用性
可用性关注的是服务在出现故障之后是否可以快速、高效地恢复。常见的系统单点故障问题就是可用性的典型示例。
图1-2展示的是一个典型的高可用架构（以两个机房为例）。
图1-2 高可用架构
从图1-2可以看出，要实现高可用性（high availability，HA），就需要在以下各层设置服务冗余或者业务故障自动发现机制。
- 机房层：考虑到业务访问机房的网络可达性问题以及单个机房内部故障问题，因此会采用多机房架构的模式。多机房架构有热备份模式和多活模式，热备份模式就是一般情况下备用机房不接收线上流量，只有在主机房出现故障时才启用备用机房。多活模式是将线上访问流量在每个机房间按照一定的策略进行分发，每个机房随时都可正常工作，当其中一个机房出现故障时，其线上流量可以通过路由分发模块配置转发。多活机房的目标是实现系统出现故障时平滑无感知的业务迁移。
- 机架层：机房内的机架也会由于各种原因出现故障，如果所有的服务器都部署在一个机架上，显然是达不到高可用的目标的，所以一般情况下服务器会在机架层进行交叉部署，以此解决机架层出现的服务可用性问题。
- 服务层：一般来说，服务会通过服务治理机制来解决服务发现和故障剔除问题，如Dubbo服务治理组件就包含服务发现机制。
- 数据存储层：对数据库来说，一般会采取主从架构，然后引入一些实现故障发现和迁移机制的模块，例如采取主数据库高可用性（master high availability，MHA）策略来解决MySQL可用性问题。
1.2.3 可扩展性
可扩展性关注的是系统依据访问请求的大小可以实现资源的自动扩容。例如，电商在做一些活动时请求量会很大，此时就需要实现资源的扩容，而活动结束后又需要考虑释放多余的资源。这些操作都需要方便快捷地完成，这就要求系统在设计架构的时候重点考虑可扩展性。
图1-3展示的是一个常见的可扩展架构。
图1-3 可扩展架构
服务接入网关会将请求分发到后端接入，服务接入网关一般采取Linux虚拟服务器（Linux virtual server，LVS）和Nginx的配合来实现。由于系统需要可扩展，那么对于任何服务器的上线和下线，系统的处理状态应该是一致的，因此这里需要实现接入层处理的无状态化。无状态化指的是任何一台业务逻辑服务器在任何时候处理的逻辑都是保持一致的，不需要为不同用户存储特殊的状态信息。例如，对用户访问的会话（session）信息进行分布式存储，而不是每台服务器自行存储，有状态的信息就得到统一处理，而业务逻辑服务器只需实现业务功能。因此，任何一台服务器的上下线都不会影响系统的处理。
接入层实现可扩展之后就到了服务层。服务层中有所有的业务逻辑处理过程，要实现可扩展需要引入服务发现组件，这一点和在1.2.2节中讲到的高可用性是一致的，这里不赘述。
最后，数据存储要实现可扩展，一般采取数据路由存储，例如基于哈希的分片映射、基于数据范围的分区映射等都属于数据路由分发策略。这样，即使有较大的数据量，也可以实现数据的有效扩容。但是，这里还需要额外注意数据重新路由的迁移效率问题，例如用户A的数据经过分片到达了数据存储1，但是在扩容后数据路由存储到数据存储N，这时就需要考虑如何快速将用户A的数据迁移到数据存储N的问题，在这里先不进行详细阐述，第6章中会详细介绍。
1.2.4 可维护性
可维护性主要是指系统的监控、故障修复、线上运维的便利性以及问题发现的及时性等。一个系统上线之后，会由于各种原因出现线上故障，这就需要快速定位故障的位置以及找出出现故障的原因，以便快速修复故障，而对于一些不适于人工介入的情况还需要做到系统的自我修复。这时就需要对系统的可维护性进行综合考量。
图1-4展示的是一个常见的可维护架构。
图1-4 可维护架构
首先需要对所有业务系统进行系统运行状态和日志的采集（即数据采集），再通过流式处理组件（如Kafka或者Flink）进行数据处理和传输，对采集到的所有数据可以分类处理，例如数据调用及追踪、日志挖掘及分析、接口及组件的监控分析，最后把获取并分析后的数据进行可视化并展示出来，同时如果出现异常可自定义实现告警或者故障切换等操作。数据存储用来保存所有运维监控状态的原始采集数据以及分析的结果数据。这样，一个具备基本功能的可维护系统就建立起来了。