99-微服务项目的企业生产场景
一、微服务项目介绍
在之前我们了解了web项目的主流开发架构是前后端分离，前后端分离是为了将传统项目代码进行降耦从而利于开发和管理，而对于业务量庞大、开发人员数量较多 且 服务器集群环境、容器集群环境、监控环境等架构复杂的公司项目来说，前后端分离的设计已经不足以支撑规模化研发、高并发承载、故障隔离与快速迭代的核心诉求。
前后端分离应用即便做了前后端拆分，后端依旧是单一代码仓库、单一部署单元的模式，随着业务模块不断叠加，会出现代码冗余、编译打包耗时剧增、局部bug引发全局崩溃、扩容只能整体升级、多团队并行开发冲突频发等一系列致命问题，难以适配互联网行业快速试错、弹性扩容、高可用运维的发展需求。
而微服务架构正是破解这一困境的最优解，也是当前中大型企业Web项目的主流后端架构选型。
微服务是一种基于分布式架构的软件设计模式，核心是将原本庞大的单体后端应用，按照业务领域边界拆分为多个独立、自治、轻量化的小型服务单元。每个微服务只专注于单一业务职责，拥有独立的数据库、独立的代码仓库、独立的运行进程，服务之间通过轻量级的通信协议进行数据交互，彻底实现业务、代码、数据、部署的全方位解耦，让复杂项目从整体架构变为积木式的架构。
相较于前后端分离仅做视图层与业务层的解耦，微服务实现了后端业务层的深度拆分，遵循高内聚、低耦合、单一职责、独立迭代的设计原则，既保留了模块化开发的优势，又解决了分布式场景下的协作、运维、扩容难题。
通俗来说，前后端分离是将
前端、后端业务分离；微服务架构是将整个后端按业务主体拆分成多个后端
二、分布式架构
在代码的业务开发上会遇到以上种种问题，我们是通过微服务项目解决的。而在项目的服务器部署、流量承载、资源调度等底层运维层面，集中式的单体部署模式依旧存在难以突破的瓶颈，单纯的代码层级拆分无法解决硬件层面的性能短板、单点故障与弹性扩容难题。
传统集中式架构把所有业务计算、数据存储、请求处理压力都集中在单台或少数服务器上，不仅并发承载能力有硬性上限，还存在致命的单点风险——单个服务器宕机就会导致全业务瘫痪；后期扩容只能靠升级硬件配置，成本高、见效慢，也无法支撑微服务多实例、跨服务器的部署需求。
而分布式架构正是破解底层运维瓶颈的核心方案，也是微服务架构能够落地生效的底层基础支撑，是中大型项目实现高可用、高并发的必备底层架构。
分布式架构是一种多节点协同的集群部署模式，核心是将系统的算力、存储、服务分散部署到多台独立服务器节点上，各节点通过网络通信实现数据互通、任务协同，对外呈现为一套完整的系统。它不直接参与业务逻辑拆分，而是为微服务提供跨节点部署、冗余备份、负载分担的底层环境，让每个微服务都能以多实例形态分散运行。
相较于集中式架构的资源集中、单点管控，分布式架构遵循高可用、弹性扩容、故障隔离、最终一致性的核心原则，既能通过多节点分流提升并发承载力，又能靠节点冗余规避全局故障，还能按需新增服务器实现横向扩容，完美适配微服务的部署与运维诉求。
通俗来说，集中式架构是一台服务器扛下所有业务负载；分布式架构是多台服务器分工协作、共同支撑全业务运转
三、k8s集群
微服务项目依托分布式架构实现了多节点分散部署，但随着服务实例数量激增、服务器节点增多，手动运维模式变得极度繁琐，分布式集群的管控难题也随之凸显，单纯的分布式架构无法实现自动化、智能化的集群管理。
人工部署微服务实例、手动调控服务器资源、故障后手动重启修复、按需扩容耗时耗力，不仅容易出现操作失误，还无法快速响应流量波动，甚至会拖慢微服务的迭代效率，让分布式架构的优势难以完全发挥。
而Kubernetes集群，简称K8s正是管理分布式微服务的核心编排工具，也是云原生项目的标配运维平台，专门解决分布式集群的自动化管控痛点。
k8s集群是开源的容器编排管理平台，核心是将多台服务器整合为统一的资源池，自动完成微服务容器的部署、调度、扩容、自愈等全生命周期管理，屏蔽底层服务器差异，让分布式集群运维更高效。
它具备自动故障自愈、弹性扩缩容、滚动更新、负载均衡、资源精细化分配等核心能力，既能降低分布式集群的运维成本，又能保障微服务稳定运行，彻底释放分布式架构的价值。
通俗来说，分布式架构是多台服务器协同干活的场地；k8s集群就是统筹管理所有服务器、调度所有微服务的大管家
总之，以上三种中大型企业常见设计和架构都是为了处理日益增长的业务量和避免各种突发状况的：
微服务是为了实现业务解耦、独立迭代，避免单体臃肿、全局故障；
分布式是为了实现高可用、高并发，避免单点瘫痪、性能瓶颈；
K8s 是为了实现自动运维、弹性调度，避免集群混乱、运维低效。
四、具体业务经验
1.发布流程
在某大型企业中，某个业务项为21个微服务的业务设计项目，其生产环境为：前端是服务器nginx代理，后端集群为k8s集群的容器化架构
生产发布流程为：
各开发组长将代码合并到需要发布的微服务仓库，向项目经理发送邮件等待同意发布的回复
配置运维填写运维工单，包括：待上线需求号、需求内容、项目经理回复邮件等，发布时间为当天 20:30
前端开发提供已经构建并压缩好的前端包
dist.zip，若有sql脚本则开发提前提供。配置运维将其均上传到对应服务器，对sql脚本编写日期明明的sh脚本，部分内容为mysql -uAPP_USER -pAPPUSER_PASSWD -f database01 < database01-开发人员名-20260318.sql到当天20：30时，登录kubectl服务器，暂时关闭gateway节点，关闭流量接收
登录数据库服务器，使用
nohup sh 0318.sh > 0318.log &命令执行sql脚本，执行成功反馈开发开发提供需发布的微服务名，前往Jenkins主页，先发布mapper，然后依次发布微服务对应Jenkins任务，发布成功反馈开发
登录前端服务器，解压新前端压缩包覆盖dist目录，并修改权限
chmod -R 755 dist/等待spring boot admin网页所有服务节点已正常上线，登录kubectl服务器将之前下线的流量节点重新上线 至此，一次正常发布完成
2.自动化发布的设计与配置
在自动化发布流程中，具体配置为：
每个微服务有对应Jenkinsfile，其中
配置了APP-NAME为该微服务名，VERSION为当前时间戳Jenkins拉取对应微服务仓库后，会本地maven构建成jar包后生成自定义镜像，镜像名为APP-NAME的值，标签为当前时间，如 ${APPNAME}: ${VERSION}，然后将该镜像上传到Harbor仓库
每个微服务也有k8s的资源清单yml文件，其中配置了需要拉取的容器名为
Harbor仓库信息/ ${APPNAME}:latest在镜像上传完成后，因为该代码仓库中的 yml文件已经拉取到本地，使用sed命令将 本地的 该微服务k8s资源清单yml文件中
latest改为${VERSION}的值Jenkins服务器就是kubectl的部署服务器，所以Jenkinsfile中最后步骤就是通过
kubectl apply命令重新应用修改后的资源清单yml文件该命令执行后k8s会自动拉取最新上传到Harbor的新镜像并根据后续配置应用到对应节点
至此，单个微服务发布完成