API网关-浅析.ppt

《API网关-浅析.ppt》由会员分享，可在线阅读，更多相关《API网关-浅析.ppt（44页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、API网关网关-浅 析浅 析王王 振 涛振 涛一、为什么微服务需要一、为什么微服务需要API网关？网关？API网关是什么网关是什么？微微服务服务API网关的网关的优势优势API网关是什么网关是什么？API网关是一系列服务集合的访问入口。从面向对象设计的角度看，它与外观模式类似，实现对所提供服务的封装一个微服务架构可以包含数十到数百个服务。API网关可以为外部用户提供一个统一的入口，这个入口独立于内部微服务组件微微服务服务API网关的网关的优势优势阻止阻止将内部的敏感信息暴露给外部的客户端将内部的敏感信息暴露给外部的客户端 API网关通过提供微服务绑定和解绑的能力来将外部的公开API与内部微服务

2、API分离开。这样就具备重构和裁切微服务而不会影响外部绑定的客户端的能力。它同时对客户端隐藏了服务发现和服务版本这些细节，因为它对所有微服务提供单一的访问点微微服务服务API网关的网关的优势优势为为服务增加额外的安全层服务增加额外的安全层API网关通过提供额外的安全层帮助阻止大规模攻击。这些攻击包括SQL注入，XML解析漏洞和DoS攻击微微服务服务API网关的网关的优势优势可以可以支持混合通讯协议支持混合通讯协议不同于外部API一般使用HTTP或REST，内部微服务可以从使用不同通讯协议中收获益处。这些协议可以是ProtoBuf或AMQP，甚至是诸如SOAP，JSON-RPC或者XML-RPC

3、这样的系统集成协议。API网关可以对这些协议提供统一的外部REST接口，这就允许开发团队挑选一款最适合于内部架构的协议微微服务服务API网关的网关的优势优势降低降低微服务的复杂度微服务的复杂度微服务中有一些常见的要点，诸如使用API令牌进行授权，访问控制和调用频次限制。这每个点都需要每个服务区增加额外的时间去实现它们。API网关将这些要点从你的代码中提取出来，允许你的服务只关注于它们需要关注的任务微微服务服务API网关的网关的优势优势微微服务模拟和虚拟化服务模拟和虚拟化随着微服务API从外部API中分离出来，你可以模拟你的服务去做设计验证或者很方便的做集成测试二、微二、微服务与服务与RPC R

4、PC vs RestfulRPC技术选型技术选型Apache Thrift+Protobuf服务注册与发现服务注册与发现连接池连接池API网关网关熔断与限流熔断与限流服务服务演化演化RPC vs Restful在微服务中，使用什么协议来构建服务体系，一直是个热门话题。争论的焦点集中在两个候选技术：（Binary）RPC or Restful以Apache Thrift为代表的二进制RPC，支持多种语言（但不是所有语言），四层通讯协议，性能高，节省带宽。相对Restful协议，使用Thrift RPC，在同等硬件条件下，带宽使用率仅为前者的20%，性能却提升一个数量级。但是这种协议最大的问题在于

5、，无法穿透防火墙RPC vs Restful以Spring Cloud为代表所支持的Restful 协议，优势在于能够穿透防火墙，使用方便，语言无关，基本上可以使用各种开发语言实现的系统，都可以接受Restful 的请求。但性能和带宽占用上有劣势所以，业内对微服务的实现，基本是确定一个组织边界，在该边界内，使用RPC;边界外，使用Restful。这个边界，可以是业务、部门，甚至是全公司RPC技术选型技术选型RPC技术选型上，原则也是选择自己熟悉的，或者公司内部内定的框架Apache Thrift国外用的多，源于Facebook，后捐献给Apache基金。是Apache的顶级项目 Apache

6、Thrift。使用者包括Facebook、Evernote、Uber、Pinterest等大型互联网公司。而在开源界，Apache Hadoop/HBase也在使用Thrift作为内部通讯协议。这是目前最为成熟的框架，优点在于稳定、高性能。缺点在于它仅提供RPC服务，其他的功能，包括限流、熔断、服务治理等，都需要自己实现，或者使用第三方软件RPC技术选型技术选型Dubbo国内用的多，源于阿里公司。性能上略逊于Apache Thrift，但自身集成了大量的微服务治理功能，使用起来相当方便。Dubbo的问题在于，该系统目前已经很长时间没有维护更新了。官网显示最近一次的更新也是8个月前Google

7、Protobuf和Apache Thrift类似，Google Protobuf也包括数据定义和服务定义两部分。问题是，Google Protobuf一直只有数据模型的实现，没有官方的RPC服务的实现。直到2015年才推出gRPC，作为RPC服务的官方实现。但缺乏重量级的用户RPC技术选型技术选型Thrift 提供多种高性能的传输协议，但在数据定义上，提供多种高性能的传输协议，但在数据定义上，不如不如Protobuf强大强大同等格式数据，Protobuf压缩率和序列化/反序列化性能都略高。Protobuf支持对数据进行自定义标注，并可以通过API来访问这些标注，这使得Protobuf在数据操控

8、上非常灵活。比如可以通过option来定义Protobuf定义的属性和数据库列的映射关系，实现数据存取RPC技术选型技术选型数据结构升级是常见的需求，Protobuf在支持数据向下兼容上做的非常不错。只要实现上处理得当，接口在升级时，老版本的用户不会受到影响而Protobuf的劣势在于其RPC服务的实现性能不佳（gRPC）。为此，Apache Thrift+Protobuf的RPC实现，成为不少公司的选择Apache Thrift+Protobuf如上所述，利用Protobuf在灵活数据定义、高性能的序列化/反序列化、兼容性上的优势，以及Thrift在传输上的成熟实现，将两者结合起来使用，是不

9、少互联网公司的选择Apache Thrift+Protobuf服务定义：serviceHelloService binaryhello(1:binaryhello_request);Apache Thrift+Protobuf协议定义：messageHelloRequest optionalstringuser_name=1;/访问这个接口的用户 optionalstringpassword=2;/访问这个接口的密码 optionalstringhello_word=3;/其他参数；messageHelloResponse optionalstringhello_word=1;/访问这个接口的

10、用户 服务注册与发现服务注册与发现Spring Cloud提供了服务注册和发现功能，如果需要自己实现，可以考虑使用Apache ZooKeeper作为注册表，使用Apache Curator 来管理ZooKeeper的链接，它实现如下功能：侦听注册表项的变化，一旦有更新，可以重新加载注册表管理到zookeeper的链接，如果出现问题，则进行重试服务注册与发现服务注册与发现Curator的重试策略是可配置的，提供如下策略：BoundedExponentialBackoffRetry ExponentialBackoffRetry RetryForever RetryNTimes RetryOne

11、Time RetryUntilElapsed 一般使用指数延迟策略，比如重试时间间隔为1s、2s、4s、8s指数增加，避免把服务器打死服务注册与发现服务注册与发现对服务注册来说，注册表结构需要详细设计，一个参考的注册表结构按照如下方式组织：机房区域-部门-服务类型-服务名称-服务器地址 服务注册与发现服务注册与发现连接池连接池RPC服务访问和数据库类似，建立链接是一个耗时的过程，连接池是服务调用的标配。目前还没有成熟的开源Apache Thrift链接池，一般互联网公司都会开发内部自用的链接池。自己实现可以基于JDBC链接池做改进，比如参考Apache commons DBCP链接池，使用Ap

12、ache Pools来管理链接。在接口设计上，连接池需要管理的是RPC 的Transport：连接池连接池publicinterfaceTransportPool /*获取一个transport *return *throwsTException */publicTTransportgetTransport()throwsTException;连接池连接池连接池实现的主要难点在于如何从多个服务器中选举出来为当前调用提供服务的连接。比如目前有10台机器在提供服务，上一次分配的是第4台服务器，本次应该分配哪一台？在实现上，需要收集每台机器的QOS以及当前的负担，分配一个最佳的连接API网关网关随着

13、公司业务的增长，RPC服务越来越多，这也为服务调用带来挑战。如果有一个应用需要调用多个服务，对这个应用来说，就需要维护和多个服务器之间的链接。服务的重启，都会对连接池以及客户端的访问带来影响。为此，在微服务中，广泛会使用到API网关API网关网关网关作用网关作用 API网关本身不提供服务的具体实现，它根据请求，将服务分发到具体的实现上。其主要作用：API路由：接受到请求时，将请求转发到具体实现的worker机器上。避免使用方建立大量的连接。封装公共功能：将微服务治理相关功能封装到网关上，简化微服务的开发，这包括熔断、限流、身份验证、监控、负载均衡、缓存等API网关网关协议转换：原API可能使用

14、http或者其他的协议来实现的，统一封装为rpc协议。注意，这里的转换，是批量转换。也就是说，原来这一组的API是使用http实现的，现在要转换为RPC，于是引入网关来统一处理。对于单个服务的转换，还是单独开发一个Adapter服务来执行分流：通过控制API网关的分发策略，可以很容易实现访问的分流，这在灰度测试和AB测试时特别有用API网关网关解耦合解耦合 RPC API网关在实现上，难点在于如何做到服务无关。我们知道使用Nginx实现HTTP的路由网关，可以实现和服务无关。而RPC网关由于实现上的不规范，很难实现和服务无关。统一使用Thrift+Protobuf 来开发RPC服务可以简化AP

15、I网关的开发，避免为每个服务上线而带来的网关的调整，使得网关和具体的服务解耦合：API网关网关每个服务实现的worker机器将服务注册到ZooKeeper上API网关接收到ZooKeeper的变更，更新本地的路由表，记录服务和worker（连接池）的映射关系当请求被提交到网关上时，网关可以从rpc请求中提取出服务名称，之后根据这个名称，找到对应的worker机（连接池），调用该worker上的服务，接受到结果后，将结果返回给调用方API网关网关权限权限 Protobuf的一个重要特性是，数据的序列化和名称无关，只和属性类型、编号有关。这种方式，间接实现了类的继承关系。如下所示，我们可以通过Pe

16、rson类来解析Girl和Boy的反序列化流：messagePerson optionalstringuser_name=1;optionalstringpassword=2;API网关网关messageGirl optionalstringuser_name=1;optionalstringpassword=2;optionalstringfavorite_toys=3;messageBoy optionalstringuser_name=1;optionalstringpassword=2;optionalint32favorite_club_count=3;optionalstringf

17、avorite_sports=4;API网关网关我们只要对服务的输入参数做合理的编排，将常用的属性使用固定的编号来表示，既可以使用通用的基础类来解析输入参数。比如我们要求所有输入的第一个和第二个元素必须是user_name和password，则我们就可以使用Person来解析这个输入，从而可以实现对服务的统一身份验证，并基于验证结果来实施QPS控制等工作熔断与限流熔断与限流熔断一般采用电路熔断器模式（Circuit Breaker Patten）。当某个服务发生错误，每秒错误次数达到阈值时，不再响应请求，直接返回服务器忙的错误给调用方。延迟一段时间后，尝试开放50%的访问，如果错误还是高，则继

18、续熔断；否则恢复到正常情况熔断与限流熔断与限流熔断与限流熔断与限流限流指按照访问方、IP地址或者域名等方式对服务访问进行限制，一旦超过给定额度，则禁止其访问。除了使用Hystrix，如果要自己实现，可以考虑使用使用Guava RateLimiter服务演化服务演化随着服务访问量的增加，服务的实现也会不断演化以提升性能。主要的方法有读写分离、缓存等读写分离读写分离 针对实体服务，读写分离是提升性能的第一步。实现读写分离一般有两种方式：服务演化服务演化在同构数据库上使用主从复制的方式：一般数据库，比如MySQL、HBase、Mongodb等，都提供主从复制功能。数据写入主库，读取、检索等操作都从从

19、库上执行，实现读写分离。这种方式实现简单，无需额外开发数据同步程序。一般来说，对写入有事务要求的数据库，在读取上的性能会比较差。虽然可以通过增加从库的方式来sharding请求，但这也会导致成本增加服务演化服务演化服务演化服务演化在异构数据库上进行读写分离。发挥不同数据库的优势，通过消息机制或者其他方式，将数据从主库同步到从库。比如使用MySQL作为主库来写入，数据写入时投递消息到消息服务器，同步程序接收到消息后，将数据更新到读库中。可以使用Redis，Couchbase等内存数据库作为读库，用来支持根据ID来读取；使用Elastic作为从库，支持搜索服务演化服务演化服务演化服务演化缓存缓存使

20、用使用 如果数据量大，使用从库也会导致从库成本非常高。对大部分数据来说，比如订单库，一般需要的只是一段时间，比如三个月内的数据。更长时间的数据访问量就非常低了。这种情况下，没有必要将所有数据加载到成本高昂的读库中，即这时候，读库是缓存模式。在缓存模式下，数据更新策略是一个大问题服务演化服务演化对于实时性要求不高的数据，可以考虑采用被动更新的策略。即数据加载到缓存的时候，设置过期时间。一般内存数据库，包括Redis，Couchbase等，都支持这个特性。到过期时间后，数据将失效，再次被访问时，系统将触发从主库读写数据的流程对实时性要求高的数据，需要采用主动更新的策略，也就是接受Message后，立即更新缓存数据服务演化服务演化当然，在服务演化后，对原有服务的实现也会产生影响。考虑到微服务的一个实现原则，即一个服务仅管一个存储库，原有的服务就被分裂成多个服务了。为了保持使用方的稳定，原有服务被重新实现为服务网关，作为各个子服务的代理来提供服务