一、基础概念

09-1.png

1、单服务

所有业务服务和应用组件部署在一台服务上，节省成本，这是单服务结构，适用于并发低，业务单一的场景。

2、集群模式

业务量逐渐增大，并发高，把一台服务进行水平扩展，做一个服务群，请求压力分散到不同的服务上处理，每台服务称为集群的一个节点，到这就是集群服务。

3、分布式架构

分布式结构就是按照业务功能，拆分成独立的子服务，独立的库表，可以独立运行，且服务之间通信和交互，带来的好处降低业务间的耦合度，方便开发维护，水平扩展，复用性高等等。

4、技术体系

服务基础架构：Dubbo框架，SpringCloud框架；

容器化运维：Docker、Kubernetes；

数据存储：关系型MySQL，NoSQL数据库，OLAP引擎;

常用组件：Zookeeper协调，MQ异步，Redis缓存；

二、分布式框架

1、Dubbo框架

垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架(RPC)是关键。Dubbo框架的核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。

2、SpringCloud框架

分布式架构下最成熟的框架，SpringCloud是一系列框架的有序集合。它利用SpringBoot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用SpringBoot的开发风格做到一键启动和部署。

09-2.png

核心组件

注册中心：具备服务发现、服务记录、查询、动态管理的机制。常用的注册中心，Zookeeper、Eureka、Consul、Nacos等。

熔断降级：限制流量突然高并发冲垮系统，使这类报文以比较均匀的速度流动发送，达到保护系统相对稳定的目的。常用算法令牌桶、漏斗；常用组件Nginx、CDN、Hystrix、Sentinel，通过不同节点控制流量。

服务网关：在整个架构体系上也是一个服务，作为请求的唯一入口，与外观模式十分类似，在网关层处理所有的非业务功能，为客户端提供定制的API。常用组件Zuul、Tyk、Kong。

09-3.png

3、业务型组件

消息中间件：RocktMQ、Kafka、RabbitMQ等；

缓存中间件：Redis、Eache等；

分布式事务：Seata、Hmily、TCC-transaction等；

三、架构细节

1、全局ID策略

业务场景产生的数据，都需要一个唯一ID作为核心标识，用来流程化管理。比如常见的：UUID、雪花算法、自增主键、ID容器等。

2、接口幂等性

幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。就是说，一次和多次请求某一个资源会产生同样的作用影响。在接口、重试、补偿的场景下尤其要保证操作的幂等性。

3、缓存处理

业务系统中，查询时最容易出现性能问题的模块，查询面对的数据量大，筛选条件复杂，所以在系统架构中引入缓存层，则是非常必要的，用来缓存热点数据、归档数据、首页查询等，达到快速响应的目的。

4、异步处理流程

异步是一种设计理念，异步操作不等于多线程，MQ中间件，或者消息广播，这些是可以实现异步处理的方式，异步处理不用阻塞当前线程来等待处理完成，而是允许后续操作，直至其它线程将处理完成，并回调通知此线程。

5、高并发与资源锁

高并发业务核心还是流量控制，控制流量下沉速度，或者控制承接流量的容器大小，多余的直接溢出，这是相对复杂的流程。一方面可以通过流量整形的方式解决请求量，另一方面可以通过加锁解决并发访问资源的问题。

6、分布式事务

不同的服务不同数据库的多个细节操作组成，这些无感知的细节操作分布在不同服务上，甚至属于不同的地区和应用，事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点，如何保证这些操作全部成功或者全部失败，即保证不同数据库间的数据一致性，这就是分布式事务需要解决的核心问题。

09-4.png

四、数据源组件

1、关系型数据库

采用了关系模型来组织数据的数据库，其以行和列的形式存储数据，例如MySQL、Oracle。在分布式系统下，为了保证核心流程的稳定性，在关键业务上基本都采用关系型数据库，当业务完成后，如果数据量大，会把数据同步到其他查询性能高组件中。

2、NoSQL数据库

NoSQL意即"不仅仅是SQL"。对不同于传统的关系型数据库的数据库管理系统的统称。NoSQL用于超大规模数据的存储。这些类型的数据存储不需要固定的模式，无需多余操作就可以横向扩展。例如MongoDB、Cassandra等。

3、数据管理策略

读写库分离、查询数据分库分表、分布式下业务分库、基于用户流量分库。

09-5.png

五、服务监控

1、生产故障

在分布式的复杂架构下，应用服务、软件服务、硬件服务，任何层面出问题都可能导致请求不能完整执行，引发一系列效应，做好全链路的监控，快速定位问题是非常关键的。

2、应用层监控

应用层为开发的业务逻辑服务，也是最容易突发问题的一个层面，通常从请求流量、服务链路熔断、系统异常日志几个方面做监控指标，观察系统是否稳定。

3、软件层监控

这里通常指，数据库层面，例如Druid的监控分析；常用中间件，例如RocketMQ的控制台；Redis缓存：提供命令获取相关监控数据等。

4、硬件层监控

硬件层面，关注的三大核心内容：CPU、内存、网络。底层硬件资源爆发的故障，来自上层的应用服务或者中间件服务触发的可能性偏高。成熟的监控框架，例如zabbix，grafana等。