nginx迁移到apache(nginx迁移到kong)

nginx迁移到apache

1、二者最核心的区别在于apache是同步多进程模型，一个连接对应一个进程；nginx是异步的，多个连接（万级别）可以对应一个进程 。nginx处理静态文件好,耗费内存少.但无疑apache仍然是目前的主流,有很多丰富的特性.所以还需要搭配着来.当然如果能确定nginx就适合需求,那么使用nginx会是更经济的方式。

2、nginx的负载能力比apache高很多。最新的服务器也改用nginx了。而且nginx改完配置能-t测试一下配置有没 有问题。

3、apache重启的时候发现配置出错了，会很崩溃，改的时候都会非常小心翼翼现在看有好多集群站，前端nginx抗并发，后端apache集群， 配合的也不错。

4、nginx处理动态请求是鸡肋，一般动态请求要apache去做，nginx只适合静态和反向。

5、从经验来看，nginx是很不错的前端服务器，负载性能很好，nginx，用webbench模拟10000个静态文件请求毫不吃力。 apache对php等语言的支持很好，此外apache有强大的支持网络，发展时间相对nginx更久，bug少但是apache有先天不支持多核心处理负载鸡肋的缺点，建议使用nginx做前端，后端用apache。大型网站建议用nginx自代的集群功能。

6、大部分情况下nginx都优于APACHE，比如说静态文件处理、PHP-CGI的支持、反向代理功能、前端 Cache、维持连接等等。在Apache+PHP（prefork）模式下，如果PHP处理慢或者前端压力很大的情况下，很容易出现Apache进程数 飙升，从而拒绝服务的现象。

7、Apache在处理动态有优势，Nginx并发性比较好，CPU内存占用低，如果rewrite频繁，那还是Apache吧！

8、一般来说，需要性能的web 服务，用nginx 。如果不需要性能只求稳定，那就apache 吧。

nginx迁移到kong

在我们讲的微服务架构下的API网关，一般指的是前三类使用场景。即，主要是把企业内部的API能力，暴露给其他应用或合作伙伴使用。网关层作为客户端与服务端的一层挡板，主要起到了三大类作用：

第一类作用是隔离作用，作为企业系统边界，隔离外网系统与内网系统。

第二类作用是解耦作用，通过解耦，使得微服务系统的各方能够独立、自由、高效、灵活地调整，而不用担心给其他方面带来影响。

第三类作用是脚手架作用，提供了一个地点，方便通过扩展机制对请求进行一系列加工和处理。

二：网关的好处

（1）网关层对外部和内部进行了隔离，保障了后台服务的安全性。

（2）对外访问控制由网络层面转换成了运维层面，减少变更的流程和错误成本

（3） 减少客户端与服务的耦合，服务可以独立发展。通过网关层来做映射。

（4）通过网关层聚合，减少外部访问的频次，提升访问效率。

（5）节约后端服务开发成本，减少上线风险。

（6）为服务熔断，灰度发布，线上测试提供简单方案。

（7）便于扩展。

三：API网关需要考虑的因素

1、安全性问题

企业在把服务暴露给外部使用时，首先要确保服务使用的安全，防止外部的恶意访问对公司业务的影响，特别是涉及交易方面的服务，更是要全面考虑安全性。为确保安全，需要考虑在通讯链路的建立、通讯数据的加密、数据的完整性、不可抵赖性等方面。

2、性能问题

作为企业API的入口，所有的请求都会经过API网关进行转发，可想而知，对API网关的访问压力是巨大的，有的网站甚至达到每分钟上千万的访问量。特别是在一些互联网企业，海量的移动终端每时每刻都需要与后端的服务进行交互，如果不能保证网关的高性能，企业在网关层需要投入大量的设备和成本。曾在一家互联网公司发生过，由于网关性能问题，网关的机器数量，需要与后台服务器的数量保持同步增长。这种情况显然是企业服务忍受的。

四:API网关的功能

企业级API网关应该提供下列的功能：

API网关功能

1.服务路由：外部服务访问接口映射到对应的内部服务访问接口。

2.认证授权：提供对用户身份的认证以及用户权限验证，包括用户身份的合法性、针对用户角色的访问授权验证、针对用户的访问授权验证、IP 黑名单验证等。

3.超时处理：当 API 网关调用的内部服务响应时间超过了在自主开发的 API 网关后台管理子系统中所设置的允许最长的超时时间时，API 网关会立即停止调用，并返回相关消息给你。

4.限流控制：当你通过 API 网关调用内部服务的频率达到在某个阈值时，API 网关会立即做断开链路处理。过了时间后，链路会自动闭合回去。

5.熔断处理：熔断处理对避免无谓的资源消耗特别有用，当通过 API 网关调用的内部服务出现异常的频率达到某个阈值时，那么 API 网关会做临时熔断处理即临时断开链路，暂时停止你对那个内部服务的调用。临时熔断后，过了一段时间后，链路会自动闭合回去。

6.日志信息记录：会记录客户 IP、客户请求参数、返回结果、异常信息等信息。

7.负载均衡： 提供API接口的负载均衡，能够处理API接口的高并发访问，防止服务雪崩。

8.安全防护：提供严格的认证服务，支持算法签名，用户使用 API 网关提供的密钥进行认证，没有被授予密钥的客户端无法调用业务 API接口，经过认证授权的请求才能到达后端应用服务。同时SSL 加密。

9.灰度发布：支持API接口线上灰度部署，减少应用版本切换风险。

nginx转发到另一台服务器

1.轮训模式

2.指定权重

3.IP绑定

nginx转发到nginx

在开发静态页面时，类似Vue的应用，我们常会调用一些接口，这些接口极可能是跨域，然后浏览器就会报cross-origin问题不给调。

最简单的解决方法，就是把浏览器设为忽略安全问题，设置--disable-web-security。不过这种方式开发PC页面到还好，如果是移动端页面就不行了。

解决办法

使用Nginx转发请求。把跨域的接口写成调本域的接口，然后将这些接口转发到真正的请求地址。

其实不仅是在开发调试时候能这么干，在生产环境也能这么玩。利用Nginx转发请求之后，就能够让所要部署的静态页面不需要放在跟请求接口同域的地方。

nginx迁移到另一台服务器

Nginx 通过配置监听 HTTP 请求，并对其进行转发到 HTTPS 请求来实现将 HTTP 请求转换为 HTTPS 请求。

这个转发过程通常是通过在 Nginx 服务器上配置一个重定向规则来实现的。

该规则告诉 Nginx 将所有通过 HTTP 协议发送的请求重定向到相同的 URL，但使用 HTTPS 协议代替 HTTP。因此，用户在访问网站时将自动使用安全的 HTTPS 协议，而不是明文的 HTTP 协议。

怎么迁移nginx

在同一端口上实现 HTTP 重定向到 HTTPS 是完全可行的。以下是基本思路：

1. 配置 HTTPS 服务器：首先应该正确地部署 HTTPS 服务器。可以使用自签名证书或更具信任的证书，具体的部署可以参考证书供应商的文档或指南。

2. 修改服务器配置文件：如果使用 Apache 或 Nginx 等流行的网络服务器，请编辑您的服务器配置文件。找到虚拟主机配置部分，在 HTTP 端口上添加以下行：

```

RewriteEngine On

RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R=301,L]

```

如上所述，RewriteRule 命令的正则表达式捕获匹配 HTTP 请求中的所有路径并将其与 HTTPS 移动到重写请求。该 [R=301] 参数表示使用 301 永久重定向。

3. 重新启动服务器：编辑完配置文件后，需要重新启动服务器使配置生效并将 HTTP 交通重定向到 HTTPS。

这样一来，您的网站现在将用 HTTPS 加密连接。多亏了匀地技术人员的辛勤工作和分秒必争的部署，你的网站现在更加安全了！

一、. 重定向(Redirect)就是通过各种方法将各种网络请求重新定个方向转到其它位置（如：网页重定向、域名的重定向、路由选择的变化也是对数据报文经由路径的一种重定向）。

二、

1.网站调整（如改变网页 目录结构）；

2.网页被移到一个新地址；

3.网页扩展名改变(如应用需要把.php改成.Html或.shtml)。

这种情况下，如果不做重定向，则用户收藏夹或搜索引擎数据库中旧地址只能让访问客户得到一个404 页面错误信息，访问流量白白丧失；再者某些注册了多个域名的网站，也需要通过重定向让访问

这些域名的用户自动跳转到主 站点等。

三、常用的重定向方式有：

301 redirect-----永久性转移

302 redirect-----暂时性转移

四、Apache服务器实现301重定向

相比较来说，Apache实现起来要比IIS简单多了。在Apache中，有个很重要的文件.htaccess，通过对它的设置，可以实现很多强大的功能， 301重定向只是其中之一。