个人公众号，月伴飞鱼，欢迎关注
单体式架构
垂直架构
SOA面向服务架构
SOA架构模式也称作为：面向服务架构模式、俗称面向与接口开发，将共同存在的业务逻辑抽取成一个共同的服务，提供给其他的服务接口实现调用、服务与服务之间通讯采用rpc远程调用技术。
SOA架构模式特点：
SOA架构通讯中，采用XML方式实现通讯、在高并发下通讯过程中协议存在非常大冗余性，所以在最后微服务架构模式中使用JSON格式替代了XML。
SOA架构模式实现方案为WebService或者是ESB企业服务总线 底层通讯协议SOAP协议（Http+XML）实现传输
ESB企业服务总线
解决多系统之间跨语言通讯，数据协议的转换，提供可靠消息传输。
微服务
微服务核心就是把传统的单机应用，根据业务将单机应用拆分为一个一个的服务，彻底的解耦，每一个服务都是提供特定的功能，一个服务只做一件事
1.将一个单一应用程序开发为一组小型服务
2.每个服务运行在自己的进程中
3.服务之间通过轻量级的通信机制(http rest api)
4.每个服务都能够独立的部署
5.每个服务甚至可以拥有自己的数据库
若不拆分的时候，我的非核心业务积分模块 出现了重大bug 导致系统内存溢出，导致整个服务宕机
若拆分之后，只是说我的积分微服务不可用，我的整个系统核心功能还是能使用
微服务架构与SOA架构的不同
1.微服务架构基于 SOA架构 演变过来，继承 SOA架构的优点，在微服务架构中去除 SOA 架构中的 ESB 企业服务总线，采用 http+json（restful）进行传输。
2.微服务架构比 SOA 架构粒度会更加精细，让专业的人去做专业的事情（专注），目的提高效率，每个服务于服务之间互不影响，微服务架构中，每个服务必须独立部署，微服务架构更加轻巧，轻量级。
3.SOA 架构中可能数据库存储会发生共享，微服务强调独每个服务都是单独数据库，保证每个服务于服务之间互不影响。
4.项目体现特征微服务架构比 SOA 架构更加适合与互联网公司敏捷开发、快速迭代版本，因为粒度非常精细。
微服务架构
微服务架构是一个架构风格
微服务以及微服务架构的是二个完全不同的概念
微服务强调的是服务的大小和对外提供的单一功能，而微服务架构是指把 一个一个微服务组合管理起来，对外提供一套完整的服务
分布示架构
分布式系统的特点
将系统的功能拆分到不同的节点，使用的时候再将这些系统组合起来。不同的机器运行不一样的代码。
分布式系统的好处：
- 部分的节点出现了问题系统，的其他功能还能使用。
- 要对一个业务进行修改的时候只要最业务所在的节点停机就可以了，不影响其他系统的运行。
- 可以单独对耗时的业务节点做单独的提升，跟集群相比资源的利用率更加的高
成本与风险
分布式事物：
分布式事物是指一个操作，分成几个小操作在多个服务器上执行，要么多成功，要么多失败这些分布事物要做的
不允许服务有状态（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 |