微信开放平台：OpenAPI云开发与基础管理能力升级

Posted 2021-11-11 腾讯云·云开发CloudBase

微信团队近期对OpenAPI以及微信开放平台第三方平台基础能力进行了若干项优化，帮助开发者更好使用OpenAPI以及帮助服务商更好地使用第三方平台。优化内容具体如下：

OpenAPI 管理

1. 为了帮助开发者更高效定位OpenAPI问题，现开放“查询rid信息”接口，通过该接口可以查询请求详情（rid为每个请求的唯一id），包括发起请求的时间戳、请求毫秒级耗时、请求参数、返回参数等，详情可查看官方接口文档。
2. 为了帮助开发者更清晰地了解每个OpenAPI调用次数限制，更合理地调用接口，现开放“查询OpenAPI调用额度”接口。可查询API的当天调用次数、当天剩余次数等信息，详情可查看官方接口文档。
3. 当开发者调用接口达当天调用限制时，可以通过“清空API调用次数”的接口进行调用次数的重置，重置后即可恢复调用额度。接口的使用限制和详情可查看官方接口文档。

此外，为了帮助开发者更高效地使用API、管理API，微信团队将持续优化API调试工具以及API错误码查询工具等，详情可留意后续公告。

第三方平台管理

为了帮助第三方开发者更高效创建帐号、配置信息以及后续管理，微信团队近期对第三方平台创建流程、配置方式均作了优化，详情如下。

云开发助力简化步骤

1. 消息接收支持云开发：服务商可直接在云环境中获取平台推送消息，减免复杂解密环节。

2. 授权域名支持云开发：支持从云开发下静态网站域名内进行打开，可节省域名申请和备案环节。

以上配置可前往微信开放平台-第三方平台-开发资料配置页进行操作。

更高效更简单

1. 简化创建步骤，注册帐号与帐号审核解耦，帐号创建后可以具备上线条件后再提审，方便开发者在获得帐号后充分测试。缩短调试时间周期，也提高审核效率。
2. 优化全网发布环节，自动化检测成功后即可发布生效，无需再走人工审核，极大提升效率。
3. 为提升第三方代开发小程序的代码审核体验，平台对授权服务商代开发的小程序上线“标准模板“审核流程，使用标准模板且满足条件的小程序可加速通过审核。详情可以查看官方公告。

基础能力再升级

1. 为了方便服务商更灵活高效配置第三方平台小程序服务器域名和小程序业务域名，现已开放相应接口，详情可查看官方接口文档。
2. 第三方开发者除了可通过官方告警群接收告警信息外，现第三方平台支持绑定管理员以及时接收官方最新动态和信息，加强开发者与平台连接。

平台将继续与各位开发者共同建设更为完善的微信生态，共同创造出更多优质小程序。有任何和小程序开发有关的产品、运营、技术问题，可前往微信开放社区进行交流。

API网关的作用方案以及如何选择

一. API网关的用处

1.Open API。

企业需要将自身数据、能力等作为开发平台向外开放，通常会以rest的方式向外提供，最好的例子就是淘宝开放平台、腾讯公司的QQ开放平台、微信开放平台。 Open API开放平台必然涉及到客户应用的接入、API权限的管理、调用次数管理等，必然会有一个统一的入口进行管理，这正是API网关可以发挥作用的时候。

2.微服务网关。

微服务的概念最早在2012年提出，在Martin Fowler的大力推广下，微服务在2014年后得到了大力发展。 在微服务架构中，有一个组件可以说是必不可少的，那就是微服务网关，微服务网关处理了负载均衡，缓存，路由，访问控制，服务代理，监控，日志等。API网关在微服务架构中正是以微服务网关的身份存在。

3.API服务管理平台。

上述的微服务架构对企业来说有可能实施上是困难的，企业有很多遗留系统，要全部抽取为微服务器改动太大，对企业来说成本太高。但是由于不同系统间存在大量的API服务互相调用，因此需要对系统间服务调用进行管理，清晰地看到各系统调用关系，对系统间调用进行监控等。 API网关可以解决这些问题，我们可以认为如果没有大规模的实施微服务架构，那么对企业来说微服务网关就是企业的API服务管理平台。

二. API网关在企业整体架构中的地位

一个企业随着信息系统复杂度的提高，必然出现外部合作伙伴应用、企业自身的公网应用、企业内网应用等，在架构上应该将这三种应用区别开，三种应用的安排级别、访问方式也不一样。因此在我的设计中将这三种应用分别用不同的网关进行API管理，分别是：API网关（OpenAPI合伙伙伴应用）、API网关（内部应用）、API网关（内部公网应用）。

三. 企业中在如何应用API网关

1.对于OpenAPI使用的API网关来说，一般合作伙伴要以应用的形式接入到OpenAPI平台，合作伙伴需要到
OpenAPI平台申请应用。 因此在OpenAPI网关之外，需要有一个面向合作伙伴的使用的平台用于合作伙伴，这就要求OpenAPI网关需要提供API给这个用户平台进行访问。 如下架构:

当然如果是在简单的场景下，可能并不需要提供一个面向合作伙伴的门户，只需要由公司的运营人员直接添加合作伙伴应用id/密钥等，这种情况下也就不需要合作伙伴门户子系统。

2.对于内网的API网关，在起到的作用上来说可以认为是微服务网关，也可以认为是内网的API服务治理平台。当企业将所有的应用使用微服务的架构管理起来，那么API网关就起到了微服务网关的作用。 而当企业只是将系统与系统之间的调用使用rest api的方式进行访问时使用API网关对调用进行管理，那么API网关起到的就是API服务治理的作用。架构参考如下：

3.对于公司内部公网应用（如APP、公司的网站），如果管理上比较细致，在架构上是可能由独立的API网关来处理这部分内部公网应用，如果想比较简单的处理，也可以是使用面向合作伙伴的API网关。如果使用独立的API网关，有以下的好处：

面向合作伙伴和面向公司主体业务的优先级不一样，不同的API网关可以做到业务影响的隔离。

内部API使用的管理流程和面向合作伙伴的管理流程可能不一样。

内部的API在功能扩展等方面的需求一般会大于OpenAPI对于功能的要求。

基于以上的分析，如果公司有能力，那么还是建议分开使用合作伙伴OPEN API网关和内部公网应用网关

四. API网关有哪些竞争方案

1.对于Open API平台的API网关，我分析只能选择API网关作为解决方案，业界没有发现比较好的可以用来作为Open API平台的入口的其他方案。

2.对于作为微服务网关的API网关，业界的选择可以选择的解决方案比较多，也取决于微服务器的实现方案，有一些微服务架构的实现方案是不需要微服务网关的。

Service Mesh，这是新兴的基于无API网关的架构，通过在客户端上的代理完成屏蔽网络层的访问，这样达到对应用层最小的改动，当前Service Mesh的产品还正在开发中，并没有非常成熟可直接应用的产品。发展最迅速的产品是Istio。

建议大家密切关注相关产品的研发、业务使用进展。

五. API网关解决方案

私有云开源解决方案如下：

• Kong kong是基于Nginx+Lua进行二次开发的方案， https://konghq.com/

• Netflix Zuul，zuul是spring cloud的一个推荐组件，https://github.com/Netflix/zuul

• orange,这个开源程序是国人开发的，http://orange.sumory.com/

公有云解决方案：

• Amazon API Gateway，https://aws.amazon.com/cn/api-gateway/

• 阿里云API网关，https://www.aliyun.com/product/apigateway/

• 腾讯云API网关， https://cloud.tencent.com/product/apigateway

自开发解决方案：

• 基于Nginx+Lua+ OpenResty的方案，可以看到Kong,orange都是基于这个方案

• 基于Netty、非阻塞IO模型。 通过网上搜索可以看到国内的宜人贷等一些公司是基于这种方案，是一种成熟的方案。

• 基于Node.js的方案。 这种方案是应用了Node.js天生的非阻塞的特性。

• 基于java Servlet的方案。 zuul基于的就是这种方案，这种方案的效率不高，这也是zuul总是被诟病的原因

六. 企业怎么选择API网关

如果是要选择一款已有的API网关，那么需要从以下几个方面去考虑。

1.性能与可用性

如果一旦采用了API网关，那么API网关就会作为企业应用核心，因此性能和可用性是必须要求的。

从性能上来说，需要让网关增加的时间消耗越短越好，个人觉得需要10ms以下。 系统需要采用非阻塞的IO，如epoll，NIO等。网关和各种依赖的交互也需要是非阻塞的，这样才能保证整体系统的高可用性，如：Node.js的响应式编程和基于java体现的RxJava和Future。

网关必须支持集群部署，任务一台服务器的crash都应该不影响整体系统的可用性。

多套网关应该支持同一管理平台和同一监控中心。如： 一个企业的OpenAPI网关和内部应用的多个系统群的不同的微服务网关可以在同一监控中心进行监控。

2.可扩展性、可维护性

一款产品总有不能满足生产需求的地方，因此需求思考产品在如何进行二次开发和维护，是否方便公司团队接手维护产品。

3.需求匹配度

需要评估各API网关在需求上是否能满足，如： 如果是OpenAPI平台需要使用API网关，那么需要看API网关在合作伙伴应用接入、合作伙伴门户集成、访问次数限额等OpenAPI核心需求上去思考产品是否能满足要求。如果是微服务网关，那么要从微服务的运维、监控、管理等方面去思考产品是否足够强大。

4.是否开源？公司是否有自开发的能力？

现有的开源产品如kong，zuul，orange都有基础的API网关的核心功能，这些开源产品大多离很好的使用有一定的距离，如：没有提供管理功能的UI界面、监控功能弱小，不支持OpenAPI平台，没有公司运营与运维的功能等。当然开源产品能获取源代码，如果公司有比较强的研发能力，能hold住这些开源产品，经过二次开发kong、zuul应该还是适应一些公司，不过需求注意以下一些点：

kong是基于ngnix+lua的，从公司的角度比较难于找到能去维护这种架构产品的人。 需求评估当前公司是否有这个能力去维护这个产品。

zuul因为架构的原因在高并发的情况下性能不高，同时需要去基于研究整合开源的适配zuul的监控和管理系统。

orange由于没有被大量使用，同时是国内个人在开源，在可持续性和社区资源上不够丰富，出了问题后可能不容易找到人问。

END

数据轩

关于大数据的“术、道、势”

科技|应用|趋势