随着互联网的发展，网站应用的规模不断扩大，需求激增，带来技术上的压力，系统架构也在不断发送改变。 大致经过如下几个过程。
- 单体应用架构
- 垂直应用架构
- 分布式架构
SOA架构- 微服务架构（现在主流的架构）
Service Mesh(服务网格)
单体应用架构
单体架构就是最早期的互联网架构，应用的数据库、文件管理系统、应用都部署在同一台机器上。
- 优点：结构简单 ，容易开发和维护，开发成本较低
- 缺点：性能差，易出错，耦合度过高
垂直应用架构
随着访问量的增加，单一应用靠增加节点来应对，但是并不是所有的模块都有较大的访问量。所以只对某些模块增加节点。
比如：某个项目分两个模块，前台系统和后台系统，一般后台系统只有管理员才会登陆，访问量比较小，前台系统访问量比较大，需要增加前台系统的节点。
- 优点：整个项目拆分为多个模块，针对不同模块进行不同优化，提高效率
- 缺点：多个项目直接不能直接通信，并且还会有重复的开发任务
分布式架构
分布式架构 也是基于垂直应用架构演变而来，当垂直应用越来越多，重复的业务代码就会越来越多。这时候，我们就思考可不可以将重复的代码抽取出来，做成统一的业务层作为独立的服务，然后由前端控制层调用不同的业务层服务呢？
- 优点：抽取公共的功能作为服务层，提高代码复用性
- 缺点：系统耦合度变高，难以维护
SOA架构
在分布式架构下，当服务越来越多，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心对集群进行实时管理，比如，上面分布式架构中的前台页面系统，需要访问下面多个服务，十几二十个呢？下面的用户服务也被十几二十个调用者调用？
此时，用于资源调度和治理中心(SOA Service OrientedArchitecture，面向服务的架构)是关键
微服务架构
维基百科对于微服务的定义。
微服务 (Microservices) 是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与***语言无关*** (Language-Independent/Language agnostic) 的 API 集相互通信
微服务架构是从SOA架构模式演变过来，比SOA架构模式粒度更加精细。这个很小的粒度就是微服务。每个微服务可以独立部署，互不影响，服务之间采用http进行通信
目前互联公司采用的框架。
- 优点：粒度更加精细，不容易崩溃，服务更容易扩展和升级
- 缺点：技术成本很高，要学习很多高阶知识，才可以做出来。
Service Mesh(服务网格)
新兴的概念，但是非常火热，google提出来的技术，初出茅庐，但是有统一微服务时代的趋势
微服务模式看似非常完善，但是还存在一些本质的问题，就是通信，虽然微服务框架帮忙实现通信，但是在出现问题时，查找问题的难度也是非常大的。
所以可以把Service Mesh当作微服务时代的TCP/IP协议
服务网格是一个基础设施层，用于处理服务间通信。云原生应用有着复杂的服务拓扑，服务网格保证请求在这些拓扑中可靠地穿梭。在实际应用当中，服务网格通常是由一系列轻量级的网络代理组成的，它们与应用程序部署在一起，但对应用程序透明。
优点：
- 屏蔽分布式系统通信的复杂性(负载均衡、服务发现、认证授权、监控追踪、流量控制等等)，服务只用关注业务逻辑；
- 真正的语言无关，服务可以用任何语言编写，只需和Service Mesh通信即可；
- 对应用透明，Service Mesh组件可以单独升级；
缺点
- Service Mesh组件以代理模式计算并转发请求，一定程度上会降低通信系统性能，并增加系统资源开销；
- Service Mesh组件接管了网络流量，因此服务的整体稳定性依赖于Service Mesh，同时额外引入的大量Service Mesh服务实例的运维和管理也是一个挑战；
分布式和集群的概念
- 分布式：将一个项目的不同模块不在不同的主机上
- 集群：多个主机上运行一个项目的同一个模块以提高性能
\
