阅读说明：
本文为原创文章，转发请注明出处。如果觉得文章不错，请点赞、收藏、关注一下，您的认可是我写作的动力。
技术架构目标
有了业务架构和应用架构之后，接下来是落地，首先要有硬件机器，在硬件机器上搭建系统完成业务功能，搭建系统依赖很多技术组件。后端开发常用的技术栈如下：
-
开发语言及特性：比如java及java并发
-
开发框架：Spring，SpringMVC, Mybatis
-
数据库：关系型数据库Mysql, 非关系型数据库Redis, Memcache、Elasticsearch
-
消息队列：Kafka, RocketMQ, RabbitMQ
-
服务治理：Spring Cloud, Dubbo
-
分布式缓存：Redis集群
-
容器化与云原生：Docker、Kubernates
完成业务功能是技术架构最基本的需求，保证业务逻辑正确，数据准确。除此之外，还需要提供系统级功能：高可用、高性能、可伸缩。有了mysql，还又发展出了redis？消息队列解决了什么问题？面对不同场景，发展出了不同技术组件帮助我们提高系统能力。下面将对这三个功能指标进一步展开。
高可用(High Availability)
是指系统能够在出现部分故障或异常情况下，依然能够持续对外提供服务，最大限度减少服务中断时间。衡量可用性标准为：系统正常工作的时间除以总体时间，通常用几个9来表示，比如3个9表示99.9%的时间内系统可用, 4个9表示99.99%的时间内系统可用。
| 可用性等级 | 年宕机时间 | 月宕机时间 | 周宕机时间 | 天宕机时间 |
|---|---|---|---|---|
| 1个9（90%） | 36.5天 | 72小时 | 16.8小时 | 2.4小时 |
| 2个9（99%） | 3.65天 | 7.2小时 | 1.68小时 | 14.4分钟 |
| 3个9（99.9%） | 8.76小时 | 43.8分钟 | 10.08分钟 | 1.44分钟 |
| 4个9（99.99%） | 52.56分钟 | 4.38分钟 | 1.008分钟 | 8.64秒 |
| 5个9（99.999%） | 5.26分钟 | 26.3秒 | 6.05秒 | 864毫秒 |
导致系统出现故障或者异常通常有这两种情况：
- 软硬件故障，比如机器硬件故障、机器断电、磁盘打满、数据损坏、网络抖动、网络超时、网络断开、网卡负载满。
- 系统自身故障，比如系统处理能力不足导致cpu飙高到100%、线程池打满、OOM。进程误杀，配置错误。
故障是不可避免的，在架构设计上可采用如下方案。
冗余与备份
系统的各个处理节点做到冗余，解决单点问题。比如同一服务异地多部署，任意一台机器故障，其他节点顶上。数据库主从架构，主节点故障切换到备用节点。进一步，切换上可优化为自动切换，相比人工切换自动切换耗时更短。
服务降级
降级是指系统将某些业务或者接口的功能降低，只提供部分或者完全停掉功能。例如，论坛可以降级为只能看帖子，不能发帖子；也可以降级为只能看帖子和评论，不能发评论。降级的核心思想就是优先保证核心业务，当然是有代价的，部分服务不可用轻点影响用户体验，严重点可导致丢失单量和用户。降级有如下方案：
限流： 对流量进行管控到系统能够正常运行时承受的范围，防止系统过载。限流方法比较多，固定窗口计数、滑动窗口计数、漏桶、令牌桶等。限流粒度可大可小，比如整体请求数、单一用户请求数，根据需要采用一个或者多个指标进行限流。
降级： 系统抛弃或者延迟执行部分不重要的功能，保障核心功能的运行。
熔断： 服务出现故障或者超时时，快速返回失败，拒绝后续请求，防止故障扩散。
监控
系统故障来源众多，不可预期，防不胜防。想要保障系统的可用性，最最重要的手段是监控。通过监控，一方面我们可以实时获取当前系统的运行状态，在出现故障征兆时，提前进行干预，避免事故；另一方面，我们可以借助监控信息，快速定位和解决问题。监控指标常用如下：
- 基础监控：CPU, 内存、硬盘、网络；
- Paas检查：主从延迟、消息积压；
- 应用监控：接口整体成功率、接口整体耗时、JVM、异常日志；
- 业务监控：下单量、请求量、支付成功率等。
当然还有很多可以做，比如隔离(线程池隔离、功能拆解隔离)，服务治理(区分核心接口、弱依赖、容量评估、超时配置)、捕获异常等。采用柔性事务保障数据最终一致性以及数据对账。发布流程上自动化比对测试、分批发布。
高性能(High Performance)
高性能是指能够以低延迟（Latency）、高吞吐量（Throughput） 和高并发（Concurrency） 处理请求，同时保持资源的合理利用率。其核心目标是最大化单位时间内的有效处理能力，同时最小化响应时间和资源浪费。高性能衡量指标如下：
- 吞吐量：单位时间内系统能处理的请求数量（如 QPS、TPS）。
- 并发量：系统同时处理多个请求的能力。
- 延迟：单个请求从发出到收到响应的时间。
- 资源利用率：CPU、内存、I/O、网络等资源的有效使用率。
高性能可采用如下方案。
加快单个请求处理
加快系统处理单次请求，缩短单次请求的处理时间，提升系统单位时间内请求处理量。常用方案如下：
- 缓存：数据存储介质有机械磁盘、SSD磁盘、内存。这几个介质获取和写入数据性能对比如下：机械磁盘 << SSD磁盘 < 内存。缓存数据保存在内存中，使用缓存可大大提高系统的性能。常用的缓存技术有redis，可构建分布式集群或者单机，以及guava构建进程级别缓存。
- 数据库读写分离和添加索引：数据库读写分离，降低单机压力，提高单机吞吐量；采用合理索引，降低数据库检索时间。
- 请求并行：把一个请求分解为多个子请求，无依赖关系的子请求并行处理，最后合并结果。举个简单泡茶例子，前期准备工作洗茶壶，洗茶杯， 烧开水可并行处理，都准备妥当了之后再进行泡茶。
并行处理
一个人干不完，那就10个人一起来干。使用多个节点或者多线程技术来处理请求，从而提升系统单位时间内处理请求的数量。
请求异步化
处理核心业务时，把相对不核心的逻辑做异步化处理。比如下单时，系统实时进行扣库存、生成订单等操作，而非核心的下单送积分、下单成功发消息等操作，我们就可以做异步处理，这样就能够提升下单接口的性能。实现方式有很多，比较可靠的是消息队列，数据库 + 定时任务轮询。
另外一种异步化比较极端的例子是将请求暂存，后台再慢慢处理。对于不要求实时返回的请求并且请求流量高峰期很短时，可延长系统的处理时间，在一个相对合理的时间内，系统能够处理完就行。比如热门商品秒杀以及抢政府消费券场景，暂存介质选择redis队列，redis队列结构读写性能好，并且可获取队列长度。
可伸缩(Scalability)
可伸缩性是指系统、网络或流程在应对增长（如数据量增加、用户量增长或交易量上升）时，能够通过扩展资源来保持或提高性能的能力；在下降时，能够快速减少系统资源，降低系统成本。系统的业务量在不同的时间点，有高峰有低谷，比如餐饮行业有午高峰和晚高峰，还有电商的大促场景。
可伸缩有垂直扩展和水平扩展两种方案。垂直扩展通过增加单个节点的资源（CPU、内存、存储）来提高性能。水平扩展通过增加更多节点来分散负载。水平扩展在成本和灵活性上都更有优势，企业中一般也是采用水平扩展。
对于有状态节点比如数据库采用分库分表、一主多从完成改造，消息中间件添加队列和消费者。对于无状态节点，直接增删节点就可以了，甚至将多个关联服务节点打包成一个单元，以单元粒度进行整体伸缩，提高伸缩操作性。
云原生技术，发展出一套完整的方法论和技术栈来实现系统的高效扩展。docker将服务进行容器化实现快速部署，Kubernetes等工具可自动扩展/收缩容器实例数量。
总结
本文总结技术架构常用技术栈，并对如何如何实现高可用、高性能、可伸缩目标进行展开并且提供了解决方案。高可用的架构原则有冗余无单点、服务降级、监控等；高性能架构原则有缓存、异步化、并行等。在项目中，灵活应用这些原则。