技术控

    今日:118| 主题:49431
收藏本版 (1)
最新软件应用技术尽在掌握

[其他] [译] 微服务模式系列之三:API 网关

[复制链接]
来治猩猩的你 发表于 2016-10-5 10:44:34
165 1

立即注册CoLaBug.com会员,免费获得投稿人的专业资料,享用更多功能,玩转个人品牌!

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
本文为普元 云计算架构师 宋潇男   翻译微服务模式文章系列,独家授权EAII企业架构创新研究院(微信号:eaworld)发布,转载请注明出处,违者必究。  
  译者自序:

  熟悉我的朋友都知道,我很不喜欢翻译东西,因为在两种语言的思维方式之间做频繁切换对我来说是件很痛苦的事情。但是这次不一样,公司和同事的大力支持降低了我的痛苦指数,让我能够坚持把Chris Richardson的微服务模式系列文章翻译完,今天发布第三篇,《API网关》。
      背景
     利用微服务模式构建一套在线商店,并要包含产品细节页面,需要为产品信息用户界面开发出多个版本:
  
       
  • 基于HTML5/JavaScript的用户界面,用于桌面与移动浏览器 —— HTML由服务器端Web应用生成。
       
  • 原生Android与iPhone客户端——这些客户端通过REST API与服务器进行交互。
      
  另外,在线商店必须通过REST API发布产品细节,以供第三方应用程序使用。
  产品细节UI可以显示出大量产品信息。举例来说,Amazon.com的POJOs in Action 图书详情页面中会显示:
  
       
  • 此书的基本信息,如标题、作者、价格等
       
  • 书籍的购买记录
       
  • 库存
       
  • 购买选项
       
  • 经常与此书籍搭配购买的货品
       
  • 买过此书的买家经常购买的其它货品
       
  • 客户评论
       
  • 卖家排名
       

  •   
  在使用微服务模式的在线商店中,产品详情数据会分布在多项服务之间,例如:
  
       
  • 产品信息服务—产品的基本信息,如标题与作者等
       
  • 价格服务—产品价格
       
  • 订单服务—产品的购买历史
       
  • 库存服务—当前产品的可购买数量
       
  • 评论服务—客户评论……
      
  因此,显示产品详情的代码需要从这些服务中获取信息。
      问题
     微服务架构的应用客户端如何访问各项服务?

      需求
     
       
  • 微服务提供的API粒度通常与客户端需要的有所不同。微服务通常提供的是细粒度API,这意味着客户端需要同多项服务进行交互。举例来说,如之前所提到的,客户端需要从多项服务处获取数据方可获得产品详情。
       
  • 不同客户端需要不同的数据。举例来说,有产品详情页面的桌面浏览器版本通常较移动版复杂。
       
  • 不同客户端的网络性能亦有所区别。举例来说,移动网络通常较非移动网络速度更慢且更延迟。当然,广域网速度也必然低于局域网。这意味着原生移动客户端所使用的网络在性能上与服务器端Web应用采用的局域网完全不同。服务器端Web应用能够向后端服务发送多条请求,而且不会影响到用户体验,但移动客户端则只能发送少量请求。
       
  • 服务实例数量与其位置(主机与端口)会发生动态变化。
       
  • 服务的划分方式会随时间的推移而改变,且不应被客户端所感知。
      
      方案
     使用API网关作为全部客户端的单一入口点。该API网关通过以下两种方式之一处理请求。部分请求会被直接代理/路由至对应的服务,另一部分请求则需要接入多项服务。
   
[译] 微服务模式系列之三:API 网关-1 (Android,在线商店,iPhone,云计算,浏览器)

  相比提供满足所有需求的API,API网关可以针对不同客户端提供出不同的API。举例来说,Netflix API网关运行的是客户端特定适配代码,这种代码能够为各客户端提供最符合其需求的API。
  API网关还能够实现安全防护,例如验证当前客户端是否有权执行该请求。
      示例
       Netflix API 网关  
      结果
     API网关有以下优势:
  
       
  • 确保客户端无法察觉应用程序是如何被拆分为多项微服务的。
       
  • 确保客户端不受服务实例的位置的影响。
       
  • 为每套客户端提供最优API。
       
  • 降低请求/往返次数。举例来说,API网关能够确保客户端在单次往返中就从多项服务中检索出数据。请求数量更少意味着运行负担更低且用户体验更好。API网关对于移动应用而言是必不可少的。
       
  • 将从客户端调用多项服务的逻辑转换为从API网关处调用,从而简化整个客户端。
      
  API网关模式也有一些弊端:
  
       
  • 复杂性高—API网关是另外一种需要开发、部署与管理的活动部件。
       
  • API网关会造成多余的网络跳转,从而增加响应时间—不过对于大多数应用程序而言,一次多余的往返并不会造成什么影响。
      
  问题:
  
       
  • 如何实现API网关?如果需要不断扩展以处理高负载量,那么事件驱动型/响应型方案是最理想的选择。在JVM上,Netty、Spring     Reactor等基于NIO的库大有用处。Node.JS也是一个可行的选项。
      
      相关模式
     
       
  • 微服务模式的存在催生出了对此模式的需求。
       
  • API网关必须使用客户端发现模式或者服务器端发现模式,从而将请求路由至可用的服务实例处。
      
      已知案例
     
       
  •    Netflix API 网关  
      
   原文链接: http://microservices.io/patterns/apigateway.html
   若想与作者有更多交流,请添加微信号: cloud_primeton
  关于译者:
  宋潇男
  EAII-企业架构创新研究院 专家委员
   现任普元云计算架构师, 曾任华为云计算产品技术总监。曾负责国家电网第一代云资源管理平台以及中国银联基于OpenStack的金融云的技术方案、架构设计和技术原型工作。

[译] 微服务模式系列之三:API 网关-2 (Android,在线商店,iPhone,云计算,浏览器)


  原著作者

  Chris Richardson

  世界十大软件架构师之一,《POJOS IN ACTION》一书的作者。他的研究领域包括Spring、Scala、微服务架构设计、NoSQL数据库、分布式数据库、分布式数据管理、事件驱动的应用编程等。
   关于EAII
    EAII(Enterprise Architecture Innovation Institute)企业架构创新研究院,致力于软件架构创新与实践,加速企业数字化转型。
    eaworld 项目  (微信号:eaworld,长按二维码关注)
12下一页
友荐云推荐




上一篇:Less Time Spec'ing, More Time Making: Be “Everywhere You Want to Be”
下一篇:Optimizing React Rendering through Virtualization
酷辣虫提示酷辣虫禁止发表任何与中华人民共和国法律有抵触的内容!所有内容由用户发布,并不代表酷辣虫的观点,酷辣虫无法对用户发布内容真实性提供任何的保证,请自行验证并承担风险与后果。如您有版权、违规等问题,请通过"联系我们"或"违规举报"告知我们处理。

樊小楠 发表于 2016-11-13 22:15:10
一脸的虚假繁荣。
回复 支持 反对

使用道具 举报

*滑动验证:
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

我要投稿

推荐阅读

扫码访问 @iTTTTT瑞翔 的微博
回页顶回复上一篇下一篇回列表手机版
手机版/CoLaBug.com ( 粤ICP备05003221号 | 文网文[2010]257号 )|网站地图 酷辣虫

© 2001-2016 Comsenz Inc. Design: Dean. DiscuzFans.

返回顶部 返回列表