单体式架构

垂直架构

分布示架构

分布式架构所带来的成本与风险

分布式事物：

分布式事物是指一个操作，分成几个小操作在多个服务器上执行，要么多成功，要么多失败这些分布事物要做的

不允许服务有状态（stateless service）

无状态服务是指对单次请求的处理，不依赖其他请求，也就是说，处理一次请求所需的全部信息，要么都包含在这个请求里，要么可以从外部获取到（比如说数据库），服务器本身不存储任何信息。

服务依懒关系复杂

服务 A --> B--> C 那和服务C 的修改就可能会影响 B 和C，事实上当服务越来越多的时候，C的变动将会越来越困难。

部署运维成本增加

不用说了，相比之前几个节点，运维成本的增加必须的。

源码管理成本增加：

原本一套或几套源码现在拆分成几十个源码库，其中分支、tag都要进行相应管理。

如何保证系统的伸缩性：

伸缩性是指,当前服务器硬件升级后或新增服务器处理能力就能相对应的提升。

分布式会话：

此仅针对应用层服务，不能将Session 存储在一个服务器上。

分布式JOB

通常定时任务只需要在一台机器上触发执行，分布式的情况下在哪台执行呢？解决:master选举机器触发，使用一个单独的定时任务服务

分布式架构的三种解决方案

1. 基于反向代理的中心化架构

2. 嵌入应用内部的去中心化架构

3. 基于独立代理进程的Service Mesh架构

基于反向代理的集中式分布式架构

这是最简单和传统做法，在服务消费者和生产者之间，代理作为独立一层集中部署，由独立团队(一般是运维或框架)负责治理和运维。常用的集中式代理有硬件负载均衡器(如F5)，或者软件负载均衡器(如Nginx)，这种软硬结合两层代理也是业内常见做法，兼顾配置的灵活性(Nginx比F5易于配置)。

嵌入应用内部的去中心化架构

这是很多互联网公司比较流行的一种做法，代理(包括服务发现和负载均衡逻辑)以客户库的形式嵌入在应用程序中。这种模式一般需要独立的服务注册中心组件配合，服务启动时自动注册到注册中心并定期报心跳，客户端代理则发现服务并做负载均衡。我们所熟悉的 duboo 和spring cloud Eureka +Ribbon 都是这种方式实现。

基于独立代理进程的架构(Service Mesh)

这种做法是上面两种模式的一个折中，代理既不是独立集中部署，也不嵌入在客户应用程序中，而是作为独立进程部署在每一个主机上，一个主机上的多个消费者应用可以共用这个代理，实现服务发现和负载均衡，如下图所示。这个模式一般也需要独立的服务注册中心组件配合，作用同第二代架构。

模式	优点	缺点	适应场景	案例
集中式负载架构	简单集中式治理与语言无关	配置维护成本高多了一层IO 单点问题	大部分公司都适用，对运维有要求	亿贝、携程、早期互联网公司
客户端嵌入式架构	无单点性能更好	客户端复杂语言栈要求	中大规模公司、语言栈统一	Dubbo 、 Twitter finagle、 Spring Cloud Ribbon
独立进程代理架构	无单点性能更好与语言无关	运维部署复杂开发联调复杂	中大规模公司对运维有要求	Smart Stack Service Mesh