系统架构发展
单体应用
在互联网的发展初期，用户数量少而造成的一般站点流量也非常的少，但服务器等硬件产品的价格较高。因此一般的开发者会选择将 站点的所有功能 集成在一起，来进行开发，这就是 单体应用。随着单体应用的发展，也出现了 MVC、MVP、MVVM等开发单体应用的程序依然可以满足业务的需求。
优缺点
而单体应用的有优点有
- 易于开发、测试、管理、部署
- 想对于微服务中可以避免开发
应用缺点：
- 团队合作困难
- 代码的维护的较为无语
- 项目的重构很复杂
- 对项目的可扩展读有很大的阻碍
- 随着项目的资源越来越大，code 越来越多，会造成编译时的速率。
为了解决这个问题，随着访问量的不断增大，数据访问框架 ORM的工作量过载导致数据库崩溃。单体应用可以根据集群来进行应对，由于他的缺点需要对之前的单体应用进行一定的拆分，因此 垂直应用 就出现了人们的视野中。
垂直应用
为了解决上述单体应用随着访问量的不断增大，因此单体应用只能通过集群来进行解决和应对，而在此过程中衍生了垂直应用。垂直应用可以根据业务的需求来解决单体应用的缺点。
垂直应用即 使用分层设计的开发应用，也随着系统复杂度的增加，系统架构的变化和侧重点均不一样。之前介绍的单体应用 当网站流量小的时候，只需要一个应用将所有功能部署一起，来减少部署的节点和成本，而此时的 数据访问框架（ORM） 的工作量多少，成为了服务器是否崩溃的关键。
垂直应用为了解决这个问题，将单一用用拆分成互不干扰的多个应用，来提升效率，此时用于加速前端开发的 MVC 框架成为关键。我们将一个单体应用拆分成了三个单体应用，这样可以 解决高并发，资源分配的问题，并提高项目的扩展、容错性以及资源分配等。
水平拆分
垂直应用的拆分可以分为 水平拆分 以及 垂直拆分，其中说平拆分主要是指根据 所属业务也进行划分。但是水平拆分会造成存在 重复造轮子 的问题，且难于维护，而优点是业务拆分后的互相影响较小。
垂直拆分
所谓垂直拆分，即根据按照 系统 来进行拆分，因此 Auth 可以被拆分为 登录和注册。垂直拆分的有点是可以按照分配资源和流量，以及垂直调用之间不会进行影响，但缺点是完全存在 重复造轮子 的问题。
分布式应用应用系统
分布式应用系统是由 若干个独立的计算机集合 ，而成的分布式应用系统。简单概述下就是可以将此堪称两个服务分别运行在两台主机中，他们的相互协作来最终完成一个功能或服务，从理论中来讲这将会被称之为 分布式系统。
当然，在上述中我们讲到了垂直应用，如果是相同的程序，将会被称之为 集群，通过不断的 横向扩展 来提升服务能力。
关于横向和纵向扩展
横向和纵向扩展，也有人称之为水平扩展和垂直扩展，我们可以假设下当有一台服务器，每天经历了几千次请求天天崩，因此你需要提升服务器性能。此时 横向扩展就是多增加几台服务器一起进行服务，而 纵向扩展 则是将该服务器换成性能更好的服务器。
服务治理
随着服务数量的不断增加，服务中的资源浪费和调度等问题也会随之而来，此时服务治理（Service-Oriented Architecture (SOA) governance）的作用就起到了一个可以基于访问压力来实时管理集群的容量，从而提高集群的利用率。
为什么要使用 SOA？
- SOA 在市场中得到了广泛的使用，可以快速的响应并根据情况作出有效的更改
- SOA 解决了 服务间的通信问题 ，通过引入 ESB、技术规范、服务管理规范来解决不同服务之间的通信问题
- SOA 解决了 基础服务的梳理 问题，以 SEB 为中心树立和规整了分布式服务
- SOA 解决了 业务服务化的问题，将业务为驱动，将业务封装到服务中。
- SOA 解决了 服务可复用 的问题，将业务功能设置为通用的业务服务，来实现业务的逻辑复用。
ESB
企业服务总线（ESB，The Enterpries Service Bus）可以将类似总线的基础设施将所有服务连接在一起。并作为服务治理中的通信中心，允许连接多个系统、应用和数据，并无终端地址连接多个系统。
微服务
需要庆幸的是，微服务（Microservices）采用的是服务治理中心，而不是在 SOA 架构中的中心话 ESB，因此服务的调度不需要知道 服务提供者的IP地址、端口号等，住需要知道在服务中心 注册了的服务名即可。
微服务指的是将 系统业务功能划分为极小的独立微服务，每个微服务只关注于某个完成的一个小任务。因此系统中的单个微服务可以被独立部署和扩展，在上图中，Provider 1 和 Provider2 在 服务中心（Eureka Server） 注册微服务来让 服务消费者（Service Consumer）进行调用服务（Remote Call）
服务网格
服务网格（Service Mesh）独立与服务之外运行，是服务间通信的基础设施层，可以将它比作是应用程序或微服务之间的 TCP/IP，负责服务之间的网格调用、限流、融断以及监控等。服务网格由 数据平台(Data Plane)和 控制平台(Control Plane) 组成，服务与服务之间通过 边车（Sidecar） 来进行通信，所有边车和网络链接就形成了 服务网格（Service Mesh），其中 Sidecar 主要负责服务发现和容错处理。
数据平台与控制平台
数据平台主要用于 处理服务之间的通信，并实现服务的发现，复杂均衡、流量管理、健康检查等。而控制平台主要用于 管理并配置边车（Sidecar）来执行策略和搜集数据。
在正常的情况下应用程序的开发人员并不会关系 TCP/IP层，这在服务网格时也依然适用，开发人员也不需要关心服务的融断、断流、限流、监控等，因为这些都将由服务网格处理
特点与区别
一是服务网格的 侧重点 不同，为服务架构更关注服务之间的 生态（如服务治理 SOA） ，而服务网格则更关注服务之间的 通信。
二是 侵入性不同，微服务架构实现了架构间分离出来解决问题（解藕），而服务网格则实现了服务框架与服务之间分离出来解决问题。需要值得注意的是服务网格是服务之外独立运行的模块，他提供了微服务框架功能，但不需要在代码和配置中添加相应的依赖库和依赖配置项。
服务网格的特点有：
- 对服务没有侵入性
- 是一个应用程序之间的中间层
- 一个轻量级的网络代理
- 应用程序对服务网格无感知
- 能够分离出来解决用用程序的重试、监控、追踪和服务发现等问题。