我们可以从两个层面来理解“服务器”：
1、物理/虚拟基础设施层（The Machine）
2、应用服务实例层（The Process）
1. 物理/虚拟基础设施层（The Machine）
在这个层面上，“服务器”指的是运行微服务应用的操作系统环境，它是微服务赖以生存的“土壤”和“硬载体”，通常包括：
物理服务器（Bare Metal Servers）真实的、看得见摸得着的硬件机器。
虚拟机（Virtual Machines, VMs）通过虚拟化技术（如 VMware, Hyper-V）在一台物理服务器上划分出的多个隔离的操作系统环境。
容器（Containers）这是现代微服务架构中最主流的选择，容器（如 Docker）提供了一个更加轻量级、便携、资源隔离的应用运行环境，一个物理机或虚拟机上可以运行成百上千个容器。
在这一层，服务器的核心职责是：
提供计算（CPU）、内存（RAM）、存储（Disk）和网络（Network）资源。
运行容器引擎（如 Docker）或操作系统本身。
保证基础环境的安全和稳定。
2. 应用服务实例层（The Process）
这是微服务架构中最常被提及的“服务器”概念。“服务器”指的是一个正在运行的、监听某个网络端口的微服务应用实例。
它是一个进程每一个微服务（例如用户服务、订单服务、商品服务）在部署后，都会以一个独立的进程（或进程组）运行起来。
它监听网络端口这个进程会绑定到一个特定的端口（如用户服务在8080端口，订单服务在8081端口），等待并处理从外部发来的网络请求（通常是 HTTP/REST, gRPC 等）。
它是“服务”的提供者正因为它在网络上提供了一个可被调用的能力，所以它被称为“服务器”（Server），而调用它的客户端（可能是另一个微服务、前端应用或移动端）则被称为“客户端”（Client）。
关键点：
一个微服务 = 一个应用（例如一个独立的.jar 包、.exe 文件或容器镜像）。
一个应用可以运行多个实例（例如启动 3 个用户服务的进程），以实现负载均衡和高可用，每一个运行的实例，都可以被称为一个“服务器”。
让我们通过一个经典的电商微服务例子来串联这两个概念：
1、基础设施：你公司云平台上有 10 台虚拟机（第一层服务器）。
2、部署：你在这些虚拟机上使用 Kubernetes（一种容器编排系统）部署了你的微服务应用。
3、运行实例：
* Kubernetes 在 3 台虚拟机上分别启动了 1 个用户服务的容器实例（第二层服务器，监听端口 8080）。
* 在另外 3 台虚拟机上启动了 3 个订单服务的容器实例（第二层服务器，监听端口 8081）。
* 在剩下的虚拟机上启动了其他服务（商品服务、支付服务等）。
4、服务调用：
* 当用户在前端点击“我的订单”时，前端会调用API 网关（一个特殊的微服务）。
* API 网关作为客户端，向订单服务的某个实例（服务器） 发起请求。
订单服务在处理过程中，需要获取用户信息，于是它又作为客户端，向用户服务的某个实例（服务器） 发起请求。
| 层面 | 传统单体应用中的“服务器” | 微服务架构中的“服务器” |
| 核心含义 | 物理机/虚拟机，整个应用运行在一台或几台服务器上。 | 1. 基础设施（物理机/VM/容器） 2. 每个微服务的运行实例（进程） |
| 职责 | 托管整个庞大的应用程序，提供所有功能。 | 基础设施层：提供资源。 应用实例层：提供一个非常具体的业务能力（如“管理用户”）。 |
| 关系 | 1个应用 : N台服务器 | M个微服务 : X台物理服务器 : Y个服务实例（Y通常远大于X和M） |
| 弹性扩展 | 垂直扩展（Scale Up）：升级服务器硬件，或水平扩展整个应用，成本高。 | 精细度水平扩展（Scale Out）：只为某个繁忙的微服务（如订单服务）启动更多实例，快速、成本低。 |
当在微服务上下文中谈到“服务器”时，首先要明确指的是提供计算资源的基础硬件/虚拟机，还是指某个正在运行并提供网络服务的微服务进程实例，后者是现代微服务讨论中最常见的语境。
文章摘自：https://idc.huochengrm.cn/js/15932.html
评论