openresty scenarios and RD Gateway System Function

openresty main scenario

Web Applications

Some business logic processing, and even template rendering CPU-intensive, general process: mysql / redis / http access to data, business processes, resulting JSON / XML / template rendered content, such as Jingdong list page / product details page.

Web Firewall

You can be IP / URL / UserAgent / Referer blacklist, current limiting functions.

Access Gateway 

The data verification achieve pre, pre-caching, data filtering, the API request polymerization authentication management, load balancing, flow control, gray release, downgrade, monitoring and other functions.

The following is a detailed description features:

  • Authentication: authentication authorization based on the access application
  • Security: Only authorized applications are allowed to access the corresponding api, ip shell black list mechanisms. Expansion: The apparatus like id, location sensitive data reinspection ...
  • Limiting: call external systems to prevent the transition of the current system, resulting in service overload, the impact of the use of the core business
  • Dynamic configuration updates: Change API, grouping, assembly and other run-time configuration, automatic synchronization, timely entry into force.
  • Routing Service (rewrite): identification request parameters and API upstream path forwarding services.
  • Availability: clustering support, to avoid a single point of failure.
  • High performance: Gateway stateless lateral support extension, the weak dependence runtime persistence layer, to enhance the gateway to maximize overall performance.
  • Fuse (TBD): back-end service call timeout or appear abnormal, the system automatically fuse the service.
  • Health Check (TBD): for service has been blown api, dynamic detection of health status, health if the repair has been blown api. At present the initial version to ensure the performance, the use of manual recovery service interface, the latter gradually adjust according to the needs of automatic recovery (extension: service inspection)
  • Gray-release: product support so that a designated portion of the client application to use the new version of the API, other applications continue to use the previous API, when a new version of the API gradually stabilized, all users can smooth the transition to the new version of the API. Use grayscale early release can get user feedback, improve product features, improve product quality. Allowing users to participate in product testing, strengthen the interaction with the user, and reduce the range of products affected by the upgrade.
  • Cache: Cache api backend data service returns, reducing the pressure of the back-end service.
  • Distributed cache: when the system cache api large clusters can be used to improve system response and the like redis
  • Logging: to specify the dimensions stored in logging system, easy to customize and audit statistics.
  • 超时控制:通过API配置访问超时时间,超时后立即返回,避免工作线程长时间等等。
  • 服务编排:将多个后端服务聚合成一个API暴露,减小客户端开发复杂度,快速生产新的API。
  • 管理中心:API网关后台管理中心简洁明了,方便API网关管理员对API进行管理,数据面板方便了解系统运行情况。
  • 监控中心:监控中心对API运行情况一目了然,通过分析API异常告警辅助系统运维。

Guess you like

Origin www.cnblogs.com/phpworld/p/10969401.html