服务架构的进化史

单体系统时代 Monolithic

单体架构（Monolithic） “单体”只是表明系统中主要的过程调用都是进程内调用，不会发生进程间通信，仅此而已。

经典三层模型

在软件设计的时候经常提到和使用经典的3层模型：表现层，业务逻辑层，数据访问层。

虽然在软件设计中划分了3层模型，但是对业务场景没有划分，一个典型的单体架构就是将所有的业务场景的表现层，业务逻辑层，数据访问层放在一个工程中最终经过编译，打包，部署在一台服务器上。

image

随着访问量的不断提升，一台服务器必将无法承载一定量级的访问。因此，诞生了集群化部署。

集群

在应用初期，访问量不大，功能迭代比较频繁，单台服务部署比较方便，开发效率高且成本低。但是，随着业务的越来越复杂，用户访问量越来越大，单机的QPS很容易就达到了瓶颈。为了解决这个问题，同时提高服务器的容错，集群部署的方式就慢慢的诞生了。

image

从图中，可以很清晰的看出：将应用分别部署多个副本到多个应用服务器中，通过负载均衡将访问流量，均匀的打在每个应用服务器上。这样理论上，可以通过平行扩容应用服务器就可以解决并发访问的问题。

在应用服务器的背后，数据库、对象存储和缓存服务器 也同样使用类似的架构，来达到给应用服务器集群提供更高的连接数、更高的QPS。

优缺点

优点

1. 开发简单： 所有的业务代码都在一起，方便开发和代码管理。
2. 测试简单： 很容易对功能进行测试
3. 问题排查简单： 可以很容易在一个工程内，追踪代码，排查问题。
4. 发布简单： 只需编译一个工程，发布到服务器上。
5. 维护简单： 每一台应用服务器代码一样，环境一样。不像微服务，还需要先定位是哪个服务的问题。

缺点

随着业务的不断发展，单体架构的优势已逐渐无法适应互联网时代的快速变化，面临越来越多的挑战：

1. 维护成本增加：随着功能越来越多，模块越来越多，团队越来越大，沟通成本、管理成本也会随之增大。开发过程中，调试，错误定位等时间变长，也不容易掌握全局功能，维护修改难度增加。
2. 技术栈升级难：单体架构倾向于使用同一种技术栈，一旦选定很难更换。
3. 资源无法隔离：公用数据库、内存、缓存等资源，弱某一模块对资源使用不当，真个系统都会拖垮。
4. 无法灵活扩展：虽然支持横向扩展，但是不能灵活对个别模块单独扩展。不能做到资源精细配置。

适用场景

业务场景简单、功能不复杂、研发人员少、创业公司初期，都适合先用单体模式（当然，你的工程搭建的时候，可以模块化，只是部署的时候是单体架构）。

SOA时代 Service-Oriented Architecture

为了允许程序出错，为了获得隔离、自治的能力，为了可以技术异构等目标，是继为了性能与算力之后，让程序再次选择分布式的理由。然而，开发分布式程序也并不意味着一定要依靠今天的微服务架构才能实现。在新旧世纪之交，人们曾经探索过几种服务拆分方法，将一个大的单体系统拆分为若干个更小的、不运行在同一个进程的独立服务，这些服务拆分方法后来导致了面向服务架构（Service-Oriented Architecture）的一段兴盛期，我们称其为“SOA 时代”。

SOA 架构（Service-Oriented Architecture） 面向服务的架构是一次具体地、系统性地成功解决分布式服务主要问题的架构模式。

SOA实现的两个最重要的概念

• 面向服务的通信（SOC Service-Oriented Communicaiton）
• 面向服务的软件架构（SOSA Service-Oriented Software Architecture）

SOA（Service-Oriented Architecture）的特点：

• 易于扩展
• 灵活的平台
• 服务通信标准化
• 服务间：松耦合，无状态，无依赖
• 服务内：高内聚，完整，可复用，可灵活重组

微服务时代

微服务架构（Microservices）

微服务是一种通过多个小型服务组合来构建单个应用的架构风格，这些服务围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言，不同的数据存储技术，运行在不同的进程之中。服务采取轻量级的通信机制和自动化的部署机制实现通信与运维。

概念：把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。

定义：围绕业务领域组件来创建应用，这些应用可独立地进行开发、管理和迭代。在分散的组件中使用云架构和平台式部署、管理和服务功能，使产品交付变得更加简单。

本质：用一些功能比较明确、业务比较精练的服务去解决更大、更实际的问题。

微服务其实就是SOA的一个变种：SOA喜欢水平服务，微服务喜欢垂直服务

后微服务时代（Cloud Native）

微服务是从软件层面独立解决问题，随着K8S的崛起和Spring Cloud的成熟，逐渐软件和硬件可以一体，来解决架构问题。有的人称之为：后微服务世代（Cloud Native），也有叫 云原生的。

早期，云原生架构有几个特征：

1. 符合12模式（Twelve-Factor App）：云原生应用架构的模式集合
2. 微服务架构（Microservices）：独立部署的服务，一次只做一件事
3. 自助服务敏捷基础设施（Self-Service Agile Infrastructure）：用于快速、可重复和一致地提供应用环境和服务的平台
4. 面向API接口的通信（API-based Collaboration）：服务之间的交互基于接口，而不是本地方法调用
5. 抗脆弱性（Anti-Fragility）：系统能抵御高负载

简单来说就是：

模块化（Modularity）

可观测性（Observability）

可部署性（Deployability）

可测试性（Testability）

可处理性（Disposability）

可替代性（Replaceability）

2019年，VMware Tanzu 官网给出了云原生最新定义，以及云原生的架构原则：

• DevOps 集成持续交付
• Microservices 微服务
• Containers 容器化和容器编排技术
• Security 安全

云原生一直在被定义，也一直在被重定义。但是可以看出，云原生技术很有可能成为未来的发展方向。我们期待着……