项目上线流程-CSDN博客

本文链接：https://blog.csdn.net/qq_53207874/article/details/136906731

项目上线流程

大致流程
问题

大致流程

准备环境：确保目标服务器环境已经准备就绪，包括操作系统、数据库、依赖项等。
代码审查：进行代码审查以确保代码质量和安全性。
打包代码：将项目代码打包成部署包，可以是压缩文件或者镜像。
测试部署：在预生产环境或者 staging 环境中进行部署测试，确保部署过程顺利且项目正常运行。
数据库迁移：如果有数据库变更，需要进行数据库迁移，并确保数据一致性。
静态资源处理：处理静态资源（如图片、样式表等）的部署和缓存设置。
配置管理：检查和更新配置文件，确保部署到目标环境后项目能够正确运行。
部署代码：将打包好的代码上传至目标服务器，解压并配置相关参数。
启动服务：启动项目服务，可以通过命令行或者自动化工具进行操作。
监控和日志：配置监控系统，确保项目在上线后能够及时发现和解决问题；同时设置日志记录，方便排查问题。
全面测试：进行全面的功能测试和性能测试，确保项目在上线后能够正常运行，并承受一定的访问量。
上线发布：在确认项目没有问题后，可以将项目正式上线，让用户访问新版本的项目。
回滚计划：准备好回滚计划，以应对意外情况，确保可以迅速回退到之前的稳定版本。

1.代码打包

在命令行工具中运行（需进入项目路径）：

npm run build

2.上线部署

购买服务器

3.用户访问

将项目部署到云服务提供商（如Heroku、AWS、Azure等）或者自己的服务器上后，用户可以通过以下方式访问你的项目：

通过公网地址：如果你的项目部署在云服务提供商上，通常会分配一个公网地址（例如IP地址或域名），用户可以直接通过这个地址来访问你的项目。

域名指向：如果你有自己的域名，可以将域名指向部署项目的服务器地址，这样用户就可以通过域名来访问你的项目。

端口访问：如果你的项目使用了特定的端口进行访问，用户可以通过服务器地址加上端口号来访问你的项目（例如http://your_server_ip:port）。

负载均衡器：如果你的项目需要高可用性和负载均衡，可以通过负载均衡器来管理用户的访问请求，将请求分发到多个实例上。

DNS解析：如果你的项目需要支持多地域访问，可以通过DNS解析来将用户请求导向不同地区的服务器。

————————————————————————————————————————————

问题

1.有了nignx为什么还要有网关

尽管Nginx等反向代理服务器可以用于负载均衡和路由请求到不同的微服务实例，但在微服务架构中引入网关仍然是有必要的，主要原因包括以下几点：

统一的入口：网关提供了一个统一的入口，客户端只需与网关进行通信，而无需直接与各个微服务通信。这样有利于简化客户端与微服务之间的交互方式，降低客户端复杂度。
安全性：网关可以作为安全壁垒，用于认证、授权、加密等安全控制。通过网关可以实现统一的安全策略，对请求进行过滤、鉴权和监控，保护后端微服务免受恶意攻击。
路由和转发：网关可以实现请求的路由和转发，根据请求的不同路径或参数将请求分发给对应的微服务。这样可以更灵活地管理微服务之间的通信，实现请求的动态路由。
协议转换：网关可以处理不同协议间的转换，比如将HTTP请求转换为gRPC请求，从而使得前端应用可以使用不同的通信协议与后端微服务进行通信。
监控和日志：网关可以集中管理请求的监控和日志记录，方便进行故障排查、性能优化和统计分析。通过网关可以收集整个系统的请求数据，帮助运维人员了解系统的运行情况。

2.Nginx的反向代理

通过反向代理，Nginx可以接收客户端的请求，并将这些请求转发给后端服务器，然后将后端服务器的响应返回给客户端，起到隐藏后端服务器、负载均衡和提高安全性等作用。

3.单体应用和微服务

是两种不同的软件架构模式，它们有以下区别：
单体应用：
优势：

简单易开发：单体应用通常开发、部署和维护相对简单，适合小型项目或初期阶段的产品。
性能优化：由于单体应用运行在同一个进程中，可以直接共享内存和数据，性能优化相对容易。
一体化管理：单体应用只需一个部署包，便于管理和监控。
劣势：
可扩展性差：随着业务增长，单体应用的代码规模会不断增大，难以扩展和维护。
耦合度高：单体应用内各个功能模块耦合度高，一个模块的变更可能影响到其他模块。
部署风险大：因为单体应用整体部署，一次部署出错可能导致整个应用不可用。

微服务架构：
优势：

灵活扩展：微服务架构将应用拆分成多个小的服务，每个服务独立部署和扩展，更加灵活。
技术多样性：不同的微服务可以使用不同的技术栈，根据实际需求选择最适合的工具。
容错性强：某个服务出现故障时，不会影响整个系统的运行，提高系统的稳定性。
劣势：
复杂度高：微服务架构涉及到多个独立部署的服务，需要额外的管理和监控，增加了系统复杂度。
分布式系统问题：微服务架构引入了分布式系统的问题，如网络延迟、服务发现、数据一致性等。
部署依赖：微服务架构中各个服务之间存在依赖关系，服务之间的通信和版本管理需要谨慎处理。

区别总结：

规模：单体应用适合小型应用，而微服务适合大型、复杂的系统。
部署：单体应用部署简单，微服务部署相对复杂。
耦合性：单体应用耦合度高，微服务耦合度低。
维护：单体应用维护相对简单，微服务需要更多的治理和监控机制。

4.微服务用户可以直接访问核心功能ip吗

不可以，通过微服务网关来访问核心功能，这样可以实现统一的入口、安全认证和请求路由
可以把微服务网关视为一个在 Web 层之上的组件，它扮演了路由、代理和管理请求的角色，并通过与核心功能的微服务进行通讯来实现对核心功能的访问。通过微服务网关，系统可以更好地管理和控制请求流量，实现统一的访问入口，同时也能够提供额外的功能，如认证、授权、监控、日志记录等，从而增强系统的整体可用性和安全性。

5.基于 Feign 的远程调用

Feign 是一个声明式的 http 客户端，它可以帮助我们优雅地发送 http 请求。
启动类上添加注解 @EnableFeignClients，开启自动装配功能
编写 user 客户端做接口声明，我们就可以通过调用该接口里面的方法，来向 user 服务端（userserver）发起 http 请求@FeignClient(“userserver”)
使用客户端，直接调用 UserClient 中的方法完成远程调用

6.网关（Gateway）

通过 Feign 就可以向指定的微服务发起 http 请求，完成远程调用。但是我的微服务好像谁来都可以访问，这样会不会不安全？那是肯定的。
实际生产中，有很多的业务模块只有我们内部的人才能用，不是谁都能访问，这时候我们就需要对用户的身份进行验证，而这个验证的工作就是网关（Gateway）来完成的。
一切请求一定要先到网关，再到微服务，
网关的技术实现：
①gataway（新技术，响应式编程，非阻塞式，性能好，吞吐能力强）
② zuul（较早的技术，基于 Servlet，阻塞式，性能差）
整体流程：
用户发起 http://localhost:10010/user/2 请求，接着该请求进入网关，而网关是无法处理具体业务的，所以它会基于路由规则去做判断，然后代理到具体的服务上去处理业务。
上面步骤中我们定义了两个路由规则，以 user 开头的路径将会被代理到 userserver 服务，接着网关会拿着服务名（userserver）去找 Nacos 拉取服务列表，然后做一个负载均衡，发送请求 http://localhost:10010/user/2。