API网关技术与开发——node.js_开题报告

（一）回顾历史

多年以来，我们一直在寻找更好的方法来构建应用系统。我们一直在学习已有的技术，尝试新技术，也目睹过不少新兴技术公司使用不同的方式来构建IT应用系统，从而提高了客户满意度和开发效率。

EricEvans的《领域驱动设计》一书帮助我们理解了用代码呈现真实世界的重要性，并且告诉我们如何更好地进行建模。持续交付理论告诉我们如何更有效及更高效地发布软件产品，并指出保持每次提交均可发布的重要性。基于对Web的理解，我们寻找到了机器与机器交互的更好方式。AlistairCockburn的六边形架构理论（://alistair.cockburn.us/Hexagonal+architecture）把我们从分层架构中拯救出来，从而能够更好地体现业务逻辑。借助虚拟化平台，我们能够按需创建机器并且调整其大小，借助基础设施的自动化我们也很容易从一台机器扩展到多台。

随着领域驱动设计、持续交付、按需虚拟化、基础设施自动化、小型自治团队、大型集群系统这些实践的流行，微服务也应运而生。它并不是被发明出来的，而是从现实世界中总结出来的一种趋势或模式。但是没有前面提及的这些概念，微服务也很难出现。

（二）分层架构

在以往的分层架构中，各个应用系统开发了重复的功能，调用关系不清晰，系统变的很难维护。其中一个服务的崩溃可能造成其他服务不能正常运行，无法统一监控了解整体情况。如图所示：

（三）面向服务的架构

SOA（Service-OrientedArchitecture，面向服务的架构）是一种设计方法，其中包含多个服务，而服务之间通过配合最终会提供一系列功能。一个服务通常以独立的形式存在于操作系统进程中。服务之间通过网络调用，而非采用进程内调用的方式进行通信。

人们逐渐认识到SOA可以用来应对臃肿的单块应用程序，从而提高软件的可重用性，比如多个终端用户应用程序可以共享同一个服务。它的目标是在不影响其他任何人的情况下透明地替换一个服务，只要替换之后的服务的外部接口没有太大的变化即可。这种性质能够大大简化软件维护甚至是软件重写的过程。

（四）什么是微服务

微服务就是一些协同工作的小而自治的服务。如下图所示

关键好处如下：

（1）很小专注于做好一件事情

随着新功能的增加，代码库会越变越大。时间久了代码库会非常庞大，以至于想要知道该在什么地方做修改都很困难。尽管我们想在巨大的代码库中做到清晰地模块化，但事实上这些模块之间的界限很难维护。相似的功能代码开始在代码库中随处可见，使得修复bug或实现更加困难。在一个单块系统内，通常会创建一些抽象层或者模块来保证代码的内聚性，从而避免上述问题。内聚性是指将相关代码放在一起，在考虑使用微服务的时候，内聚性这一概念很重要。RobertC.Martin有一个对单一职责原则（SingleResponsibilityPrinciple，://programmer.97things.oreilly.com/wiki/index.php/The_Single_Responsibility_Principle）的论述：“把因相同原因而变化的东西聚合到一起，而把因不同原因而变化的东西分离开来。”该论述很好地强调了内聚性这一概念。微服务将这个理念应用在独立的服务上。根据业务的边界来确定服务的边界，这样就很容易确定某个功能代码应该放在哪里。而且由于该服务专注于某个边界之内，因此可以很好地避免由于代码库过大衍生出的很多相关问题。

（2）自治性

一个微服务就是一个独立的实体。它可以独立地部署在PAAS（PlatformAsAService，平台即服务）上，也可以作为一个操作系统进程存在。服务之间均通过网络调用进行通信，从而加强了服务之间的隔离性，避免紧耦合。

这些服务应该可以彼此间独立进行修改，并且某一个服务的部署不应该引起该服务消费方的变动。对于一个服务来说，我们需要考虑的是什么应该暴露，什么应该隐藏。如果暴露得过多，那么服务消费方会与该服务的内部实现产生耦合。这会使得服务和消费方之间产生额外的协调工作，从而降低服务的自治性。

（3）弹性

弹性工程学的一个关键概念是舱壁。如果系统中的一个组件不可用了，但并没有导致级联故障，那么系统的其他部分还可以正常运行。服务边界就是一个很显然的舱壁。在单块系统中，如果服务不可用，那么所有的功能都会不可用。对于单块服务的系统而言，可以通过将同样的实例运行在不同的机器上来降低功能完全不可用的概率，然而微服务系统本身就能够很好地处理服务不可用和功能降级问题。

微服务系统可以改进弹性，但你还是需要谨慎对待，因为一旦使用了分布式系统，网络就会是个问题。不但网络会是个问题，机器也如此，因此我们需要了解出现问题时应该如何对用户进行展示。

（4）扩展

庞大的单块服务只能作为一个整体进行扩展。即使系统中只有一小部分存在性能问题，也需要对整个服务进行扩展。如果使用较小的多个服务，则可以只对需要扩展的服务进行扩展，这样就可以把那些不需要扩展的服务运行在更小的、性能稍差的硬件上，

（5）简化部署

在有几百万代码行的单块应用程序中，即使只修改了一行代码，也需要重新部署整个应用程序才能够发布该变更。这种部署的影响很大、风险很高，因此相关干系人不敢轻易做部署。于是在实际操作中，部署的频率就会变得很低。这意味着在两次发布之间我们对软件做了很多功能增强，但直到最后一刻才把这些大量的变更一次性发布到生产环境中。这时，另外一个问题就显现出来了：两次发布之间的差异越大，出错的可能性就更大！在微服务架构中，各个服务的部署是独立的，这样就可以更快地对特定部分的代码进行部署。如果真的出了问题，也只会影响一个服务，并且容易快速回滚，这也意味着客户可以更快地使用我们开发的新功能。Amazon和Netflix等组织采用这种架构主要就是基于上述考虑。这种架构很好地清除了软件发布过程中的种种障碍。

（五）为什么选Node.js。

Node.js是用来构建面向微服务的架构的绝佳选择，原因如下：

学习门槛低

易于扩展

对测试友好

易于部署

可以通过npm进行依赖管理

有着大量与主流标准协议相集成的库

二、^范文提纲

1技术选型

1.1 SpringCloud-Zuul

1.2 Kong

1.3 Nginx+Lua

1.4 NODE.JS

2核心功能

2.1认证

2.1.1 Baisc认证

2.1.2 JWT认证

2.2鉴权

2.2.1应用授权

2.2.2 NULL授权

2.3流量管控

2.3.1客户端应用流量管控

2.3.2 API流量管理

2.4缓存

2.5安全防护

2.5.1身份认证

2.5.2授权应用

2.5.3公私密钥算法保护

2.5.4 IP白名单、黑名单机制

2.6服务路由

2.7日志记录

2.8负载均衡

2.9超时控制

2.10熔断

2.11监控中心

2.12管理中心

3测试

参考文献

[1]纽曼(SamNewman),崔力强张骏.微服务设计:1-5

[2]大卫·冈萨雷斯(DavidGonzalez),赵震一.Node.js微服务456

[3]董超,胡炽维.SpringCloud微服务架构开发实战

[4]李明江.NginxLua开发实战(Web开发技术丛书)2018-01

[5]朴灵.深入浅出Node.js (图灵原创)2013-12

[6]泽卡斯(Zakas. Nicholas C.) , 李松峰 (译者), 曹力 (译者).java script高级程序设计(第3版)

[7]://nodejs.cn/api/

[8]s://koa.bootcss.com/

[9]s://.npmjs.com/package/koa-router

[10]://.w3school.com.cn