业内交流 | 信用算力首席架构师潘志伟应邀出席阿里Dubbo社区开发者日活动

前言：Dubbo是阿里巴巴自研的分布式服务框架，自2012年开源以来，深得开发人员的喜爱，并被广泛的应用于服务化解决方案中。去年6月的Dubbo开发者沙龙中，信用算力首席架构师潘志伟曾与Dubbo爱好者们分享了Dubbo开源分布式服务框架在互金行业的应用场景，而在本次的开发者日活动，则为大家介绍了“基于Dubbo微服务框架的亿级网关架构解密”。

 

 

8月17日，由阿里Dubbo主办，阿里中间件与携程协办的Dubbo社区开发者日上海站活动在张江高科技园区举行。信用算力首席架构师潘志伟与来自阿里、携程、工商银行的资深架构师专家一起，作为特邀讲师出席了本次活动，与到场的众多Dubbo开发者和开源爱好者一起分享交流。

 

 

Dubbo是阿里巴巴自研的分布式服务框架，自2012年开源以来，深得开发人员的喜爱，并被广泛的应用于服务化解决方案中。自2018年12月开始，Dubbo 3.0便已正式进入开发阶段，并备受社区和广大Dubbo用户的关注。本次Dubbo社区开发者日，Dubbo讲师们先后分享了Dubbo在阿里、携程、信用算力、工商银行等平台上的落地实践与开发架构经验。

 

作为特邀企业讲师，潘志伟曾经在去年上海站的Dubbo开发者沙龙中分享了信用算力微服务架构的实践应用。在今年的Dubbo社区开发者日活动上，潘志伟作了以“基于Dubbo微服务框架的亿级网关架构解密”为题的主题演讲，主要针对信用算力在微服务架构下的API网关架构开发实践作了相关介绍。

 

网关作为出现在系统边界上的一个面向API的，串行集中式的强管控服务，是企业IT系统的边界，主要起到隔离外部访问与内部系统的作用。移动应用、企业互联，使得后台服务支持的对象，从以前单一的Web应用，扩展到多种使用场景，且每种使用场景对后台服务的要求都不尽相同。这不仅增加了后台服务的响应量，还增加了后台服务的复杂性。随着微服务架构概念的提出，API网关成为了微服务架构的一个标配组件。

 

潘志伟首先介绍了信用算力目前在网关应用方面所面临到的问题，主要存在接口复用性不高，上线新接口需要运维在Nginx中配置，以及涉及权限认证的每个模块各自处理，状态码各种各样的问题，从而导致实际应用过程中开发效率不高，入口请求日志散落到了各back层。

 

潘志伟提出，网关是整个服务对外的统一出口，所以信用算力在实际应用中，会在这一层做一些“防刷”工作，例如在有恶意流量访问的时候，可以通过IP限制等手段将其拒绝在整个网关之外，防止其对网关造成恶意冲击。

 

由于后端接口的响应时间网关没办法控制，信用算力利用了Hystrix的信号量隔离方式，来避免因为某个接口异常导致网关被拖垮，其中阈值的大小可通过管理端来对每个接口进行配置。同时，信用算力为API提供了一个熔断降级配置，可以自行设置API在达到多少错误率时进行降级或熔断，并在之后通知其他节点。如果遇到一些特殊情况，也可通过管理后台来主动指定某个接口熔断。

 

当然，在实际应用中，也会遇到如客户返回的自定义异常，但信用算力网关无法解析，以及后端DTO日期格式报错等的异常问题，这也引起了现场众多Dubbo开发者的共鸣。对此，潘志伟根据多年微服务网关架构经验，总结出网关核心系统必须是无状态的，以便于进行横向扩展；并且在运行时尽量不依赖本地存储，在内存中完成服务的处理和中转；减少对线程的依赖，采用非阻塞式IO和异步时间响应机制；网关必须要有自身的超时时间，而不是依赖服务方的超时限制。

 

在实际操作中，作为国内领先的信用服务解决方案提供商，信用算力对于自身的API网关系统提出了高性能、高可用、高可靠、高开发的要求，以达到系统毫秒级反应、分布式部署，吞吐量大且消耗资源少的目的。在此基础上，信用算力依托人工智能、大数据、云计算等核心科技，将更加精准而高效地为电商、餐饮、人力资源、金融等多个产业场景合作方提供精准营销、信用查询、智能建模、咨询研究在内的信用产品服务及行业解决方案。