开题准备（扫盲1）---亚马逊对接框架

一、名词解释

1.微服务：

以下内容来源于亚马逊云AWS

微服务是一种开发软件的架构和组织方法，其中软件由通过明确定义的 API 进行通信的小型独立服务组成。这些服务由各个小型独立团队负责。

微服务架构使应用程序更易于扩展和更快地开发，从而加速创新并缩短新功能的上市时间。 

整体式架构与微服务（MicroService）架构

通过整体式架构，所有进程紧密耦合，并可作为单项服务运行。这意味着，如果应用程序的一个进程遇到需求峰值，则必须扩展整个架构。随着代码库的增长，添加或改进整体式应用程序的功能变得更加复杂。这种复杂性限制了试验的可行性，并使实施新概念变得困难。整体式架构增加了应用程序可用性的风险，因为许多依赖且紧密耦合的进程会扩大单个进程故障的影响。

使用微服务架构，将应用程序构建为独立的组件，并将每个应用程序进程作为一项服务运行。这些服务使用轻量级 API 通过明确定义的接口进行通信。这些服务是围绕业务功能构建的，每项服务执行一项功能。由于它们是独立运行的，因此可以针对各项服务进行更新、部署和扩展，以满足对应用程序特定功能的需求。

2.API：

api是应用程序编程接口（Application Programming Interface）此处主要了解WebAPI

以下内容来源维基百科

Web API 是定义的接口，企业和使用其资产的应用程序之间通过该接口发生交互，这也是一种服务级别协议(SLA)，用于指定功能提供者并为其 API 用户公开服务路径或 URL。API 方法是一种架构方法，它围绕为一组服务提供程序接口提供给服务于不同类型消费者的不同应用程序。[29]

在Web 开发环境中使用时，API 通常定义为一组规范，例如超文本传输​​协议(HTTP) 请求消息，以及响应消息结构的定义，通常采用可扩展标记语言 ( XML) ) 或 JavaScript 对象表示法 ( JSON ) 格式。一个例子可能是航运公司 API，它可以添加到以电子商务为中心的网站，以促进订购航运服务并自动包含当前的运费，而网站开发人员不必将托运人的费率表输入网络数据库。虽然“Web API”在历史上实际上是Web 服务的同义词，但最近的趋势（所谓的Web 2.0) 已经从基于简单对象访问协议 ( SOAP ) 的 Web 服务和面向服务的架构(SOA) 转向更直接的表示状态传输(REST) 样式的Web 资源和面向资源的架构(ROA)。[30]这一趋势的一部分与向资源描述框架(RDF)的语义 Web运动有关，这是一种促进基于 Web 的本体工程技术的概念。Web API 允许将多个 API 组合到称为混搭的新应用程序中。[31] 在社交媒体领域，Web API 允许 Web 社区促进社区和应用程序之间的内容和数据共享。通过这种方式，在一个地方动态创建的内容可以发布并更新到网络上的多个位置。[32]例如，Twitter 的 REST API 允许开发人员访问核心 Twitter 数据，搜索 API 为开发人员提供与 Twitter 搜索和趋势数据交互的方法。[33]

3.SOAP：简单对象传输协议（Simple Object Access Protocol） 

是一种消息传递协议规范，用于在计算机网络中的Web 服务实现中交换结构化信息。它使用XML 信息集作为其消息格式，并依赖于应用层协议，最常见的是超文本传输​​协议(HTTP)，尽管一些遗留系统通过简单邮件传输协议(SMTP) 进行通信，以进行消息协商和传输。

SOAP 为Web 服务提供了Web 服务协议栈的消息传递协议层。它是一个基于 XML 的协议，由三部分组成：

• 一个信封，它定义了消息结构[1]以及如何处理它
• 一组用于表达应用程序定义的数据类型实例的编码规则
• 表示过程调用和响应的约定

 SOAP 具有三大特点：

1. 可扩展性（安全性和WS-Addressing属于正在开发的扩展）
2. 中立性（SOAP 可以在任何协议上运行，例如HTTP、SMTP、TCP、UDP）
3. 独立性（SOAP 允许任何编程模型）

 作为 SOAP 过程可以做什么的一个示例，应用程序可以将 SOAP 请求发送到启用了 Web 服务（例如房地产价格数据库）的服务器，并带有搜索参数。然后服务器返回 SOAP 响应（带有结果数据的 XML 格式文档），例如价格、位置、特征。由于生成的数据采用标准化的机器可解析格式，因此请求应用程序可以直接集成它。

SOAP 体系结构由以下几层规范组成：

• 消息格式
• 消息交换模式(MEP)
• 底层传输协议绑定
• 消息处理模型
• 协议可扩展性

优点 

• SOAP 的中立特性使其适用于任何传输协议。实现通常使用 HTTP 作为传输协议，但也可以使用其他流行的传输协议。例如，SOAP 也可以用于 SMTP、JMS [19] [20]和消息队列。
• SOAP 与 HTTP 发布/响应交换结合使用时，可以轻松通过现有的防火墙和代理进行隧道传输，因此不需要修改用于处理 HTTP 发布/响应交换的广泛计算和通信基础设施。
• SOAP 具有 XML 的所有功能，包括使用 XML 命名空间轻松实现国际化和可扩展性。

 缺点

• 当使用标准实现和默认 SOAP/HTTP 绑定时，XML 信息集被序列化为 XML。为了提高带有嵌入式二进制对象的 XML 特殊情况的性能，引入了消息传输优化机制。
• 当依赖 HTTP 作为传输协议而不使用Web 服务寻址或企业服务总线时，交互方的角色是固定的。只有一方（客户端）可以使用另一方的服务。
• SOAP 不像名称所暗示的那样“简单”。协议冗长，XML解析速度慢，缺乏标准化的交互模型，导致服务更直接地使用HTTP协议占据主导地位。例如，请参见REST。
• 由于与协议无关，SOAP 无法利用特定于协议的功能和优化，例如REST 的统一接口或缓存——而必须重新实现它们（如使用WS-Addressing）。

4.SOA:面向服务的架构（service-oriented architecture）

企业系统的架构师认为SOA能够帮助业务迅速和高效地响应变化的市场条件[1]。服务导向的架构在宏观（服务）上，而不是在微观上（对象），因此提高了重复使用性。同时，服务导向的架构可以简化与传统系统的互连和使用。它并不是一门技术，而是一种分布式的软件设计方法

SOA中的一项服务应有以下四个特性：

1. 针对某特定要求的输出，该服务就是运作一项商业逻辑
2. 具有完备的特性（self-contained）
3. 消费者并不需要了解此服务的运作过程
4. 可能由底层其他服务组成

开发，维护和使用SOA的基本原则[3]：

• 可重复使用、粒度、模块性、可组合型、对象化原件、构件化以及具交互操作性
• 符合开放标准（通用的或行业的）
• 服务的识别和分类，提供和发布，监控和跟踪。

下面是一些特定的体系架构原则：

• 服务封装
• 服务松耦合（Loosely Coupled） - 服务之间的关系最小化，只是互相知道。
• 服务契约 - 服务按照服务描述文档所定义的服务契约行事。
• 服务抽象 - 除了服务契约中所描述的内容，服务将对外部隐藏逻辑。
• 服务的重用性 - 将逻辑分布在不同的服务中，以提高服务的重用性。
• 服务的可组合性 - 一组服务可以协调工作并组合起来形成一个组合服务。
• 服务自治 – 服务对所封装的逻辑具有控制权
• 服务无状态 – 服务将一个活动所需保存的信息最小化。
• 服务的可被发现性 – 服务需要对外部提供描述信息，这样可以通过现有的发现机制发现并访问这些服务。[4]

除此以外，在定义一个SOA实现时，还需要考虑以下因素：

• 生命周期管理
• 有效使用系统资源
• 服务成熟度和性能

 

5.ROA:面向资源的架构（resource-oriented architecture）

是一种软件架构风格和编程范式，用于支持以具有“ RESTful ”接口的资源互联的形式设计和开发软件。这些资源是软件组件（离散的代码和/或数据结构），可以为不同的目的重复使用。ROA设计原则和指南在软件开发阶段使用和系统集成。

REST 或 Representational State Transfer 描述了一系列架构约束，它们举例说明了 Web 设计是如何出现的。[1]随着时间的推移，这些想法的各种具体实现已经被创造出来，但很难在不模糊实际软件与其背后的架构原则之间的界限的情况下讨论 REST 架构风格。

RPC:远程过程调用（remote procedure call）

RPC 模型隐含了一定程度的位置透明性，即调用过程无论是本地的还是远程的，在很大程度上是相同的，但通常它们并不相同，因此可以将本地调用与远程调用区分开来。远程调用通常比本地调用慢几个数量级且可靠性较差，因此区分它们很重要。

RPC 是一种请求-响应协议。RPC 由客户端发起，客户端向已知的远程服务器发送请求消息，以使用提供的参数执行指定的过程。远程服务器向客户端发送响应，应用程序继续其进程。当服务器正在处理调用时，客户端会被阻塞（它会等待服务器完成处理后再继续执行），除非客户端向服务器发送异步请求，例如XMLHttpRequest。在各种实现中有许多变化和微妙之处，导致了各种不同（不兼容）的 RPC 协议。

远程过程调用和本地调用之间的一个重要区别是远程调用可能会因为不可预测的网络问题而失败。此外，调用者通常必须在不知道远程过程是否被实际调用的情况下处理此类故障。幂等过程（如果多次调用不会产生额外影响的过程）很容易处理，但仍然存在足够的困难，以至于调用远程过程的代码通常仅限于精心编写的低级子系统。

REST：表现层状态转换（Representational State Transfer）

是Roy Thomas Fielding博士于2000年在他的博士论文[1]中提出来的一种万维网软件架构风格，目的是便于不同软件/程序在网络（例如互联网）中互相传递信息。表现层状态转换是根基于超文本传输协议（HTTP）之上而确定的一组约束和属性，是一种设计提供万维网络服务的软件构建风格。符合或兼容于这种架构风格（简称为 REST 或 RESTful）的网络服务，允许客户端发出以统一资源标识符访问和操作网络资源的请求，而与预先定义好的无状态操作集一致化。因此表现层状态转换提供了在互联网络的计算系统之间，彼此资源可交互使用的协作性质（interoperability）。相对于其它种类的网络服务，例如SOAP服务，则是以本身所定义的操作集，来访问网络上的资源。

目前在三种主流的Web服务实现方案中，因为REST模式与复杂的SOAP和XML-RPC相比更加简洁，越来越多的Web服务开始采用REST风格设计和实现。例如，Amazon.com提供接近REST风格的Web服务运行图书查询；雅虎提供的Web服务也是REST风格的。

6.API网关(Api GateWay)

Amazon  API  Gateway 和阿里 API 网关分别基于 Amazon 云服务和阿里云服务，提供全托管的 API 服务，以及流量管理、CORS 支持、授权和访问控制、限制、监控等功能

API Gateway 是随着微服务（Microservice）这个概念一起兴起的一种架构模式，它用于解决微服务过于分散，没有一个统一的出入口进行流量管理的问题。

当使用微服务构建整个 API 服务时，一般会有许许多多职责不同的应用在运行着，这些应用会需要一些通用的功能，例如鉴权、流控、监控、日志统计。

在传统的单体应用中，这些功能一般都是内嵌在应用中，作为一个组件运行。但是在微服务模式下，不同种类且独立运行的应用可能会有数十甚至数百种，继续使用这种方式会造成非常高的管理和发布成本。所以就需要在这些应用上抽象出一个统一的流量入口，完成这些功能的实现。

在我看来，API Gateway 的职责主要分为两部分：

1. 对服务应用有感知且重要的功能，例如鉴权。
2. 对服务应用无感知的边缘服务，例如流控、监控、页面级缓存等。

虽然微服务具有种种优势，但也绝非毫无缺点，要想更好的得到微服务的种种好处，系统需要在分布式服务管理，系统部署、测试、监控以及分布式事务和ＣＡＰ（Consistency—致性、Availability可用性、partition tolerance分区容错性）相关问题上进行大量细致有效的工作。

几个术语：

熔断：这个术语来源于家用电器由于短路或其他问题时自动跳闸，电路断开。分布式系统中的熔断：内部服务或者是第三方服务，如果请求出现问题时，我们还是盲目的去请求，即使是失败了很多次，还是去请求，去等待。熔断器模式最牛的是能让应用程序自我诊断下游系统的错误是否已经修正，如果没有，不放量去请求，如果请求成功了，慢慢的增加请求，再次尝试调用。

降级：在有限的资源情况下，为了能抗住大量的请求，就需要对系统做出一些牺牲，有点“弃卒保帅”的意思。放弃一些功能，保证整个系统能平稳运行。（如：强一致性变为最终一致性，干掉一些次要功能，简化功能流程）

限流：通过对并发访问进行限速。

限流的行为： 

  1.拒绝服务：最简单的方式，把多余的请求直接拒绝掉做的高大上一些，可以根据一定的用户规则进行拒绝策略。 

  2.服务降级：降级甚至关掉后台的某些服务。
  3.特权请求：在多租户或者对用户进行分级时，可以考虑让一些特殊的用户有限处理，其他的可以考虑干掉
  4.延时处理：可以利用队列把请求缓存住。削峰填谷。

限流的方法：

1.计数器（限制请求次数比如一天500次）

2.漏斗模式：漏斗很多是用一个队列实现的，当流量过多时，队列会出现积压，队列满了，则开始拒绝请求

3.令牌桶：令牌通和漏斗模式很像，主要的区别是增加了一个中间人，这个中间人按照一定的速率放入一些token，然后，处理请求时，需要先拿到token才能处理，如果桶里没有token可以获取，则不进行处理。

对于 API Gateway，常见的选型有基于 Openresty 的 Kong、基于 Go 的 Tyk 和基于 Java 的 Zuul。

云平台Amazon Gateway ，阿里云Gateway，京东云Gateway