架构简介
现在主流的项目运行环境有四类环境
- 物理机环境
- 虚拟化云主机环境
- 容器化环境
- 函数计算环境
如何选择呢？主要看项目首要且最核心的需求。
物理机环境
侧重点主要是高性能, 其次是兼容性；
性能:
分布式架构, 因为有跨节点通信和同步的开销, 所以性能绝对没有单体应用在单节点上运行高;
例如对延迟要求极高, 或性能要求极高的场景, 还是得直接在物理机上跑好一些。
兼容性:
对于老旧应用, 以及需要专有硬件外设的场景; 物理机如果跑不起来, 其它环境就更别想了；
例如需要 USB 外设, 某某加密运算卡等场景。
虚拟化环境
侧重点主要是隔离，其次是资源利用率
隔离:
当一个公司20个部门共享10台物理机的时候, 怎么分配合适？
向其它部门借用几台主机后，如何尽快纳管, 后续如何归还？
我部门部署的应用运行时会不会影响到别的部门;
虚拟化的隔离性，可以有效解决这些问题;
利用率:
纯物理机的场景, 很多非核心应用主机，常年CPU使用率不足 1%-5%，太浪费了；
多部门复用一台机器, 只要CPU使用率没有饱和都可以继续分配；有效提升资源利用率；
容器化环境
侧重点主要是调度
误区: 容器化的核心并不是提升资源使用率；
虚拟化场景下已经能做到有效利用 CPU 或内存资源 80% 了，容器化后最多加到90%，如果只是为了提升这一点通常情况下其实意义不大。
容器化的核心是调度, 一个应用实例能最快速度的部署, 最快速度的扩容和缩容、迁移、下线等。
传统模式下，如果某个线上运行了50份实例的应用需要更新，并且扩容到1000份；需要很大的运维支持能力;
如新环境准备, 代码更新、编译打包、上传更新、断流、重启、恢复流量、更新配置中心、更新网关等等一长串步骤。
现在容器化后，其实可以理解为使用业内最佳实践标准化了发布更新流程;
函数计算
没有实际接触过，但有一些了解，我非常看好某些场景下的应用；
- 某些低频服务，一天可能就会被使用1-2次，却要单独占个机器或者运行个容器，造成了资源浪费，大家更希望在必要时候才运行。
- 某些高频服务, 波动特别大，需要以极快速度扩容并且缩容，使用容器化也不能达到极致部署速度。
- 某些逻辑非常简单的轻应用, 根本不需要自己去维护主机或容器环境。
例如: 函数+云数据库(rds)+对象存储(oss), 自己根本不需要维护主机环境。
选型考虑
| 环境 | 首要需求 |
|---|---|
| 物理机 | 极致性能、兼容性、稳定性需求 |
| 虚拟机 | 强隔离+资源利用率 需求 |
| 容器 | 快速业务变更，标准化部署模式 |
| 函数计算 | 低频, 无基础设施运维 |
k8s 环境的优势
不同的人可能有不同的视角，作为运维人员，我更看重的是其标准化的能力。
早期系统运维场景中
有很多日常事务，如日志怎么管理, 应用程序放那个路径，数据文件放什么路径，启停脚本在哪，服务注册与注销，负载均衡配置变更，资产管理等等一大堆事情。
关键是这些事情每个公司的管理方式都是不一样的，甚至公司内每个项目组都是不一样的;
造成这个项目极为依赖个别资深老员工的经验来进行维护。
而 k8s 主推的是用一套"业内最佳实践"来整合这些日常运维事件；
例如新员工入职的第一天，即便没有看到任何文档，也能快速找到线上全部服务的配置，日志，运行情况，能立即对服务进行扩容、上线、下线。
这要是在以前，一两周时间可能也不够熟悉环境的。
k8s 部署方式
- 如果是部门专用的物理机环境, 则直接在物理机上部署k8s环境。
- 如果是公司的共享物理机资源池, 则先划分虚拟机分配给各部门后, 各部门再独立部署k8s环境;
其它说明
虽然k8s也可以通过命名空间进行租户隔离, 但隔离程度还是不高；
举个例子: 两个部门都部署了一个程序, 需要相同的 hostPath 路径, 此时就会冲突；