服务架构

读写分离

将数据库分为主从数据库，从库实时同步主库的更新内容；写请求访问主数据库，读请求访问从数据库；

分库分表

把原本存储于一个库的数据分块存储到多个库上，把原本存储于一个表的数据分块存储到多个表上

缓存

集群，高可用，可共享，大容量

基于二八定律，访问命中缓存，既能减小数据库的访问压力，又可以提高数据访问性能

动静分离

将服务的静态资源与后台应用进行分开部署，提高用户访问静态资源的速度（CDN），降低对后台的访问压力（集群）

（静态文件的缓存更新以及前后端的更新成本都是动静分离所带来的问题）

业务拆分---分布式

将业务进行拆分并分而治之，每个子业务模块进行独立开发、部署、运维；

随着对业务场景越来越细的划分，模块越来越多，整个应用的复杂度也越来越高，大量的独立子应用对数据库的独立访问，导致后端数据库的压力越来越大，需要将各个子应用的重叠逻辑再进行抽取为独立子服务，子应用服务之间通过RPC或者消息系统进行相互通信，因此出现了分布式应用；

SOA

（面向服务的计算，服务之间松散耦合，支持服务的封装）

把应用的公用模块提出来，采用独立部署统一管理的方式，提高重用度，这就是服务导向架构（SOA）

微服务

（微服务架构实现了业务的解耦，但分布式系统固有的难题（如分布式事务等）在微服务架构中也依然存在）

微服务架构通过业务拆分实现服务组件化，通过组件组合快速开发系统，业务单一的服务组件又可以独立部署，使得整个系统变得清晰灵活

在微服务架构中除了业务服务组件外通常会引入服务注册发现组件来进行服务治理，引入服务网关组件来提供统一入口和权限控制，引入负载均衡组件来提供客户端或服务器端的负载均衡，引入集中配置组件来提供服务集中管理，引入熔断器组件来提供服务熔断，引入服务追踪组件来提供服务监控等

因此微服务架构是由这些基础的服务组件和业务微服务组件共同组成。

 

为了保证系统不被突发流量击垮，进行容量保障是十分有必要的。从架构的稳定性角度看，在有限资源的情况下，所能提供的单位时间服务能力也是有限的。假如超过承受能力，可能会带来整个服务的停顿，应用的Crash，进而可能将风险传递给服务调用方造成整个系统的服务能力丧失，进而引发雪崩。

为了避免系统压力大时引发服务雪崩，就需要在系统中引入限流，降级和熔断等工具。

限流：

qps限流：限制每秒处理请求数不超过阈值。

并发限流：限制同时处理的请求数。

单机限流

集群限流

 

算法:

漏桶算法

令牌桶算法

滑动窗口

 

降级和熔断：

降级hystrix

业务降级，是指牺牲非核心的业务功能，保证核心功能的稳定运行。简单来说，要实现优雅的业务降级，需要将功能实现拆分到相对独立的不同代码单元，分优先级进行隔离。在后台通过开关控制，降级部分非主流程的业务功能，减轻系统依赖和性能损耗，从而提升集群的整体吞吐率。

降级的重点是：业务之间有优先级之分。

降级的典型应用是：电商活动期间。

熔断dubbo

老式电闸都安装了保险丝，一旦有人使用超大功率的设备，保险丝就会烧断以保护各个电器不被强电流给烧坏。同理我们的接口也需要安装上“保险丝”，以防止非预期的请求对系统压力过大而引起的系统瘫痪，当流量过大时，可以采取拒绝或者引流等机制。

同样在分布式系统中，当被调用的远程服务无法使用时，如果没有过载保护，就会导致请求的资源阻塞在远程服务器上耗尽资源。很多时候，刚开始可能只是出现了局部小规模的故障，然而由于种种原因，故障影响范围越来越大，最终导致全局性的后果。这种过载保护，就是熔断器。

 

降级熔断区别

1. 触发原因不一样，服务熔断一般是某个服务（下游服务）故障引起，而服务降级一般是从整体负荷考虑
2. 自愈能力要求不一样，服务熔断在发生后有自愈能力，而服务降级没有该职责