重装系统后,无法访问远程API

解决方法：1、点击桌面左下角的windows图标，点击菜单中的“运行”工具，接着输入“control”命令，按Enter键执行即可。
2、打开控制面板窗口后，将查看方式切换成“大图标”，接着找到并点击“程序和功能”选项。
3、接下来点击“打开或关闭windows功能”，然后在windows功能窗口中找到并勾选“Telnet服务器”和“Telnet客户端”，点击“确定”按钮保存设置即可。

API暂停服务通常是技术问题，有以下几种情况：
1、淘宝服务器繁忙或者服务器维护（可能性不大）
2、手机淘宝版本过低（更新到最新版本）
3、如果是技术同学，可能是淘宝关闭了部分api权限，收回了开发者已有的选项（等淘宝的通知调整）

本文由Donny译自 3scalecom 的 《How to load test & tune performance on your API》
这几年API的作用不断演化，以前API还只是用来做内部系统之间的集成点，但现在API已成为一个公司的核心系统，一个构建于Web和移动端应用之上的核心系统。

当API仅只用来处理后台的任务（例如生成报告），那么性能差点也不是问题。但是如今API慢慢地发展成为连接服务与终端用户的核心纽带。这种关键性的角色变化表明了一个重要的观点：那就是API的性能真的很重要。

如果API数据源响应快，前端的应用程序的设计好点或差点影响不大，要是响应慢如蜗牛，前端的设计再出色也是然并卵。现在我们的客户端应用展示的数据源可能都是来自多个API响应内容的聚合，性能对这种微服务构架来说真的非常重要。

可以毫不夸张的说出色的性能就是你API提供的最好功能。我们知道向目标改进的唯一正确的方法就是找到问题的关键点，或者叫关键路径，并不断迭代测量和调整你的架构系统，直到系统达到预定的目标。对于API来说，测量和提高性能的过程就是负载与压力测试的过程。

本文将重点介绍如何对你的API进行负载压力测试。我们会以一个简单的、未测过的例子开始，然后再添加一个访问控制层，要确保一切都经过严格测试，做好处理真实流量的准备工作。OK，开始吧！
首先我们要明确要测试什么，可以是对你所有的API接口，或者是对单个API接口，或是对需要排除故障或改进的API接口的常规测试。
本文的其部分，我们将使用一个示例API。这是一个棋牌类游戏的Nodejs API。它有三个API接口：
/question – 返回一个随机黑牌

/answer – 返回一个随机白牌
/pick – 返回一对随机的问题与答案

你测试用的负荷情况越和真实环境的越类似，你的负载测试就越有用。如果你不知道实际流量有多少或者你不知道负载在所有接口上是否都一致，那么就算你知道你的API可以保持400 请求/秒的吞吐量也没啥鸟用。

所以，你应该先从收集你API的使用数据开始。你可以直接从你的API服务日志或者从其他你在用的应用性能工具（例如New Relic）中获取数据。在对你的API进行第一次测试之前，你应该对以下问题做到心中有数：
（1）每秒请求数的平均吞吐量（Average throughput in requests per second）

（2）峰值吞吐量（您在某段时间内获得的最大流量是多少？）（Peak throughput）

（3）API各接口的吞吐量分布情况（有没有一些接口的流量远超其他接口？）

（4）用户的吞吐量分布情况（少数用户产生大多数的流量，或者是更均匀分布？）

另外还需要考虑的一个关键点是，在测试期间将要模拟的流量会是怎样的，主要考虑点是：

（1）重复负载生成（Repetitive load generation）

（2）模拟流量模式

（3）真实流量

通常我们最好以最简单的方法开始测试，然后逐步演化到更为接近真实环境的测试。我们可以先用重复负载生成来做为API接口的第一个测试，这样不仅可以验证我们的测试环境是否稳定，更重要的是可以让我们找到API能承受的最大吞吐量，这样我们就可以知道API可以达到的性能上限是多少。

找到你的API性能上限值后，你就可以开始考虑如何将你的生成的测试流量塑造得更接近真实环境。使用真实流量来测试是最理想的，但实际 *** 作不太可行。要模拟真实流量比较难，也太花时间。所以我们有一个折中点的方法：先研究你的流量分析数据，并做一个简单的概率模拟。比如你有100个API接口（提示：原文endpoint在这里我译为接口，翻译成端点也可以，不过译成接口感觉更容易理解），你检查了上个月的使用情况，发现80%的流量来自20个接口，其中3个接口占用了50%的流量。那么你就可以创建一个遵循这种概率的请求列表，并提供给你的负载测试工具。这样做就相对快多了，并且它相对比较接近你真实负载，可以显示出你实际环境中可能遇到的问题。

最后，如果你拿到你要测试的API的真实访问日志，你就可以用它们来做最接近客观现实的测试。我们待会儿要讨论的大部分负载测试工具，都是接收一个请求列表作为输入文件。你可以用你的访问日志，稍微做一个格式调整就可以匹配每个测试工具所需的格式。搞定这个你就可以在测试环境中轻松重现你的生产流量。
好了，你清楚了你要测试什么鬼了，准备工作的最后一步就是配置好你的测试环境。你需要一个专用的测试环境。如果你不怕被你老板骂的话，或者比较任性，你也可以直接在你的生产环境中进行性能测试，不过出问题别说哥事先没跟你说清楚哈。

如果您已经设好一个预生产或沙箱环境，并且你的API也在上面运行了，那么你就万事俱备了。因为本文要用示例API，我们会在AWS的服务实例上设置我们的环境。

在我们的例子中，我们使用一个简单的API，不需要从磁盘读取或在内存中保存大型数据集。我们选择Linux C4large 实例就够了。

注意：我们对比过其他相似处理资源数但内存更大的AWS实例，但实际测试中内存大部分没使用，所以我们选了C4large

接下来，我们将一个配好的负载测试实例（服务器）运行起来，这只是一个运行模拟测试程序的服务器，它会通过从多个并发连接重复发送请求到我们的API服务器。你需要模拟的负载越高，机器的性能就要求越高。再次，这也是一个CPU密集型工作负载。这里我们选择具有4个虚拟核，16个 ECU的优化处理器的 c4xlarge AWS服务器

我们选择在相同的可用区内部署所有实例（API服务器与测试服务器在同一个区/机房），这样可以将外部因素对我们测试结果的影响降到最小。
我们有一个沙箱环境来运行我们的API，同时也有另一台服务器准备开始负载测试。如果这是你第一次做性能测试，你一定会想知道什么是最好的方法。在本节中，我们将会分享我们如何选择工具，同时也会介绍一下目前市面上一些公认比较好的工具。

JMeter

在人们意识当中，首当翘楚的估计是 Apache JMeter ，这是一个开源的Java程序，他关键的特性就是提供一个强大而完善的创建测试计划的GUI。测试计划由测试组件组成，测试组件定义了测试的每一个部分，例如：

（1）用来注入负载测试的线程
（2）参数化测试中使用的>