api网关 服务发现（api网关管理系统）

本篇文章给大家谈谈api网关 服务发现，以及api网关管理系统对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享api网关 服务发现的知识，其中也会对api网关管理系统进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、【知识总结】4.微服务的治理去中心化，服务发现，安全，部署
• 2、为什么需要api网关
• 3、Ocelot一款.NET下的API网关介绍
• 4、Go - Micro微服务框架实践 - API（十三）
• 5、API网关从入门到放弃

【知识总结】4.微服务的治理去中心化，服务发现，安全，部署

通常“治理”的意思是构建方案，并且迫使人们通过努力达到组织的目标。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而不是微服务。集成现有的系统，需要一些集成总线。实际情况是，微服务和其它企业架构并存。

为什么需要api网关

API网关跨一个或多个内部API提供单个统一的API入口点。 通常还包括限制访问速率限制和有关安全性等特点。 诸如Tyk.io的API管理层增加了额外的功能，例如分析，货币化和生命周期管理。

基于微服务的架构可以具有10到100个或更多个服务。 API网关可以为外部消费者提供统一的入口点，而与内部微服务的数量和组成无关。

API网关对于微服务的好处：

1、防止内部关注暴露给外部客户端

API网关将外部公共API与内部微服务API分开，允许添加微服务和更改边界。 其结果是能够在不对外部绑定客户端产生负面影响的情况下重构和适当大小的微服务。 它还通过为您的所有微服务提供单一入口点，对客户端隐藏了服务发现和版本控制详细信息。
2、为您的微服务添加额外的安全层

API网关通过提供一个额外的保护层来防止恶意攻击，例如SQL注入，XML解析器漏洞和拒绝服务（DoS）攻击。

3、支持混合通信协议

虽然面向外部的API通常提供基于HTTP或REST的API，但是内部微服务可以从使用不同的通信协议中受益。 协议可能包括的Protobuf或AMQP ，或者用SOAP，JSON-RPC或XML-RPC系统集成。 API网关可以在这些不同的协议之上提供外部的，统一的基于REST的API，允许团队选择最适合内部架构的API。
4、降低微服务复杂性

如果微服务具有共同的关注点，例如使用API令牌的授权，访问控制实施和速率限制。 每个这些关注可以通过要求每个服务都实现它们，但这为微服务的开发增加更多的时间成本。 API网关将从您的代码中删除这些问题，允许您的微服务关注手头的任务。
5、微服务模拟和虚拟化

通过将微服务API与外部API分离，您可以模拟或虚拟化服务，以验证设计要求或协助集成测试。

API网关的服务对象

API网关可以为Web端、APP提供API访问，也可以给物联网设备提供API接口。另外致力于开发生态的企业还会为一些合作伙伴提供API网关，供其调用通用的微服务。对于可以提供数据或算法服务的企业，可以在云市场的API网关注册自己的API，从而对外提供服务。

Ocelot一款.NET下的API网关介绍

前言

在当前微服务技术盛行的年代，大家都在大谈特谈微服务架构，api网关等等配套技术，但是我们发现，大多都是java系的一些技术，那咋们.NET系难道没有吗？那今天就给大家介绍一款ap网关框架：Ocelot

什么是网关

API网关—— 它是系统的暴露在外部的一个访问入口。这个有点像代理访问的家伙，就像一个公司的门卫承担着寻址、限制进入、安全检查、位置引导、等等功能。

什么是Ocelot

Ocelot是一个用.NET Core实现并且开源的API网关，它功能强大，包括了：路由、请求聚合、服务发现、认证、鉴权、限流熔断、并内置了负载均衡器与Service Fabric、Butterfly Tracing集成。这些功能只都只需要简单的配置即可完成，下面我们会对这些功能的配置一一进行说明。

Ocelot的实现原理

简单的来说Ocelot是一堆的asp.net core middleware组成的一个管道。当它拿到请求之后会用一个request builder来构造一个HttpRequestMessage发到下游的真实服务器，等下游的服务返回response之后再由一个middleware将它返回的HttpResponseMessage映射到HttpResponse上。

Ocelot基本使用

在项目中通过Nuget命令添加Install-Package Ocelot

首先在.Net工程中添加一个ocelot.json文件

在启动类中加载配置文件：

先指定Oclot的对外服务访问的地址和端口号

接下来才是Ocelot的核心配置：

{

"DownstreamPathTemplate": "/",

"UpstreamPathTemplate": "/",

"UpstreamHttpMethod": [

"Get"

],

"AddHeadersToRequest": {},

"AddClaimsToRequest": {},

"RouteClaimsRequirement": {},

"AddQueriesToRequest": {},

"RequestIdKey": "",

"FileCacheOptions": {

"TtlSeconds": 0,

"Region": ""

},

"ReRouteIsCaseSensitive": false,

"ServiceName": "",

"DownstreamScheme": "http",

"DownstreamHostAndPorts": [

{

"Host": "localhost",

"Port": 51876,

}

],

"QoSOptions": {

"ExceptionsAllowedBeforeBreaking": 0,

"DurationOfBreak": 0,

"TimeoutValue": 0

},

"LoadBalancer": "",

"RateLimitOptions": {

"ClientWhitelist": [],

"EnableRateLimiting": false,

"Period": "",

"PeriodTimespan": 0,

"Limit": 0

},

"AuthenticationOptions": {

"AuthenticationProviderKey": "",

"AllowedScopes": []

},

"HttpHandlerOptions": {

"AllowAutoRedirect": true,

"UseCookieContainer": true,

"UseTracing": true

},

"UseServiceDiscovery": false

}

配置属性说明：

Downstream是下游服务配置

UpStream是上游服务配置

Aggregates 服务聚合配置

ServiceName, LoadBalancer, UseServiceDiscovery 配置服务发现

AuthenticationOptions 配置服务认证

RouteClaimsRequirement 配置Claims鉴权

RateLimitOptions为限流配置

FileCacheOptions 缓存配置

QosOptions 服务质量与熔断

DownstreamHeaderTransform头信息转发

演示一个基本路由配置：

ReRoutes：是一个数组，里面包含了多组路由配置；

DownstreamPathTemplate：下游服务的真实地址；

DownstreamScheme：请求协议

DownstreamHostAndPorts：指定下游服务的ip，端口。这里可以配置负载均衡，比如下游服务应用横向部署在多台服务器上，这里非常方便的就可以做到负载均衡配置；

UpstreamPathTemplate：对外服务的地址；

UpstreamHttpMethod：配置请求方式；

RateLimitOptions：限流配置

EnableRateLimiting：限流开关

Period：限流统计时间段

PeriodTimespan：多长时间之后，用户可以再次访问

Limit：最大允许访问次数

好了，一个最基本的路由配置就完成了。

其他的功能点后面再逐一介绍。

Go - Micro微服务框架实践 - API（十三）

Micro的api就是api网关

API参考api网关 服务发现了 API网关模式 为服务提供了一个单一的公共入口。基于服务发现api网关 服务发现，使得micro api可以提供具备http及动态路由的服务。

Micro的API基于HTTP协议。请求的API接口通过HTTP协议访问api网关 服务发现，并且路由是基于服务发现机制向下转发的。 Micro API在 go-micro 之上开发，所以它集成了服务发现、负载均衡、编码及基于RPC的通信。

因为micro api内部使用了go-micro，所以它自身也是可插拔的。 参考 go-plugins 了解对gRPC、kubernetes、etcd、nats、及rabbitmq等支持。另外，api也使用了 go-api ，这样，接口handler也是可以配置的。

ACME（ Automatic Certificate Management Environment）是由 Let’s Encrypt 制定的安全协议。

可以选择是否配置白名单

API服务支持TLS证书

API使用带分隔符的命名空间来在逻辑上区分后台服务及公开的服务。命名空间及http请求路径会用于解析服务名与方法，比如 GET /foo HTTP/1.1 会被路由到 go.micro.api.foo 服务上。

API默认的命名空间是 go.micro.api ，当然，也可以修改api网关 服务发现：

api网关 服务发现我们演示一个3层的服务架构：

完整示例可以参考： examples/greeter

先决条件：我们使用Consul作为默认的服务发现，所以请先确定它已经安装好了，并且已经运行，比如执行 consul agent -dev 这样子方式运行。

向micro api发起http请求

HTTP请求的路径 /greeter/say/hello 会被路由到服务 go.micro.api.greeter 的方法 Say.Hello 上。

绕开api服务并且直接通过rpc调用：

使用JSON的方式执行同一请求：

micro api提供下面类型的http api接口

请看下面的例子

Handler负责持有并管理HTTP请求路由。

默认的handler使用从注册中心获取的端口元数据来决定指向服务的路由，如果路由不匹配，就会回退到使用”rpc” hander。在注册时，可以通过 go-api 来配置路由。

API有如下方法可以配置请求handler：

通过 /rpc 入口可以绕开handler处理器。

API处理器接收任何的HTTP请求，并且向前转发指定格式的RPC请求。

RPC处理器接收json或protobuf格式的HTTP POST请求，然后向前转成RPC请求。

代理Handler其实是内置在服务发现中的反向代理服务。

事件处理器使用go-micro的broker代理接收http请求并把请求作为消息传到消息总线上。

Web处理器是，它是内置在服务发现中的HTTP反向代理服务，支持web socket。

/rpc 端点允许绕过主handler，然后与任何服务直接会话。

示例：

更多信息查看可运行的示例： github.com/micro/examples/api

解析器，Micro使用命名空间与HTTP请求路径来动态路由到具体的服务。

API命名的空间是 go.micro.api 。可以通过指令 --namespace 或者环境变量 MICRO_NAMESPACE= 设置命名空间。

下面说一下解析器是如何使用的：

RPC解析器示例中的RPC服务有名称与方法，分别是 go.micro.api.greeter ， Greeter.Hello 。

URL会被解析成以下几部分：

带版本号的API URL也可以很容易定位到具体的服务：

代理解析器只处理服务名，所以处理方案和RPC解析器有点不太一样。

URL会被解析成以下几部分：

API网关从入门到放弃

假设api网关 服务发现你正在开发一个电商网站api网关 服务发现，那么这里会涉及到很多后端的微服务api网关 服务发现，比如会员、商品、推荐服务等等。

那么这里就会遇到一个问题，APP/Browser怎么去访问这些后端的服务? 如果业务比较简单的话，可以给每个业务都分配一个独立的域名(https://service.api.company.com)，但这种方式会有几个问题:

更好的方式是采用API网关，实现一个API网关接管所有的入口流量，类似Nginx的作用，将所有用户的请求转发给后端的服务器，但网关做的不仅仅只是简单的转发，也会针对流量做一些扩展，比如鉴权、限流、权限、熔断、协议转换、错误码统一、缓存、日志、监控、告警等，这样将通用的逻辑抽出来，由网关统一去做，业务方也能够更专注于业务逻辑，提升迭代的效率。

通过引入API网关，客户端只需要与API网关交互，而不用与各个业务方的接口分别通讯，但多引入一个组件就多引入了一个潜在的故障点，因此要实现一个高性能、稳定的网关，也会涉及到很多点。

API 注册

业务方如何接入网关?一般来说有几种方式。

协议转换

内部的API可能是由很多种不同的协议实现的，比如HTTP、Dubbo、GRPC等，但对于用户来说其中很多都不是很友好，或者根本没法对外暴露，比如Dubbo服务，因此需要在网关层做一次协议转换，将用户的HTTP协议请求，在网关层转换成底层对应的协议，比如HTTP - Dubbo, 但这里需要注意很多问题，比如参数类型，如果类型搞错了，导致转换出问题，而日志又不够详细的话，问题会很难定位。

服务发现

网关作为流量的入口，负责请求的转发，但首先需要知道转发给谁，如何寻址，这里有几种方式:

服务调用

网关由于对接很多种不同的协议，因此可能需要实现很多种调用方式，比如HTTP、Dubbo等，基于性能原因，最好都采用异步的方式，而Http、Dubbo都是支持异步的，比如apache就提供了基于NIO实现的异步HTTP客户端。

因为网关会涉及到很多异步调用，比如拦截器、HTTP客户端、dubbo、redis等，因此需要考虑下异步调用的方式，如果基于回调或者future的话，代码嵌套会很深，可读性很差，可以参考zuul和spring cloud gateway的方案，基于响应式进行改造。

优雅下线

性能

网关作为所有流量的入口，性能是重中之重，早期大部分网关都是基于同步阻塞模型构建的，比如Zuul 1.x。但这种同步的模型我们都知道，每个请求/连接都会占用一个线程，而线程在JVM中是一个很重的资源，比如Tomcat默认就是200个线程，如果网关隔离没有做好的话，当发生网络延迟、FullGC、第三方服务慢等情况造成上游服务延迟时，线程池很容易会被打满，造成新的请求被拒绝，但这个时候其实线程都阻塞在IO上，系统的资源被没有得到充分的利用。另外一点，容易受网络、磁盘IO等延迟影响。需要谨慎设置超时时间，如果设置不当，且服务隔离做的不是很完善的话，网关很容易被一个慢接口拖垮。

而异步化的方式则完全不同，通常情况下一个CPU核启动一个线程即可处理所有的请求、响应。一个请求的生命周期不再固定于一个线程，而是会分成不同的阶段交由不同的线程池处理，系统的资源能够得到更充分的利用。而且因为线程不再被某一个连接独占，一个连接所占用的系统资源也会低得多，只是一个文件描述符加上几个监听器等，而在阻塞模型中，每条连接都会独占一个线程，而线程是一个非常重的资源。对于上游服务的延迟情况，也能够得到很大的缓解，因为在阻塞模型中，慢请求会独占一个线程资源，而异步化之后，因为单条连接所占用的资源变的非常低，系统可以同时处理大量的请求。

如果是JVM平台，Zuul 2、Spring Cloud gateway等都是不错的异步网关选型，另外也可以基于Netty、Spring Boot2.x的webflux、vert.x或者servlet3.1的异步支持进行自研。

缓存

对于一些幂等的get请求，可以在网关层面根据业务方指定的缓存头做一层缓存，存储到Redis等二级缓存中，这样一些重复的请求，可以在网关层直接处理，而不用打到业务线，降低业务方的压力，另外如果业务方节点挂掉，网关也能够返回自身的缓存。

限流

限流对于每个业务组件来说，可以说都是一个必须的组件，如果限流做不好的话，当请求量突增时，很容易导致业务方的服务挂掉，比如双11、双12等大促时，接口的请求量是平时的数倍，如果没有评估好容量，又没有做限流的话，很容易服务整个不可用，因此需要根据业务方接口的处理能力，做好限流策略，相信大家都见过淘宝、百度抢红包时的降级页面。

因此一定要在接入层做好限流策略，对于非核心接口可以直接将降级掉，保障核心服务的可用性，对于核心接口，需要根据压测时得到的接口容量，制定对应的限流策略。限流又分为几种:

稳定性

稳定性是网关非常重要的一环，监控、告警需要做的很完善才可以，比如接口调用量、响应时间、异常、错误码、成功率等相关的监控告警，还有线程池相关的一些，比如活跃线程数、队列积压等，还有些系统层面的，比如CPU、内存、FullGC这些基本的。

网关是所有服务的入口，对于网关的稳定性的要求相对于其他服务会更高，最好能够一直稳定的运行，尽量少重启，但当新增功能、或者加日志排查问题时，不可避免的需要重新发布，因此可以参考zuul的方式，将所有的核心功能都基于不同的拦截器实现，拦截器的代码采用Groovy编写，存储到数据库中，支持动态加载、编译、运行，这样在出了问题的时候能够第一时间定位并解决，并且如果网关需要开发新功能，只需要增加新的拦截器，并动态添加到网关即可，不需要重新发布。

熔断降级

熔断机制也是非常重要的一项。若某一个服务挂掉、接口响应严重超时等发生，则可能整个网关都被一个接口拖垮，因此需要增加熔断降级，当发生特定异常的时候，对接口降级由网关直接返回，可以基于Hystrix或者Resilience4j实现。

日志

由于所有的请求都是由网关处理的，因此日志也需要相对比较完善，比如接口的耗时、请求方式、请求IP、请求参数、响应参数(注意脱敏)等，另外由于可能涉及到很多微服务，因此需要提供一个统一的traceId方便关联所有的日志，可以将这个traceId置于响应头中，方便排查问题。

隔离

比如线程池、http连接池、redis等应用层面的隔离，另外也可以根据业务场景，将核心业务部署带单独的网关集群，与其他非核心业务隔离开。

网关管控平台

这块也是非常重要的一环，需要考虑好整个流程的用户体验，比如接入到网关的这个流程，能不能尽量简化、智能，比如如果是dubbo接口，我们可以通过到git仓库中获取源码、解析对应的类、方法，从而实现自动填充，尽量帮用户减少操作api网关 服务发现；另外接口一般是从测试-预发-线上，如果每次都要填写一遍表单会非常麻烦，我们能不能自动把这个事情做掉，另外如果网关部署到了多个可用区、甚至不同的国家，那这个时候，我们还需要接口数据同步功能，不然用户需要到每个后台都操作一遍，非常麻烦。

这块个人的建议是直接参考阿里云、aws等提供的网关服务即可，功能非常全面。

其他

其他还有些需要考虑到的点，比如接口mock，文档生成、sdk代码生成、错误码统一、服务治理相关的等，这里就不累述了。

目前的网关还是中心化的架构，所有的请求都需要走一次网关，因此当大促或者流量突增时，网关可能会成为性能的瓶颈，而且当网关接入的大量接口的时候，做好流量评估也不是一项容易的工作，每次大促前都需要跟业务方一起针对接口做压测，评估出大致的容量，并对网关进行扩容，而且网关是所有流量的入口，所有的请求都是由网关处理，要想准确的评估出容量很复杂。可以参考目前比较流行的ServiceMesh，采用去中心化的方案，将网关的逻辑下沉到sidecar中，

sidecar和应用部署到同一个节点，并接管应用流入、流出的流量，这样大促时，只需要对相关的业务压测，并针对性扩容即可，另外升级也会更平滑，中心化的网关，即使灰度发布，但是理论上所有业务方的流量都会流入到新版本的网关，如果出了问题，会影响到所有的业务，但这种去中心化的方式，可以先针对非核心业务升级，观察一段时间没问题后，再全量推上线。另外ServiceMesh的方案，对于多语言支持也更友好。

关于api网关 服务发现和api网关管理系统的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 api网关 服务发现的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于api网关管理系统、api网关 服务发现的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。