服务器架构的演进

单体服务架构

所有的业务功能都放在一个工程中，最终经过编译、打包，部署在一台服务器上。

MVC服务架构

MVC架构是交互式应用中广泛使用的架构。它将对象按功能进行划分，尽可能地最小化对象之间的耦合度。MVC架构与传统的应用程序架构—输入，处理，输出给用户接口的模型相对应。它们也与基于域的多层企业级WEB应用相对应。

MVC架构将应用分为三层—模型，视图，控制，并减弱它们各自的责任。每一层处理特定的任务并对其它层有特殊的责任。

分布式架构

分布式架构就是指应用程序分布在不同计算机上，通过网络来共同完成一项任务，通常为服务器/客户端模式。更广义上理解“分布”，不只是应用程序，还包括数据库等，分布在不同计算机，完成同一个任务。之所以要把一个应用程序分布在不同的计算机上，主要有两个目的：

1. 分散服务器的压力
2. 提供服务，功能重用
   

微服务架构

微服务架构是一项在云中部署应用和服务的新技术。大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务，而红帽说API应该是重点。
微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程的架构。

中台业务架构

中台的出现更多是因为公司业务在发展到某一阶段时，在拥有多个业务线时继续发展遇到瓶颈与障碍后，为了解决如何继续朝下走的实际问题而提出的一个组织前台业与后台关系新解决方案的统称，而不是某个新的系统。

服务网格架构

服务网格( Service Mesh )是指用于微服务应用的可配置基础架构层( configurable infrastructure layer )。它使每个service实例之间的通信更加流畅、可靠和迅速。服务网格提供了诸如服务发现、负载均衡、加密、身份鉴定、授权、支持熔断器模式( Circuit Breaker Pattern )以及其他一系列功能。
服务网格的实现通常是提供一个代理实例，我们称之为"sidecar"。sidecar 包含在每一个service 之中。sidecar 主要处理 service 间的通信、监控、以及一些安全相关的考量 —— 任何可以从服务本体中抽象出来的安全方面的部分。通过这种方式，开发者可以在服务中专注于开发、支持以及维护；运维人员可以维护服务网格并运行app。

Istio( 由Google、IBM、Lyft公司在背后进行支持 ) 是目前最广为人知的一款服务网格架构。Kubernetes( 由Google最早进行设计并开源 ) 是目前 Istio 唯一支持的容器组织框架。