现代应用程序体系结构的核心是HTTP API。 HTTP使应用程序能够快速构建并轻松维护。无论应用程序的规模如何，HTTP API都提供了一个通用接口，从单用途微服务到无所不包的整体。通过使用HTTP，支持超大规模Internet属性的Web应用程序交付的进步也可用于提供可靠和高性能的API交付。
有关API网关对微服务应用程序重要性的精彩介绍，请参阅我们博客上的构建微服务：使用API网关。
作为领先的高性能，轻量级反向代理和负载均衡器，NGINX Plus具有处理API流量所需的高级HTTP处理功能。这使得NGINX Plus成为构建API网关的理想平台。在这篇博文中，我们描述了许多常见的API网关用例，并展示了如何配置NGINX Plus以便以高效，可扩展且易于维护的方式处理它们。我们描述了一个完整的配置，它可以构成生产部署的基础。
注意：除非另有说明，否则本文中的所有信息均适用于NGINX Plus和NGINX开源。
API网关的主要功能是为多个API提供单一，一致的入口点，无论它们在后端如何实现或部署。并非所有API都是微服务应用程序。我们的API网关需要管理现有的API，单块和正在部分过渡到微服务的应用程序。
在这篇博文中，我们引用了一个假设的库存管理API，即“仓库API”。我们使用示例配置代码来说明不同的用例。 Warehouse API是一个RESTful API，它使用JSON请求并生成JSON响应。但是，当部署为API网关时，使用JSON不是NGINX Plus的限制或要求NGINX Plus与API本身使用的架构风格和数据格式无关。
Warehouse API实现为离散微服务的集合，并作为单个API发布。库存和定价资源作为单独的服务实施，并部署到不同的后端。所以API的路径结构是：
例如，要查询当前仓库库存，客户端应用程序会向/ api / warehouse / inventory发出HTTP GET请求。
使用NGINX Plus作为API网关的一个优点是，它可以执行该角色，同时充当现有HTTP流量的反向代理，负载平衡器和Web服务器。如果NGINX Plus已经是应用程序交付堆栈的一部分，那么通常不需要部署单独的API网关。但是，API网关所期望的某些默认行为与基于浏览器的流量的预期不同。出于这个原因，我们将API网关配置与基于浏览器的流量的任何现有（或未来）配置分开。
为实现这种分离，我们创建了一个支持多用途NGINX Plus实例的配置布局，并为通过CI / CD管道自动配置部署提供了便利的结构。 / etc / nginx下的结果目录结构如下所示。
所有API网关配置的目录和文件名都以api_为前缀。这些文件和目录中的每一个都启用API网关的不同特性和功能，并在下面详细说明。
所有NGINX配置都以主配置文件nginx.conf开头。要读入API网关配置，我们在nginx.conf的http块中添加一个指令，该指令引用包含网关配置的文件api_gateway.conf（下面的第28行）。请注意，默认的nginx.conf文件使用include伪指令从conf.d子目录中引入基于浏览器的HTTP配置（第29行）。本博文广泛使用include指令来提高可读性并实现配置某些部分的自动化。
api_gateway.conf文件定义了将NGINX Plus公开为客户端的API网关的虚拟服务器。此配置公开API网关在单个入口点https://api.example.com/（第13行）发布的所有API，受第16到21行配置的TLS保护。请注意，此配置纯粹是HTTPS - 没有明文HTTP侦听器。我们希望API客户端知道正确的入口点并默认进行HTTPS连接。
此配置是静态的 - 各个API及其后端服务的详细信息在第24行的include伪指令引用的文件中指定。第27到30行处理日志记录默认值和错误处理，并在响应中讨论错误部分如下。
一些API可以在单个后端实现，但是出于弹性或负载平衡的原因，我们通常期望存在多个API。使用微服务API，我们为每个服务定义单独的后端它们一起作为完整的API。在这里，我们的Warehouse API被部署为两个独立的服务，每个服务都有多个后端。
API网关发布的所有API的所有后端API服务都在api_backends.conf中定义。这里我们在每个块中使用多个IP地址 - 端口对来指示API代码的部署位置，但也可以使用主机名。 NGINX Plus订户还可以利用动态DNS负载平衡，自动将新后端添加到运行时配置中。
配置的这一部分首先定义Warehouse API的有效URI，然后定义用于处理对Warehouse API的请求的公共策略。
Warehouse API定义了许多块。 NGINX Plus具有高效灵活的系统，可将请求URI与配置的一部分进行匹配。通常，请求由最具体的路径前缀匹配，并且位置指令的顺序并不重要。这里，在第3行和第8行，我们定义了两个路径前缀。在每种情况下，$ upstream变量都设置为上游块的名称，该上游块分别代表库存和定价服务的后端API服务。
此配置的目标是将API定义与管理API交付方式的策略分开。为此，我们最小化了API定义部分中显示的配置。在为每个位置确定适当的上游组之后，我们停止处理并使用指令来查找API的策略（第10行）。
使用重写指令将处理移至API策略部分
重写指令的结果是NGINX Plus搜索匹配以/ _warehouse开头的URI的位置块。第15行的位置块使用=修饰符执行完全匹配，从而加快处理速度。
在这个阶段，我们的政策部分非常简单。位置块本身标记为第16行，这意味着客户端无法直接向它发出请求。重新定义$ api_name变量以匹配API的名称，以便它在日志文件中正确显示。最后，请求被代理到API定义部分中指定的上游组，使用$ request_uri变量 - 其中包含原始请求URI，未经修改。
API定义有两种方法 - 广泛而精确。每种API最合适的方法取决于API的安全要求以及后端服务是否需要处理无效的URI。
在warehouse_api_simple.conf中，我们通过在第3行和第8行定义URI前缀来使用Warehouse API的广泛方法。这意味着以任一前缀开头的任何URI都代理到相应的后端服务。使用基于前缀的位置匹配，对以下URI的API请求都是有效的：
如果唯一的考虑是将每个请求代理到正确的后端服务，则广泛的方法提供最快的处理和最紧凑的配置。另一方面，精确的方法使API网关能够通过显式定义每个可用API资源的URI路径来理解API的完整URI空间。采用精确的方法，Warehouse API的以下配置使用精确匹配（=）和正则表达式（〜）的组合来定义每个URI。
此配置更详细，但更准确地描述了后端服务实现的资源。这具有保护后端服务免于格式错误的客户端请求的优点，代价是正常表达式匹配的一些小额外开销。有了这个配置，NGINX Plus接受一些URI并拒绝其他URI无效：
使用精确的API定义，现有的API文档格式可以驱动API网关的配置。可以从OpenAPI规范（以前称为Swagger）自动化NGINX Plus API定义。此博客文章的Gists中提供了用于此目的的示例脚本。
随着API的发展，有时会发生需要更新客户端的重大更改。一个这样的示例是重命名或移动API资源。与Web浏览器不同，API网关无法向其客户端发送命名新位置的重定向（代码301）。幸运的是，当修改API客户端不切实际时，我们可以动态地重写客户端请求。
在下面的示例中，我们可以在第3行看到定价服务以前是作为库存服务的一部分实现的：rewrite指令将对旧定价资源的请求转换为新的定价服务。
动态重写URI意味着当我们最终在第26行代理请求时，我们不能再使用$ request_uri变量（正如我们在warehouse_api_simple.conf的第21行所做的那样）。这意味着我们需要在API定义部分的第9行和第14行使用稍微不同的重写指令，以便在处理切换到策略部分时保留URI。
HTTP API和基于浏览器的流量之间的主要区别之一是如何将错误传达给客户端。当NGINX Plus作为API网关部署时，我们将其配置为以最适合API客户端的方式返回错误。
顶级API网关配置包括一个定义如何处理错误响应的部分。
第27行的指令指定当请求与任何API定义都不匹配时，NGINX Plus会返回错误而不是默认错误。此（可选）行为要求API客户端仅向API文档中包含的有效URI发出请求，并防止未经授权的客户端发现通过API网关发布的API的URI结构。
第28行指的是后端服务本身产生的错误。未处理的异常可能包含我们不希望发送到客户端的堆栈跟踪或其他敏感数据。此配置通过向客户端发送标准化错误来进一步提供保护。
完整的错误响应列表在第29行的include伪指令引用的单独配置文件中定义，其前几行如下所示。如果首选不同的错误格式，并且通过更改第30行上的default_type值以匹配，则可以修改此文件。您还可以在每个API的策略部分中使用单独的include指令来定义一组覆盖默认值的错误响应。
有了这种配置，客户端对无效URI的请求就会收到以下响应。
在没有某种形式的身份验证的情况下发布API以保护它们是不常见的。 NGINX Plus提供了几种保护API和验证API客户端的方法。有关基于IP地址的访问控制列表（ACL），数字证书身份验证和HTTP基本身份验证的信息，请参阅文档。在这里，我们专注于API特定的身份验证方法。
API密钥身份验证
API密钥是客户端和API网关已知的共享密钥。它们本质上是作为长期凭证发布给API客户端的长而复杂的密码。创建API密钥很简单 - 只需编码一个随机数，如本例所示。
在顶级API网关配置文件api_gateway.conf的第6行，我们包含一个名为api_keys.conf的文件，其中包含每个API客户端的API密钥，由客户端名称或其他描述标识。
API密钥在块中定义。 map指令有两个参数。第一个定义了API密钥的位置，在本例中是在$ http_apikey变量中捕获的客户端请求的apikey HTTP头。第二个参数创建一个新变量（$ api_client_name）并将其设置为第一个参数与键匹配的行上的第二个参数的值。
例如，当客户端提供API密钥7B5zIqmRGXmrJTFmKa99vcit时，$ api_client_name变量设置为client_one。此变量可用于检查经过身份验证的客户端，并包含在日志条目中以进行更详细的审核。
地图块的格式很简单，易于集成到自动化工作流程中，从现有的凭证存储生成api_keys.conf文件。 API密钥身份验证由每个API的策略部分强制执行。
客户端应在apikey HTTP头中显示其API密钥。如果此标头丢失或为空（第20行），我们发送401响应以告知客户端需要进行身份验证。第23行处理API键与地图块中的任何键都不匹配的情况 - 在这种情况下，api_keys.conf第2行的默认参数将$ api_client_name设置为空字符串 - 我们发送403响应告诉身份验证失败的客户端。
有了这个配置，Warehouse API现在可以实现API密钥身份验证。
JWT身份验证
JSON Web令牌（JWT）越来越多地用于API身份验证。原生JWT支持是NGINX Plus独有的，可以在我们的博客上验证JWT，如使用JWT和NGINX Plus验证API客户端中所述。
本系列的第一篇博客详细介绍了将NGINX Plus部署为API网关的完整解决方案。可以从我们的GitHub Gist仓库查看和下载此博客中讨论的完整文件集。本系列的下一篇博客将探讨更高级的用例，以保护后端服务免受恶意或行为不端的客户端的攻击。
原文：https://dzone.com/articles/deploying-nginx-plus-as-an-api-gateway-part-1-ngin
本文：http://pub.intelligentx.net/deploying-nginx-plus-api-gateway-part-1-nginx
讨论：请加入知识星球或者小红圈【首席架构师圈】
通常“治理”的意思是构建方案，并且迫使人们通过努力达到组织的目标。SOA治理指导开发者开发可重用的服务，以及随着时间推移，服务应该怎么被设计和开发。治理建立了服务提供者和消费者之间对于服务的协定，告诉消费者能从服务提供获取到什么样的支持。
SOA中有两种常见的治理：
那么微服务中的治理是什么意思呢？
在微服务架构中，不同的微服务之间相互独立，并且基于不同的平台和技术。因此，没有必要为服务的设计和开发定义一个通用的标准。
总结微服务的治理去中心化如下：
微服务架构下，有大量的微服务需要处理。由于微服务的快速和敏捷研发，他们的位置可能会动态变化。因此在运行时需要能够发现服务所在的位置，服务发现可以解决这个问题。
注册中心有微服务的实例和位置信息，微服务在启动时向注册中心注册自己的信息，关闭时注销。其它使用者能够通过注册中心找到可用的微服务和相关信息。
为了能找到可用的服务和他们的位置信息，需要服务发现机制。有两种发现机制，客户端发现和服务端发现。
客户端发现 - 客户端或者API网关通过查询服务注册中心或者服务的位置信息。
客户端/API网关必须调用服务注册中心组件，实现服务发现的逻辑。
服务端发现 - 客户端/API网关把请求发送到已知位置信息的组件（比如负载均衡器）。组件去访问注册中心，找到微服务的位置信息。
类似Kubernetes（ http://kubernetes.io/v1.1/docs/user-guide/services.html ）这种微服务部署解决方案，就提供了服务器端的自动发现机制。
微服务的部署方式也特别重要，以下是关键：
Docker（一个运行在linux上并且开源的应用，能够协助开发和运维把应用运行在容器中）能够快速部署微服务，包括关键几点：
相对于传统的虚拟机模式，利用docker容器，构建、发布、启动微服务将会变得十分快捷。
通过Kubernetes能够进一步扩展Docker的能力，能够从单个linux主机扩展到linux集群，支持多主机，管理容器位置，服务发现，多实例。都是微服务需求的重要特性。因此，利用Kubernetes管理微服务和容器的发布，是一个非常有力的方案。
图11，展示了零售应用的微服务部署。每个服务都在独立的容器中，每个主机有两个容器，通过kubernetes可以随意调整容器的数量。
在实际运行环境中，微服务的安全也非常重要。我们先看下单体架构下安全是如何实现的。
一个典型的单体应用，安全问题主要是“谁调用”，“调用者能做什么”，“如何处理”。服务器接收到请求后，一般都在处理链条的最开始，通过安全组件来对请求的信息进行安全处理。
我们能直接把这种处理方式应用在微服务架构中吗？答案是可以的，需要每个微服务都实现一个安全组件从资源中心获取对应的用户信息，实现安全控制。这是比较初级的处理方式。可以尝试采用一些标准的API方式，比如OAuth2和OpenID。深入研究之前，可以先概括下这两种安全协议以及如何使用。
OAuth2-是一个访问委托协议。需要获得权限的客户端，向授权服务申请一个访问令牌。访问令牌没有任何关于用户/客户端的信息，仅仅是一个给授权服务器使用的用户引用信息。因此，这个“引用的令牌”也没有安全问题。
OpenID类似于OAuth，不过除了访问令牌以外，授权服务器还会颁发一个ID令牌，包含用户信息。通常由授权服务器以JWT（JSON Web Token）的方式实现。通过这种方式确保客户和服务器端的互信。JWT令牌是一种“有内容的令牌”，包含用户的身份信息，在公共环境中使用不安全。
现在我们看下如何在网络零售网站中应用这些协议保障微服务的安全。
图12中所示，是实现微服务安全的关键几步：
JWT包含必要的用户信息，如果每个微服务都能够解析JWT，那么你的系统中每个服务都能处理身份相关的业务。在每个微服务中，可以有一个处理JWT的轻量级的组件。
在微服务中怎么支持事务呢？事实上，跨多个微服务的分布式事务支持非常复杂，微服务的设计思路是尽量避免多个服务之间的事务操作。
解决办法是微服务的设计需要遵循功能自包含和单职责原则。跨越多个微服务支持分布式事务在微服务架构中不是一个好的设计思路，通常需要重新划定微服务的职责。某些场景下，必须要跨越服务支持分布式事务，可以在每个微服务内部利用“组合操作”。
最关键的事情是，基于单职责原则设计微服务，如果某个服务不能正常执行某些操作，那么这个服务是有问题的。那么上游的操作，都需要在各自的微服务中执行回滚操作。
微服务架构相比较单体的设计而言，引入了更多服务，在每个服务级别会增加发生错误的可能性。一个服务可能由于网络问题、底层资源等各种问题导致失败。某个服务的不可能不应该影响整个应用的崩溃。因此，微服务系统必须容错，甚至自动回复，对客户端无感知。
任何服务在任何时间都有可能出问题，监控系统需要能够发现问题，并且自动恢复。微服务环境下有不少常用的模式。
微服务中请求的失败率达到一定程度后，系统中的监控可以激活线路中断。当正常请求的数量恢复到一定程度后，再关闭线路中断的开关，使系统回复到正常状态。
这个模式可以避免不必要的资源消耗，请求的处理延迟会导致超时，借此可以把监控系统做的更完善。
一个应用会有很多微服务租车，单个微服务的失败不应该影响整个系统。防火墙模式强调服务直接的隔离性，微服务不会受到其它微服务失败的影响。
超时机制是在确定不会再有应答的情况下，主动放弃等待微服务的响应。这种超时应该是可配置的。
哪些情况下，如何使用这些模式呢？大多数情况，都应该在网关处理。当微服务不可用或者没有回复时，网关能够决定是否执行线路中断或者启动超时机制。防火墙机制同样重要，网关是所有请求的唯一入口，一个微服务的失败不应该影响到其它微服务。网关也是获得微服务状态、监控信息的中心。
我们已经讨论了微服务的架构和各种特性，以及如何应用在一个现代的IT系统中。同时也需要意识到，微服务不是解决所有问题的灵丹妙药。盲目追求流行的技术概念并不能解决掉企业IT系统的问题。
微服务有很多优势，但是仅靠微服务不能解决企业IT中的所有问题。例如，微服务需要去除ESB，但是现实的IT系统中，大量的应用和服务是基于ESB而不是微服务。集成现有的系统，需要一些集成总线。实际情况是，微服务和其它企业架构并存。
送你一个神器， wgcloud监控系统 ，免费的，只要是服务器，肯定选它就没错了。
我们项目中就用的它，主要是领导喜欢它的UI风格，它用户体验做的确实也好。
它能对服务器各种指标进行实时监测，比如cpu，内存，磁盘，网络流量等，部署简单，上手容易，虽然是英文名字，但却是地地道道的国产软件，运行几乎不占用资源，性能超好。
搭建家庭小型服务器，建议搭建黑群晖系统，对于离线下载高清电影，大容量素材的存储十分方便，对于黑群晖系统的搭建，下面和朋友们简单谈一下：
1选择主板CPU套装
由于群晖系统对于硬件要求较低，一般主要考虑搭建低功耗平台，推荐使用华擎j3455B-ITX CPU主板套装，对于群晖系统的兼容性较好，功率较低，比较省电。
选择专用的黑群晖机箱和电源
根据硬盘的数量和个人偏好选择相应盘位的黑群晖机箱，并选择和机箱配套的电源即可。
内存黑群晖系统对于内存要求不高，一般选择2g内存就可以满足需要，也可以根据需要选择4g内存。
组装黑群晖电脑
硬件准备齐全后就可以组装黑群晖电脑了，和普通电脑装机差别并不是很大。
安装黑群晖系统黑群晖电脑组装成功后，需要升级专用主板BIOS以兼容黑群晖系统。制作黑群晖系统启动U盘，并下载黑群晖系统镜像。用系统启动U盘启动黑群晖电脑后，在同一网络的电脑上使用群晖助手就可以将黑群晖系统镜像安装到黑群晖电脑中。详细教程网上都有，可以具体参考一下。
搭建黑群晖成本比购买白群晖要低很多，但功能方面基本相同，很适合高清影片离线下载和影视素材的存储。
建议你购买一款群晖Synology NAS，轻松搭建一个小型工作站，简单以我自己的群晖NAS做为简单演示。
首先你得购买一台群晖NAS，京东天猫都有旗舰店，作为家庭小型服务器的搭建对硬件配置要求不用太高，参考我的配置即可：
硬盘推荐选择大一些，比如我选择了3TB的两块硬盘，虽然贵点，但是一步到位，可以较长一段时间内足够放大量的图片和视频，我第一次因为没经验选择了1TB的硬盘，结果没用两年就空间不够了，不得不另外购置3TB的硬盘升级，幸好群晖升级硬盘非常省心，只需要将做RAID1的其中一块拆卸下来，放入一块新的硬盘，启动系统以后系统会自动提示有硬盘有冲突问你是否要fix，你就点击fix确定，然后系统会自动将其中一块旧硬盘的数据全部镜像到另外一块，等几个小时后彻底同步好了，再拆卸掉旧的，如法炮制装上另外一块空白硬盘再次同步，然后就成功将两块硬盘都升级为了3TB。
搭建好了NAS以后，就是通过远程访问了，一般如果默认只需要局域网访问就很简单，只需要将此NAS通过有线插入路由器，然后通过同一个局域网里的一台电脑通过浏览器远程访问此NAS，一般局域网内会默认通过： http://192.168.1.105:5000的方式来访问，然后就是进行一些常规的设置，进入Synology自带的Pacage Center，去安装一些常用的套间，群晖最大的特点就是操作系统非常牛逼，自带的套间也非常多，有些还非常好用，比如最新推出的一款Drive，里边包含了类似Google Doc和Zoho Doc的Office套件，完全支持多人协同作业，用户体验一级棒，反正我用了这个套件以后，团队内部协作就再也没出现过问题了：
从上图可以看出，有了这个Drive套件以后，基本满足了我们整个团队内部的文档协作，而且极大的提高了协作效率，为此我们真的要给予Synology团队点一百个 。
同时Synology Pacake Center还有大量的多媒体套件，可以满足各种多媒体存储和展示需求，比如如下这些套件：
搭建一个家庭影音休闲中心是完全没问题的。
Synology还有一个很厉害的地方就是，可以通过设置，让外网轻松访问到，从此只要这台NAS开启，无论出差到哪里都可以轻松读取NAS上的任何文件，是不是很酷？
如上图所示，简单两步设置以后，就彻底将这台局域网内的NAS变成了一台对外的公网服务器，从此只要你将此NAS一直保持开机状态，无论你到天涯海角都可以轻松读取文件，存取文件，从此无需再装任何第三方随时可能坑爹的云服务了。
或许有些人会担心这种NAS的安全性，我可以负责任的高速你，Synology这套操作系统是基于Unix内核开发的，类似Mac一样的一个分支，稳定性和安全性都绝对没问题，而且有一点就是，你可以随时随地物理的接触到这台服务器，有任何问题可以随时拆卸查看硬件问题，况且如今这个时代硬件产生问题的可能性几乎很小很小，只要放置的地方保持一定的温度和干燥，基本和放机房没太大区别。
说了这么多可别以为我是在为群晖打广告，本人和群晖公司没有任何关系，只不过确实是这几年用下来的一个真实感受，不吐不快，希望能够帮到你，最后祝你好运。
“网络极客”，全新视角、全新思路，伴你遨游神奇的网络世界。
家庭小型局域网，往往在装修的时候，已经以弱电箱为汇聚点完成了综合布线。
其实，并不建议按照此种方式布局，但是没有办法，只能够按照装修的规划来布置了。
一起来看看，如何围绕着弱电箱来搭建家庭小型局域网吧。
整体网络布局思路具体设置
关于家庭小型局域网组网，是否海域更好的建议？
欢迎大家留言讨论，喜欢的点点关注。
既然你问的是小型的，那么这非常简单：
1）需要一台无线路由器。其中“无线”两个字，就意味着手机等等无线数码设备也可以连入局域网。
2）如果家里有电脑，除了可以通过无线网卡接入局域网外，更推荐用网线连接到路由器的LAN口上。一般路由器上有4个LAN口，即最多可以通过网线接入4台设备（如电视机、高清盒子、蓝光播放机……等等）。
3）如果希望用网线接入局域网的设备超过4台，那么可以增加一个交换机，网购价只需几十元。此时的连接方法是，用一根网线从路由器的LAN口接入交换机的任何一个接口上即可。此时其它要接入局域网的设备就可以通过交换机的网线口连接了。
我家就是这样连接的。我家除了各位家庭成员的手机和iPad等通过无线连接外，通过网线连接的设备有两台电脑、智能电视机、蓝光碟机、4K网络盒子、卡拉OK点歌机。
“IT狂人日志”来回答你这个问题，推荐你使用TrueNas，简单说几个优点：
1、开源，免费使用；
2、支持NFS，SMB、SCSI、WebDAV等多种协议，尤其是还支持：苹果文件协议（AFP），多平台使用非常方便；
3、安装部署简单。
建议采购一台群晖，或者威联通的NAS这样就什么都有了，php+mysql环境，tomcat环境，java都可以，要是对dock了解那就很快上手，再有文件共享，音频，视频服务，个人网站，wordprees，crm系统在NAS上都可以一键搭建，NAS可以做vpn服务器，邮件服务器，监控服务器，最关键是比较小巧不占地方，购买一台2盘位的足够用了，除非你要有大量小片放！
穷玩党，没钱买服务器，闲的蛋疼又不甘堕落的，在寝室或家里宽带60m，身边还有台电脑，梦想把家里的电脑 如何架设成服务器 ?自己当网管，肯定比买某云的强太多了，即使不能保障365*24持续维护，但能够爽个一年半载也是不要不要的。即使不同的服务器提供的服务并不相同，但每种服务器由规划、架设到后续的安全维护， 流程是没太大差别的。
下面介绍一下第一种，操作的话还需自己琢磨。比如说光纤猫是网通的，有公有地址，平时用nat连接，本质就是端口映射，如果将光纤猫的某个固定端口，映射到自己电脑上的服务端口(就80吧)，那应该就ok的，虽然正常是dhcp分配的，临时映射端口，但是提供映射的应该还是有的吧。想要原理，自己上网。网上有人成功把私有地址改成了公有地址，那就下面是过程。
1、直接输入网关地址登录进去了，进去直接看到一个应用的，端口是应用层的了。
2、然后，可以看到nat服务器，可以直接设置，添加，
3、外部端口就是猫的端口，也就是客户端访问的时候的端口了。初始和终止的，直接设置80，
4、然后，还要选择服务器，默认的就什么telnet之类的，直接其他服务器地址的话，选择电脑的地址。
5、确认了。设置好后，首先是进入状态，copy了下公有地址了(没有的话，就网上搜下查看自己的共有ip啥的就行了)，
6、输入，如果成功，可以试试电脑、手机了，输入发现ok的话可以断下wifi，用的数据，如果，连接不上。首先，就apache(我用的wamp)是不是受限了，反正跟着网上的搞了很多httpd.conf的东西，把所有的deny from all改成allow了，
7、如果不行就可能是防火墙了，电脑防火墙是关着的，测试了下把防火墙打开，还是不行。那就只能是猫的防火墙了。但是，一打开，发现猫的防火墙只有高中低，不能关闭，
8、还不行就是超级管理员的问题，但这个管理员才能修改，账户只能查看，也可以直接修改啊，
9、期间还可以把apache的权限搞一遍，重启几遍，还是不行就映射其他端口试试。可以把端口改成了8520，这自己调试。
解决了问题关键是到一千还是两千是熟知端口，到8000以上的，肯定是自定义端口了，最低级别就是屏蔽这些端口了。可能，nat映射，这些熟知端口就默认没拿来映射(现在只是光纤猫，如果是主机那就废了)所以，端口映射的时候，最好还是选择自定义端口的。
人名币玩家如何架设服务器？
只需要两步：1、购买服务器。2、搭建服务器。
1、先登录wenidc.com/这个网站，在上面完成登录和注册，根据自己需要的产品进行充值。
2、充值后才可以购买服务器，要选择与我国关系友好的地区，如台湾等。在此选择香港。
3、服务器的类型(现在大多数的计算机都是64位操作系统的，所以一般选择64 bit os)，但是由于在下面要在linux操作系统下远程部署服务器，所以选择apache。
4、选择服务器的大小，在这里进行付费，付费后如果感觉服务器不理想，可以删除服务器，再重新购买。
到此，服务器购买完成，接下来就是部署服务器了。
第二步：部署服务器
1、下载ftp(上传网站模板到服务器需要用到的软件)
2、安装后打开该软件，点击新建。
填写两项：名称(随意)，主机(刚刚购买的服务器的IP地址)
在这里可以查到IP地址。输入完后点击确定。然后点击链接进入用户名界面，确认后开始输入密码。
那么如何查找密码呢?点击刚刚购买的服务器 ，进入后即可找到密码。
复制代码，确定后，进入部署界面，表示与服务器连接成功。
3、部署服务器
完成后出现设置新密码的界面。
设置完密码出现设置端口的密码。
设置完端口后，出现以下几个界面直接回车确定
出现上面那张图像时表示部署成功。(最后的这个的这个图最好保留下来，因为其中包括很多重要信息。)
三、用shadowsocks登陆 【客户端下载】
第一次电脑系统使用SSR/SS客户端时，需要安装NETFramework 4.0，不然无法正常使用，微软官网下载。NET Framework 4.0是SSR/SS的运行库，没有这个SSR/SS客户端无法正常运行。有的电脑系统可能会自带NETFramework 4.0。
打开ssr，在对应的位置，填上服务器ip、服务器端口、密码、加密方式、协议和混淆。密码和端口就是在部署服务器的时候自己设置的。
您的服务器将需要每日备份。也可以购买相关备份的软件，但必须监控并保持备份安全。可以存储在当前服务器或将它们存储在不同的计算机上。备份的一个主要问题是传输文件和知道备份是否可行的时间。大多数公司不知道他们的备份在他们真正尝试恢复数据之前已经损坏。此时，如果备份损坏，则数据将丢失。
因此，在搭建服务器时，请确保考虑备份过程，并花时间验证备份是否可行。大多数调度软件还会对备份进行检查，以确保数据不被破坏，但只有在测试过以后才发现，想要免去备案及相关麻烦其实还是租用一台香港免备案服务器更划算一点，你觉得呢？
我有个案例，帮朋友公司弄的用了半年了还没有出现过问题叫我去维护的，我自己用了也两年了
需要的硬件大致列一下：
1、h61平台一套 一个质量好一点容量在32G—64G的固态（我跟我朋友的配置都是i3 8G的内存，区别：我是ASUS的普通主板，朋友用的是最便宜的Dell塔式服务器）
2、我用的是黑裙 ，玩nas谁不想省两个毛爷爷。当然还有其它的开源平台
3、固态硬盘写好引导，输入ip地址进入后台进行相关设置，只要主板的SATA接口多，电源功率够，硬盘数量不是问题，黑裙里面可以组软阵列
这是自己的
这是朋友公司的
家中搭建，最关键的是外部网络。公网IP的ddns和端口转发。
然后是内网。根据你的诉求，视频为主。那么内网传输速度非常关键。如果家中PC无法长期开机，可能需要买nas设备和千兆网卡等附属硬件了。买买买就可以。
如果是丐版能用就行。可以选择树莓派。300对块钱，待机才几瓦。
欢迎分享，转载请注明来源：夏雨云
微信扫一扫
支付宝扫一扫
评论列表（0条）