Fiddler在移动App测试中的应用小红的测试生涯
& Fiddler在移动App测试中的应用
我在移动app测试、web测试中经常使用fiddler，fiddler能记录所有客户端和服务器的http和https请求，个人觉得还比较好用，今天就来整理一下我在移动app测试工作中用到的几个fiddler的功能。
1. fiddler原理
fiddler原理如下图，它就是一个代理，默认代理地址:127.0.0.1, 端口:8888。
2. 手机配置
首先，在fiddler中设置允许远程连接 “allow remote computers to connect”
然后在ipad/tablet上配置代理：网络连接， 打开HTTP代理， 输入Fiddler所在机器的IP地址：你安装fiddler的计算机ip，以及端口号8888。一般不需要重启设备，有时候可能会需要重启设备。运行app或者网页，移动端发送给server的http request都能被fiddler截获。
3. 查看request
在inspectors下面可以看到具体的request，统计信息，web forms，header等等：
4. 设置断点
设置断点中断request：
中断所有会话：Fiddler -& Rules-& Automatic Breakpoint
-&Before Requests （disable消除断点）
中断某一条request：在QuickExec命令行中输入命令:
bpu *************** （命令行中输入命令 bpu消除断点）
设置断点中断response：
中断所有会话：Fiddler -& Rules-& Automatic Breakpoint
-& After Response（disable消除断点）
中断某一条request：在QuickExec命令行中输入命令:
bpafter *************** （命令行中输入命令 bpafter 消除断点）
设置断点之后便可以修改request或者response。
5. filter过滤会话
6. fiddler模拟低网速
首先可以自定义Modem speed，fiddler -& rules -& customize rules
这段话意味着每上传、下载1KB延迟多久，你可以更改该数据来设置网速。
然后到fiddler -& performances -& simulate modem speeds.
fiddler的功能很强大，我日常工作中用到的只是其冰山一角。
参考网站：
Current ye@r *
Leave this field emptyWEB、接口、APP自动化测试的一些看法
我的图书馆
WEB、接口、APP自动化测试的一些看法
标签：&&&&&&&&&&&&&&&& 当故事看即可，只是个人看法...............& 目前在各个软件公司中基本上存在WEB和APP的对外系统，不管是电子商务、电信、新闻等基本上都有WEB和APP同时存在。对于APP个人感觉是新东西，但也觉得它就是个老东西，因为大家是否记得我们曾经装在电脑上的Application应用程序，当然一个管理软件当时就很NB了。不过现在手机上的Application和以前电脑上的Application当然不管技术上还是形态上都是不一样的，但使用上似乎是一样的，同样的下载---安装---使用。这些都是体外话题，我想说的是软件测试，当年的软件危机大爆发导致了软件测试这个职业的出现，测试中的懒人出现导致自动化测试的产生，而Application应用程序是最初的尝试产品吧。那个时候的自动化测试就是很NB的自动化测试，但现在呢，应该叫Application应用程序的UI自动化测试、接下来互联网的出现，应该出现了WEB的UI自动化测试、再接下来API技术的来临，应该出现了接口的自动化测试、这几年又出现了手机版本Application出现，然后就是APP自动化测试的出现（其实APP自动化测试按技术类型分也包含了UI(UI应该主要包含了NATIVE和WEBVIEW,还有加载中间的hybrid，我还是看好WEBVIEW的未来，哈哈。。。。)和接口。说了这么多只想说明我知道的挺多.....接下来我想说说WEB的UI自动化测试、接口自动化测试和APP的自动化测试。& WEB的UI自动化测试：&&&&很多人在说自动化测试的时候，基本上现在指的是WEB的UI自动化测试，但其实这是不对的，自动化测试包含了很多开发的技术，不只是界面上的自动化测试。WEB的UI自动化测试只是其中的一种，但它的工具确实最多的，我所知道的有WINRUNNER\QTP(UFT)\TESTCOMPLETE\SILKTEST\ROBOT\SELENIUM\RF\WAITER等等，当然最出名的是商业工具QTP和开源工具SELENIUM。现在各个公司通过开源搭建的自动化框架基本上都是以SELENIUM为底层，个人感觉SELENIUM还是非常的好的工具。而对于没有开发基础的测试人员，可以考虑QTP这个自动化工具，掌握比较快，但要学精还是需要掌握开发技术。但当你掌握了开发技术后就会放弃QTP想玩SELENIUM了。原因是QTP越做越烂了，虽然最新版本的UFT增加了API的测试，当我觉得这个更加是鸡肋，QTP这个产品在WINDOWS环境下做还可以，但是你想扩展到其他环境就麻烦了，如自动启停进程相关的操作....。工具介绍就到这吧,总体来说根据自己的需求来选择符合自己公司的工具和开发语言。接下来我说下WEB的UI自动化测试的优缺点：&&&&缺点：&&&&开发效率低、维护成本高、执行速度慢.......................几百种缺点。&&&&优点：&&&&用户操作真实性强。&接口自动化测试：&&&&接口自动化测试在后来出现，但现在大部分的互联网公司都喜欢用它作为测试工作辅助。原因很简单，UI自动化的缺点它都能进行弥补，但同时它也存在一个最大的问题：用户操作真实性不强。其实个人觉得接口自动化测试和UI自动化测试可以产生互补的测试。因为我们做接口测试时更多的是根据开发的技术进行测试HTTP\SOCKET等等（接口测试基本上不需要用到什么工具进行，如果一定需要的话建议是用SOAPUI），而非真实的进行对系统进行操作验证系统是否存在问题。&APP的自动化测试：& APP的自动化测试应该也要分为UI和接口自动化测试，接口测试与上面说的一样都是技术层面上的事情就不说了。那么还是关注APP的UI自动化测试，APP的自动化测试工具方面也有很多，但也都不成熟，我选择了APPIUM，主要考虑到的它可以进行跨平台测试，但最大的问题还是不稳定。所以也不敢大面积的布置其自动化测试用例。APP刚才说过了主要分为NATIVE和WEBVIEW，NATIVE的对象还好获取，像android可以直接使用uiautomatorviewer进行获取。而WEBVIEW就比较麻烦，不能直接获取要么就让开发提供给你，要么就直接下代码自己找，还有就是通过google的一个方法进行获取.......& 说了一下这三种技术的一些内容，其实我想说不管什么类型的自动化测试，我们测试的过程中都需要和开发进行紧密的结合，但测试优于开发的测试思想。另外这三种技术我们在实际的应用中更应该将其进行混合的测试：&&&&1、UI（WEB）自动化测试走主流程的测试、接口自动化测试走全面的测试：先布置接口的自动化测试用于测试和回归测试，特别在敏捷测试中，接口自动化测试应该占主体。后布置UI自动化测试用于住流程的回归测试。&&&&2、UI（WEB）自动化测试与APP自动化测试结合：需要一个自动化测试框架的协调，可以进行UI自动化测试到APP接口层的长流程场景自动化测试，也可以进行UI自动化测试到APPUI层的长流程场景自动化测试。&&&&3、接口自动化测试与APP自动化测试结合：其实和UI与APP自动化测试长流程的交换一样的原理，需要自动化测试框架的支撑。先进行接口测试用例的执行后进行APP的UI和接口测试的用例执行。& & 以上是我想说的这么个故事....看看就好....本文出自 “” 博客，请务必保留此出处标签：&&&&&&&&&&&&& &
TA的最新馆藏
喜欢该文的人也喜欢《移动App测试实战》——2.1　轻量接口自动化测试
本节书摘来自华章出版社《移动App测试实战》一 书中的第2章，第2.1节，作者：邱鹏　陈吉　潘晓明，更多章节内容可以访问云栖社区“华章计算机”公众号查看。
2.1　轻量接口自动化测试
无论Web互联网的产品还是移动互联网的产品都必须依赖大量的后台接口提供的服务，有很多的业务逻辑都是放在后台来处理的，所以非常有必要对这部分逻辑来做测试验证。
本节书摘来自华章出版社《移动App测试实战》一 书中的第2章，第2.1节，作者：邱鹏　陈吉　潘晓明，更多章节内容可以访问云栖社区“华章计算机”公众号查看。
2.1　轻量接口自动化测试
无论Web互联网的产品还是移动互联网的产品都必须依赖大量的后台接口提供的服务，有很多的业务逻辑都是放在后台来处理的，所以非常有必要对这部分逻辑来做测试验证。技术方案上，也可以模拟用户的UI操作，从界面上发起相关的请求。但是实际中，会发现这样的做法效率不高而且稳定性不够，开发和维护的代价也比较大。针对这部分的测试，最直接的方式还是从接口层面发起请求来验证。就目前观察，对于一些比较稳定的基础性组件，比如底层平台、API、SDK等，或者功能通用性高的产品，比如防火墙、邮件系统等，都可以做到比较高的自动化率，而且自动化测试开发的方案也相对比较明确。相比而言，偏重应用层业务的测试团队，通常在自动化方面的开展要困难很多，主要有以下几个问题：首要的问题是版本的节奏，互联网产品版本节奏非常快，一个稍大的系统一周发布上百个功能特性是一件很常见的事情。团队成员有非常多的精力消耗在这些功能版本上，需要快速理解业务，构建测试环境，进行bug验证回归，以及发布和线上验证等，留给业务测试人员构建自动化用例的时间非常少。自动化框架的开发代价比较大。自己开发或者维护过测试框架的人可能都深有体会，这绝不是一件容易的事情，其工作量和持续的时间往往会超出我们的预期，特别是对于大部分的互联网测试团队，尤其是一些初创团队。而另一方面，也很难找到一个现成的，能满足特定需求的平台。实际的项目，特别是大型的项目，功能通常都非常的复杂，需要将业务逻辑通过框架的能力来表达，对构建用例来说也存在一定的门槛。而测试开发人员由于对各个业务细节的了解程度不够且精力有限，对于需要构建大规模自动化测试用例的系统也是一个挑战。对于一些大的互联网研发团队，如果有一个比较大的测试部门，对应有比较强的测试开发能力，可以考虑自己开发一套自动化测试框架，然后可以在多个业务测试团队复用。对于一些人力有限的团队，则需要考虑一些轻量级的方式。这里不准备介绍如何开发一个自动化框架，那可能需要写一本书的篇幅。下面将要介绍的是适合小团队的一些测试自动化的方法，基于我们之前在一些实际项目中的实践。这套方法我们曾在几个不同类型的项目中得到应用，包括电商的后端ERP系统、Web网站以及App的后台接口，都获得了比较好的实际效果，同时测试开发和用例编写的代价相对可以承受。
2.1.1　JMeter关于自动化方面的特性介绍
这个轻量级方法的核心是采用开源测试工具JMeter作为引擎，把发送接口请求，以及结果的解析和断言的工作都交给JMeter的基础功能来实现。这样的考虑涉及两个问题：一是为什么不从头开发一套完整的自动化框架？二是为什么采用JMeter？关于不从头开发一套完整的框架，主要的考虑如下：1）首先主要是开发成本的考虑。用当前任何一个主流的开发语言，比如Java/Python/PHP等，写一个协议层面的收发都非常简单，因为有了大量的通用的库。但是如果用于自动化测试，需要考虑的方面非常多，比如以HTTP协议为例：需要考虑数据编码的问题需要处理连接的建立，销毁的问题需要考虑Cookie的问题，自动重定向的问题，是否用keep-alive对于POST，需要处理发送前的数据准备问题需要处理代理的问题需要处理返回数据的解析需要支持各种断言的形式2）在自动化测试的开展过程中，会不断对底层框架提出新的要求，需要有持续的测试开发人力投入。3）需要保证框架的高质量和稳定性。很多内部开发的框架都会遇到上面的问题，投入了大量人力，开发了很长时间，也需要持续的维护，但是一旦有大的产品和人员的变动，很多时候，框架或者框架的很多功能都会被废弃。4）这可能不是团队的工作核心。开发一个HTTP等基础协议的收发处理的框架对很多业务测试团队来说，都不是核心的职责和最重要的事情，特别是人力有限的情况下。基于这样的考虑，为了快速构建一套可用的自动化框架，我们决定寻找一个开源的工具，能完成协议层面的基本功能。最后我们选用了JMeter，基于它来构建我们的自动化平台。JMeter是Apache Software Foundation下面的一个开源项目，有超过10年的历史了。它是一个纯Java编写的测试工具，最早主要用于HTTP协议性能测试（现在这仍是其主要用途之一），但是后来随着功能的逐渐丰富完善，它也成为一个接口协议测试工具，以及自动化测试工具。下面介绍下它的一些特点，主要从功能测试的角度，其他更进一步的信息可以参考它的官方文档，或者下载之后试验。
支持多种不同类型的协议从图2-1可以看出，JMeter自带支持的接口协议有多种，可以直接应用，省去了上面提到的接口协议的数据收发方面的开发。
对HTTP协议的支持比较全面HTTP是互联网最常用的协议，目前很多移动互联网产品也是通过HTTP协议来完成后台的交互。JMeter对HTTP的支持比较全面，如图2-2所示，对于协议方法、请求的参数和选项、代理等方面都提供了支持。
除此之外，还提供了Cookie管理、Cache管理、消息头和授权管理等辅助功能，如图2-3所示。
3.其他非直接支持的协议可以通过扩展方式实现某些实际项目中，可能在App和服务端通信上采用非上述标准协议之外的其他协议，包括一些私有协议。对于这种情况，可以通过JMeter提供的通用组件来编写代码扩展，或者更进一步编写JMeter插件，类似于一个新的Sampler。接下来我们通过一个例子看看如何通过现有组件来扩展。对于其他私有通信协议的接口，我们可以通过JMeter的OS Process Sampler来进行桥接和测试，如图2-4所示。OS Process Sampler可以用来启动一个可执行程序，由于是通过命令行方式启动，所以我们可以用任何语言编写一个测试用的可执行程序。在该可执行程序中调用我们的接口，调用完成后可以做简单的解析判断输出文本信息，也可以把返回的原始数据输出而交由JMeter做后续解析判断。具体做法是往该进程的标准输出流写入数据。之后在JMeter 中即可读取这些数据。以C#语言为例，在测试程序中我们可以用下列代码输出文本到标准输出流：
Console.WriteLine("[!Error!]");```
在JMeter中我们可以使用BeanShell PostProcessor来处理可执行文件输出，如图2-5所示。
使用BeanShell PostProcessor来处理可执行文件输出，BeanShell PostProcessor中获取输出的关键代码如下：
var res=prev.getResponseDataAsString();var hasErr=res.contains("[!Error!]");if(hasErr){//这里可以增加断言或者进行变量赋值等常用操作}`
通过上述例子可以看到，测试用可执行文件的输出与JMeter的输入数据需要有一定的约定格式。该数据格式在项目中可以根据实际情况自由设计。
支持丰富的断言对于接口测试而言，断言是一个非常重要的功能，而且实际项目中，可能需要比较复杂的断言方式来判断结果是否正确。
图2-6所示是JMeter提供的响应断言，可以看出，其支持的检查内容比较多，包括响应代码、响应头和Body内容等方面，检查方式也支持多种不同的规则。
支持内嵌自定义脚本实际中，一个功能的自动化可能需要多个步骤，包含调用多个接口来完成。而多个接口之间有一些逻辑管理，比如后面的接口依赖前面接口的响应数据，甚至数据需要做一些处理才能为后面的接口所用。针对这种情况，可以通过JMeter内嵌支持的自定义脚本来实现，可以使用JavaScript和Java等语言。
下面我们以JavaScript语言为例，通过一个实际的例子来看看，如图2-7所示。
这个例子是针对一个电商App的首页楼层布局的检查，前面的接口返回了各个楼层的信息，这里的BSF PostProcessor里面的JS脚本以前面接口的返回作为参数，解析出其中各个楼层的信息，然后存入到数组中。之后后续的接口就可以读取这些变量，逐个地访问这些楼层的信息。
可以直连DB检查数据在实际的接口自动化中，除了通过接口层面来检查执行结果，有些不能在接口中返回的，或者接口中信息比较少的，也可以通过直接查询DB的方式来检查数据和结果。在JMeter中可以通过JDBC Request这个Sampler来实现。图2-8所示是一个具体的例子。
可以直接在其中编写SQL脚本来访问对应DB中的数据，获取到数据后可以存入变量做进一步的断言和处理。
可以嵌入执行第三方命令行可以使用OS Process Sampler和BeanShell Sampler来执行一些外部的命令、用户环境和数据的准备等功能。
文本的输入和输出JMeter的输入和输出都是文本的形式，包括界面编辑的配置存成jmx文本，需要的测试数据也可以通过文本的方式提供，另外，执行之后的结果也是存成文本的。这样的方式，方便了后续其他脚本的处理和结果的解析。
图形界面和命令行启动执行JMeter本身提供图形界面，极大地方便了用例制作和调试，不但提供请求配置和脚本编写的界面，也可以用于执行和调试，并有对应的多种形式的报告，让用例制作和调试的过程变得简单。当调试完成后，可以用命令行的方式来执行JMeter脚本，而不需要打开GUI，也方便自动化框架的封装。
工具本身非常稳定最后一点也是一个很重要的方面，因为自动化会比较频繁的执行，而且可能执行的时间比较长，所以工具和框架本身的稳定性也非常重要。JMeter作为一个开源工具，有非常广泛的用户基础，得到过比较充分的验证。新版本也在持续开发中，所以稳定性和可维护性方面比较有保障。
还有更多细节的功能这里不一一介绍了，有了上述这些特性后，就可以用于接口自动化的构建了。如果独自开发上面提到的这些功能，并在实际使用中稳定下来需要花费比较大的代价。借助已有的开源工作，围绕其做二次开发，是下面的自动化方案可以做到比较轻量级的主要原因。
2.1.2　基于JMeter的轻量接口自动化实践
有了上面这些基本的功能，接下来需要考虑如何整合成一套完整的方案，包括考虑用例的可复用和可扩展。实践中我们的基本思路如下：
用例的分层为了更好的复用和管理，我们对用例的层次进行一些划分，并给出名称的定义。单次接口请求是一个最小粒度的操作，比如下面示例中的一次HTTP请求，在以下我们称之为CGI。CGI这个词的本意是通用网关接口，由于习惯的原因，常常用来代称单个业务接口。Function是一个对外有逻辑意义的请求组合，比如提交订单、审核订单。TestCase是一个成品，TestSuite是一个用例的集合。基本的组织方式如图2-9所示。
通过这样的分层，整体逻辑就比较清楚了，CGI对于一个具体的接口是最小粒度的元素，如果接口变化了，只需要修改对应的CGI用例。Function层面是一个有逻辑意义的功能，可能需要多个CGI共同完成，相当于做了一层封装，为后面构建用例打下基础。
每个子系统的目录结构如图2-10所示。
这里有个需要注意的小地方，为了部署的时候更灵活，希望脚本中互相引用的文件是相对的路径，但是JMeter支持不太好，默认的根目录是bin，所以简单的做法是把整个自动化用例的目录复制到JMeter的bin下面。2.完整的自动化用例结构因为我们有多个系统，对应多个测试小组，大家各有专注，而整个业务又是一个长链条。Function层就是我们复用的基础，里面包含了对CGI层接口的调用。注意一点，JMeter　2.10开始建议用TestFragment来组织，而TestFragment是不能直接执行的，只是些积木，到了TestCase层面再用ThreadGroup线程组才可以执行。图2-11是一个Test Fragment的示例。
图2-12所示是一个完整的TestCase，包含了本系统和其他系统的一些Function步骤。实际多人协作的过程汇总，用例细节有很多需要规范的地方，比如命名规范，这样便于多人协作。
数据的输出JMeter里面配置和编写用例执行完了之后，需要拿到输出的结果，外层的自动化框架才能进行解析和结果的输出。这里我们通过添加一个“察看结果树”的监听器，将所有的执行结果输出到一个文本文件里面，如图2-13所示。为了解析方便，通过变量指定了一个确定的文件名，数据结果方面选择了所有的列，便于得到完整的结果并处理。
自动化的报告基于上述步骤输出的文本结果，可以编写一个解析器，把结果解析成比较易于阅读的方式。然后生成对应的报告，每次执行完成之后自动地发邮件报告出来。图2-14是一个自动化测试报告的例子。
用例执行细节查询除了上面汇总之后的结果报告，还需要一个地方能看到用例执行的细节，帮助定位问题。实际中我们构建了一个Web平台，测试人员可以在上面看到每次测试的结果，以及每个用例的执行细节。
为了更好地定位问题，需要把每个接口执行的细节也暴露出来，点击详情可以看到调用的情况，包括request和response的数据，如图2-15所示。到这里为止，一个比较完整的可以在实际项目中应用的自动化框架就完成了。在实际的运作过程中，可以对业务测试人员进行一些JMeter方面的培训，让大家熟悉如何构造接口的请求，以及断言处理等模块，然后就可以编写对应的用例了。当然，如果多个人来准备测试用例，也需要知道哪些CGI和Function级别的封装是已有的，可以复用。
可见，除了JMeter以外的框架部分的开发工作外，工作量不是很大，很多较小规模的测试团队也可以承受。综合来看，基于这样的方案可以快速地把一个可用的自动化系统构建起来。上述方案在一个项目中实践的情况如下：1）覆盖了4个大的系统，200多个CGI接口，以及100多个功能点。每个系统在构建后快速地通过以上自动化用例来进行回归，并发出邮件报告，框架整体比较稳定。2）整个过程，不算制作用例的时间，我们实际投入的测试开发的人力约为一个人/月。3）大部分业务测试人员都参与到了用例的制作，提升了对业务逻辑的理解，并且对部分人员来说，也学习了HTTP协议等基础知识，并编写了少量的脚本，提升了业务测试人员的自动化和测试开发能力。总体来说，达到了轻量化来构建接口自动化的目标。除了以上好处，也有一些不方便的地方需要指出：JMeter在包含其他的jmx脚本后，不能直接在界面显示加载的内容，所以看不到被包含的脚本里面的步骤，调试的时候不方便。不过JMeter可以支持多个实例同时运行，所以在编写和调试阶段，可以同时打开多个JMeter窗口，一定程度上可以缓解这个问题。最后的测试报告里面，不能控制显示结果的层次，是直接展开成每个接口的结果，当用例的步骤过多时查看起来不是特别方便。除了技术层面的考虑，自动化执行的过程中还有几个建议值得考虑：1）一定要强挂钩到测试和发布的环节。这一点看起来没那么重要，但是如果不希望自动化测试成为花瓶，必须要这样做。互联网产品的节奏非常快，如果自动化不能实际地在项目中发挥效果，就很容易被荒废。目前来看最合适的点是在每次自动部署后快速地把自动化用例执行一遍，这要在手工测试开始之前。这也是持续集成的思路，可以快速地发挥自动化的价值。2）报告也需要自动化地发出来，并且邮件抄送给相关的开发人员、测试人员和团队负责人。这样可以让大家快速地关注到结果。3）非100%成功的都要跟进。宁愿少而精，就像“破窗理论”指出的，如果能容忍一个用例失败，就会有2个、3个，也会让自动化慢慢失去意义。我们的做法是只要有失败，对应系统的测试负责人员需要进行定位并邮件回复出问题原因和处理措施。4）需要关注用例的细节。测试团队的负责人需要去关注用例的质量，而不只是用例的数量和执行情况，比如断言做到什么程度，哪些自动化数据是写死的，哪些参数化了，功能之间的复用情况，这些都是影响整个自动化的稳定性和可维护性的具体方面。
如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件至：yqgroup@service.aliyun.com 进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容。
用云栖社区APP，舒服~
【云栖快讯】新年大招！云栖社区为在读大学生/研究生准备了一份学（huan）习（zhuang）攻略，发布博文即有机会赢得iPad mini 4等大奖，学习换装两不误！欢迎报名参与~&&
移动测试（Mobile Testing）是为广大企业客户和移动开发者提供真机测试服务的云平台，拥有大量热门机型，...
全球领先的SaaS性能测试平台，具有强大的分布式压测能力，可模拟海量用户真实的业务场景，让应用性能问题无所遁形。
阿里云移动APP解决方案，助力开发者轻松应对移动app中随时可能出现的用户数量的爆发式增长、复杂的移动安全挑战等...
为您提供简单高效、处理能力可弹性伸缩的计算服务，帮助您快速构建更稳定、安全的应用，提升运维效率，降低 IT 成本...
Loading...App架构设计经验谈:接口的设计a year ago64收藏分享举报文章被以下专栏收录不定期更新互联网技术文章、产品研究、工具干货。{&debug&:false,&apiRoot&:&&,&paySDK&:&https:\u002F\u002Fpay.zhihu.com\u002Fapi\u002Fjs&,&wechatConfigAPI&:&\u002Fapi\u002Fwechat\u002Fjssdkconfig&,&name&:&production&,&instance&:&column&,&tokens&:{&X-XSRF-TOKEN&:null,&X-UDID&:null,&Authorization&:&oauth c3cef7c66aa9e6a1e3160e20&}}{&database&:{&Post&:{&&:{&isPending&:false,&contributes&:[{&sourceColumn&:{&lastUpdated&:,&description&:&不定期更新互联网技术知识点、总结归纳、整理开发技巧，相互学习，共同进步！\n\n不定期更新移动端的产品研究、见解、归纳。 \n\n分享当前主流的界面设计尺寸、主流平台的设计规范、主流APP的设计规范。 \n设计类干货资源整合，设计类技能教程等。&,&permission&:&COLUMN_PUBLIC&,&memberId&:,&contributePermission&:&COLUMN_PUBLIC&,&translatedCommentPermission&:&all&,&canManage&:true,&intro&:&不定期更新互联网技术文章、产品研究、工具干货。&,&urlToken&:&lishichao&,&id&:14044,&imagePath&:&v2-05a3efacf81bef39a0f44.jpg&,&slug&:&lishichao&,&applyReason&:&0&,&name&:&互联网笔记&,&title&:&互联网笔记&,&url&:&https:\u002F\u002Fzhuanlan.zhihu.com\u002Flishichao&,&commentPermission&:&COLUMN_ALL_CAN_COMMENT&,&canPost&:true,&created&:,&state&:&COLUMN_NORMAL&,&followers&:10248,&avatar&:{&id&:&v2-05a3efacf81bef39a0f44&,&template&:&https:\u002F\u002Fpic1.zhimg.com\u002F{id}_{size}.jpg&},&activateAuthorRequested&:false,&following&:false,&imageUrl&:&https:\u002F\u002Fpic1.zhimg.com\u002Fv2-05a3efacf81bef39a0f44_l.jpg&,&articlesCount&:426},&state&:&accepted&,&targetPost&:{&titleImage&:&https:\u002F\u002Fpic4.zhimg.com\u002Fv2-8a037a6a01dd8da714664_r.jpg&,&lastUpdated&:,&imagePath&:&v2-8a037a6a01dd8da714664.jpg&,&permission&:&ARTICLE_PUBLIC&,&topics&:[],&summary&:&来源：Keegan小钢 \u003Ca href=\&http:\u002F\u002Fkeeganlee.me\u002Fpost\u002Farchitecture\u002F\& data-editable=\&true\& data-title=\&App架构设计经验谈:接口的设计\&\u003EApp架构设计经验谈:接口的设计\u003C\u002Fa\u003E App与服务器的通信接口如何设计得好，需要考虑的地方挺多的，在此根据我的一些经验做一些总结分享，旨在抛砖引玉。 安全机制的设计 现在，大部分App的接口都采用RESTful架构，RESTFul最重要的一个设计原则就…&,&copyPermission&:&ARTICLE_COPYABLE&,&translatedCommentPermission&:&all&,&likes&:0,&origAuthorId&:0,&publishedTime&:&T22:19:54+08:00&,&sourceUrl&:&&,&urlToken&:,&id&:2205932,&withContent&:false,&slug&:,&bigTitleImage&:false,&title&:&App架构设计经验谈:接口的设计&,&url&:&\u002Fp\u002F&,&commentPermission&:&ARTICLE_ALL_CAN_COMMENT&,&snapshotUrl&:&&,&created&:,&comments&:0,&columnId&:14044,&content&:&&,&parentId&:0,&state&:&ARTICLE_PUBLISHED&,&imageUrl&:&https:\u002F\u002Fpic4.zhimg.com\u002Fv2-8a037a6a01dd8da714664_r.jpg&,&author&:{&bio&:&有情怀→渴望做出一款颠覆性App的代码工作者&,&isFollowing&:false,&hash&:&fd983d762fb8&,&uid&:528000,&isOrg&:false,&slug&:&amin706&,&isFollowed&:false,&description&:&
奇点日报创始人，追求产品交互和设计的产品经理一枚\n 高逼格程序员技术分享平台 → http:\u002F\u002Fwww.qidianlife.com\n『心动屋』→ 发现令您心动的好物\n『壹日程』→ 专注任务管理和待办计划提醒
\n『拾光记』→ 拾起你走过的时光\n『口袋密码』→ 安全简洁的账号管家\n『破壳日』→ 精美的生日 · 节日 · 纪念日礼物提醒工具\n 邮箱 → &,&name&:&Larry&,&profileUrl&:&https:\u002F\u002Fwww.zhihu.com\u002Fpeople\u002Famin706&,&avatar&:{&id&:&v2-a5db75ec863beb&,&template&:&https:\u002F\u002Fpic3.zhimg.com\u002F{id}_{size}.jpg&},&isOrgWhiteList&:false,&isBanned&:false},&memberId&:,&excerptTitle&:&&,&voteType&:&ARTICLE_VOTE_CLEAR&},&id&:535036}],&title&:&App架构设计经验谈:接口的设计&,&author&:&amin706&,&content&:&\u003Cp\u003E来源：Keegan小钢
\u003C\u002Fp\u003E\u003Cp\u003E\u003Ca href=\&http:\u002F\u002Flink.zhihu.com\u002F?target=http%3A\u002F\u002Fkeeganlee.me\u002Fpost\u002Farchitecture\u002F\& class=\& wrap external\& target=\&_blank\& rel=\&nofollow noreferrer\&\u003EApp架构设计经验谈:接口的设计\u003C\u002Fa\u003E\u003C\u002Fp\u003E\u003Cbr\u003E\u003Cp\u003EApp与服务器的通信接口如何设计得好，需要考虑的地方挺多的，在此根据我的一些经验做一些总结分享，旨在抛砖引玉。\u003C\u002Fp\u003E\u003Cbr\u003E\u003Ch2\u003E安全机制的设计\u003C\u002Fh2\u003E\u003Cbr\u003E\u003Cp\u003E现在，大部分App的接口都采用RESTful架构，RESTFul最重要的一个设计原则就是，客户端与服务器的交互在请求之间是无状态的，也就是说，当涉及到用户状态时，每次请求都要带上身份验证信息。实现上，大部分都采用token的认证方式，一般流程是：\u003C\u002Fp\u003E\u003Cbr\u003E\u003Cp\u003E用户用密码登录成功后，服务器返回token给客户端；\u003C\u002Fp\u003E\u003Cp\u003E客户端将token保存在本地，发起后续的相关请求时，将token发回给服务器；\u003C\u002Fp\u003E\u003Cp\u003E服务器检查token的有效性，有效则返回数据，若无效，分两种情况：\u003C\u002Fp\u003E\u003Cp\u003Etoken错误，这时需要用户重新登录，获取正确的token\u003C\u002Fp\u003E\u003Cp\u003Etoken过期，这时客户端需要再发起一次认证请求，获取新的token\u003C\u002Fp\u003E\u003Cbr\u003E\u003Cp\u003E然而，此种验证方式存在一个安全性问题：当登录接口被劫持时，黑客就获取到了用户密码和token，后续则可以对该用户做任何事情了。用户只有修改密码才能夺回控制权。\u003C\u002Fp\u003E\u003Cbr\u003E\u003Cp\u003E如何优化呢？第一种解决方案是采用HTTPS。HTTPS在HTTP的基础上添加了SSL安全协议，自动对数据进行了压缩加密，在一定程序可以防止监听、防止劫持、防止重发，安全性可以提高很多。不过，SSL也不是绝对安全的，也存在被劫持的可能。另外，服务器对HTTPS的配置相对有点复杂，还需要到CA申请证书，而且一般还是收费的。而且，HTTPS效率也比较低。一般，只有安全要求比较高的系统才会采用HTTPS，比如银行。而大部分对安全要求没那么高的App还是采用HTTP的方式。\u003C\u002Fp\u003E\u003Cbr\u003E\u003Cp\u003E我们目前的做法是给每个接口都添加签名。给客户端分配一个密钥，每次请求接口时，将密钥和所有参数组合成源串，根据签名算法生成签名值，发送请求时将签名一起发送给服务器验证。类似的实现可参考OAuth1.0的签名算法。这样，黑客不知道密钥，不知道签名算法，就算拦截到登录接口，后续请求也无法成功操作。不过，因为签名算法比较麻烦，而且容易出错，只适合对内的接口。如果你们的接口属于开放的API，则不太适合这种签名认证的方式了，建议还是使用OAuth2.0的认证机制。\u003C\u002Fp\u003E\u003Cbr\u003E\u003Cp\u003E我们也给每个端分配一个appKey，比如Android、iOS、微信三端，每个端分别分配一个appKey和一个密钥。没有传appKey的请求将报错，传错了appKey的请求也将报错。这样，安全性方面又加多了一层防御，同时也方便对不同端做一些不同的处理策略。\u003C\u002Fp\u003E\u003Cbr\u003E\u003Cp\u003E另外，现在越来越多App取消了密码登录，而采用手机号+短信验证码的登录方式，我在当前的项目中也采用了这种登录方式。这种登录方式有几种好处：\u003C\u002Fp\u003E\u003Cbr\u003E\u003Cp\u003E不需要注册，不需要修改密码，也不需要因为忘记密码而重置密码的操作了；\u003C\u002Fp\u003E\u003Cp\u003E用户不再需要记住密码了，也不怕密码泄露的问题了；\u003C\u002Fp\u003E\u003Cp\u003E相对于密码登录其安全性明显提高了。\u003C\u002Fp\u003E\u003Ch2\u003E接口数据的设计\u003C\u002Fh2\u003E\u003Cbr\u003E\u003Cp\u003E接口的数据一般都采用JSON格式进行传输，不过，需要注意的是，JSON的值只有六种数据类型：\u003C\u002Fp\u003E\u003Cbr\u003E\u003Cp\u003ENumber：整数或浮点数\u003C\u002Fp\u003E\u003Cp\u003EString：字符串\u003C\u002Fp\u003E\u003Cp\u003EBoolean：true 或 false\u003C\u002Fp\u003E\u003Cp\u003EArray：数组包含在方括号[]中\u003C\u002Fp\u003E\u003Cp\u003EObject：对象包含在大括号{}中\u003C\u002Fp\u003E\u003Cp\u003ENull：空类型\u003C\u002Fp\u003E\u003Cbr\u003E\u003Cp\u003E所以，传输的数据类型不能超过这六种数据类型。以前，我们曾经试过传输Date类型，它会转为类似于”日 09时17分42秒 GMT+08:00″这样的字符串，这在转换时会产生问题，不同的解析库解析方式可能不同，有的可能会转乱，有的可能直接异常了。要避免出错，必须做特殊处理，自己手动去做解析。为了根除这种问题，最好的解决方案是用毫秒数表示日期。\u003C\u002Fp\u003E\u003Cbr\u003E\u003Cp\u003E另外，以前的项目中还出现过字符串的”true”和”false”，或者字符串的数字，甚至还出现过字符串的”null”，导致解析错误，尤其是”null”，导致App奔溃，后来查了好久才查出来是该问题导致的。这都是因为服务端对数据没处理好，导致有些数据转为了字符串。所以，在客户端，也不能完全信任服务端传回的数据都是对的，需要对所有异常情况都做相应处理。\u003C\u002Fp\u003E\u003Cbr\u003E\u003Cp\u003E服务器返回的数据结构，一般为：\u003C\u002Fp\u003E\u003Cbr\u003E\u003Cp\u003E{\u003C\u002Fp\u003E\u003Cp\u003E
code：0\u003C\u002Fp\u003E\u003Cp\u003E
message: \&success\&\u003C\u002Fp\u003E\u003Cp\u003E
data: { key1: value1, key2: value2, ... }\u003C\u002Fp\u003E\u003Cp\u003E}\u003C\u002Fp\u003E\u003Cbr\u003E\u003Cp\u003Ecode: 状态码，0表示成功，非0表示各种不同的错误\u003C\u002Fp\u003E\u003Cp\u003Emessage: 描述信息，成功时为”success”，错误时则是错误信息\u003C\u002Fp\u003E\u003Cp\u003Edata: 成功时返回的数据，类型为对象或数据\u003C\u002Fp\u003E\u003Cbr\u003E\u003Cp\u003E不同错误需要定义不同的状态码，属于客户端的错误和服务端的错误也要区分，比如1XX表示客户端的错误，2XX表示服务端的错误。这里举几个例子：\u003C\u002Fp\u003E\u003Cbr\u003E\u003Cp\u003E0：成功\u003C\u002Fp\u003E\u003Cp\u003E100：请求错误\u003C\u002Fp\u003E\u003Cp\u003E101：缺少appKey\u003C\u002Fp\u003E\u003Cp\u003E102：缺少签名\u003C\u002Fp\u003E\u003Cp\u003E103：缺少参数\u003C\u002Fp\u003E\u003Cp\u003E200：服务器出错\u003C\u002Fp\u003E\u003Cp\u003E201：服务不可用\u003C\u002Fp\u003E\u003Cp\u003E202：服务器正在重启\u003C\u002Fp\u003E\u003Cbr\u003E\u003Cp\u003E错误信息一般有两种用途：一是客户端开发人员调试时看具体是什么错误；二是作为App错误提示直接展示给用户看。主要还是作为App错误提示，直接展示给用户看的。所以，大部分都是简短的提示信息。\u003C\u002Fp\u003E\u003Cbr\u003E\u003Cp\u003Edata字段只在请求成功时才会有数据返回的。数据类型限定为对象或数组，当请求需要的数据为单个对象时则传回对象，当请求需要的数据是列表时，则为某个对象的数组。这里需要注意的就是，不要将data传入字符串或数字，即使请求需要的数据只有一个，比如token，那返回的data应该为：\u003C\u002Fp\u003E\u003Cbr\u003E\u003Cp\u003E\u002F\u002F 正确\u003C\u002Fp\u003E\u003Cp\u003Edata: { token: 123456 }\u003C\u002Fp\u003E\u003Cp\u003E\u002F\u002F 错误\u003C\u002Fp\u003E\u003Cp\u003Edata: 3C\u002Fp\u003E\u003Cbr\u003E\u003Cp\u003E\u003Cstrong\u003E接口版本的设计\u003C\u002Fstrong\u003E\u003Cbr\u003E\u003C\u002Fp\u003E\u003Cbr\u003E\u003Cp\u003E接口不可能一成不变，在不停迭代中，总会发生变化。接口的变化一般会有几种：\u003C\u002Fp\u003E\u003Cbr\u003E\u003Cp\u003E数据的变化，比如增加了旧版本不支持的数据类型\u003C\u002Fp\u003E\u003Cp\u003E参数的变化，比如新增了参数\u003C\u002Fp\u003E\u003Cp\u003E接口的废弃，不再使用该接口了\u003C\u002Fp\u003E\u003Cbr\u003E\u003Cp\u003E为了适应这些变化，必须得做接口版本的设计。实现上，一般有两种做法：\u003C\u002Fp\u003E\u003Cbr\u003E\u003Cp\u003E每个接口有各自的版本，一般为接口添加个version的参数。\u003C\u002Fp\u003E\u003Cp\u003E整个接口系统有统一的版本，一般在URL中添加版本号，比如\u003Ca href=\&http:\u002F\u002Flink.zhihu.com\u002F?target=http%3A\u002F\u002Fapi.domain.com\u002Fv2\& class=\& external\& target=\&_blank\& rel=\&nofollow noreferrer\&\u003E\u003Cspan class=\&invisible\&\u003Ehttp:\u002F\u002F\u003C\u002Fspan\u003E\u003Cspan class=\&visible\&\u003Eapi.domain.com\u002Fv2\u003C\u002Fspan\u003E\u003Cspan class=\&invisible\&\u003E\u003C\u002Fspan\u003E\u003C\u002Fa\u003E。\u003C\u002Fp\u003E\u003Cbr\u003E\u003Cp\u003E大部分情况下会采用第一种方式，当某一个接口有变动时，在这个接口上叠加版本号，并兼容旧版本。App的新版本开发传参时则将传入新版本的version。\u003C\u002Fp\u003E\u003Cbr\u003E\u003Cp\u003E如果整个接口系统的根基都发生变动的话，比如微博API，从OAuth1.0升级到OAuth2.0，整个API都进行了升级。\u003C\u002Fp\u003E\u003Cbr\u003E\u003Cp\u003E有时候，一个接口的变动还会影响到其他接口，但做的时候不一定能发现。因此，最好还要有一套完善的测试机制保证每次接口变更都能测试到所有相关层面。\u003C\u002Fp\u003E\u003Cbr\u003E\u003Ch2\u003E写在最后\u003C\u002Fh2\u003E\u003Cbr\u003E\u003Cp\u003E关于接口设计，暂时想到的就这么多了。各位看官看完觉得有遗漏或有哪些需要优化的欢迎提出一起讨论。\u003C\u002Fp\u003E\u003Cp\u003E\u003Ca href=\&http:\u002F\u002Flink.zhihu.com\u002F?target=http%3A\u002F\u002Fkeeganlee.me\u002Fpost\u002Farchitecture\u002F\& class=\& wrap external\& target=\&_blank\& rel=\&nofollow noreferrer\&\u003E阅读原文\u003C\u002Fa\u003E\u003C\u002Fp\u003E&,&updated&:new Date(&T14:19:54.000Z&),&canComment&:false,&commentPermission&:&anyone&,&commentCount&:9,&collapsedCount&:0,&likeCount&:64,&state&:&published&,&isLiked&:false,&slug&:&&,&isTitleImageFullScreen&:false,&rating&:&none&,&titleImage&:&https:\u002F\u002Fpic4.zhimg.com\u002Fv2-8a037a6a01dd8da714664_r.jpg&,&links&:{&comments&:&\u002Fapi\u002Fposts\u002F2Fcomments&},&reviewers&:[],&topics&:[{&url&:&https:\u002F\u002Fwww.zhihu.com\u002Ftopic\u002F&,&id&:&&,&name&:&软件架构&},{&url&:&https:\u002F\u002Fwww.zhihu.com\u002Ftopic\u002F&,&id&:&&,&name&:&应用程序（Application）&}],&adminClosedComment&:false,&titleImageSize&:{&width&:750,&height&:340},&href&:&\u002Fapi\u002Fposts\u002F&,&excerptTitle&:&&,&column&:{&slug&:&lishichao&,&name&:&互联网笔记&},&tipjarState&:&inactivated&,&annotationAction&:[],&sourceUrl&:&&,&pageCommentsCount&:9,&hasPublishingDraft&:false,&snapshotUrl&:&&,&publishedTime&:&T22:19:54+08:00&,&url&:&\u002Fp\u002F&,&lastestLikers&:[{&bio&:&产品策划&,&isFollowing&:false,&hash&:&ccff5b38c80&,&uid&:489600,&isOrg&:false,&slug&:&zaifan&,&isFollowed&:false,&description&:&2018应届生&,&name&:&在凡&,&profileUrl&:&https:\u002F\u002Fwww.zhihu.com\u002Fpeople\u002Fzaifan&,&avatar&:{&id&:&v2-a73f38a169f470c221a4d1b&,&template&:&https:\u002F\u002Fpic4.zhimg.com\u002F{id}_{size}.jpg&},&isOrgWhiteList&:false,&isBanned&:false},{&bio&:&INFP&,&isFollowing&:false,&hash&:&836baed7d7ad771d9b7ac53&,&uid&:84,&isOrg&:false,&slug&:&pan-qi-95&,&isFollowed&:false,&description&:&VIEW\n\n生命在于折腾\n\n做的每一件事总有一天会反馈给你\n\n习惯主宰一生，培养良好的习惯最重要\n\n终生学习者&,&name&:&潘琦&,&profileUrl&:&https:\u002F\u002Fwww.zhihu.com\u002Fpeople\u002Fpan-qi-95&,&avatar&:{&id&:&d&,&template&:&https:\u002F\u002Fpic2.zhimg.com\u002F{id}_{size}.jpg&},&isOrgWhiteList&:false,&isBanned&:false},{&bio&:&产品经理&,&isFollowing&:false,&hash&:&ee0ea9f2b1e5218baddae15d2c5cd55a&,&uid&:765800,&isOrg&:false,&slug&:&xing-kong-55-41-42&,&isFollowed&:false,&description&:&&,&name&:&星空&,&profileUrl&:&https:\u002F\u002Fwww.zhihu.com\u002Fpeople\u002Fxing-kong-55-41-42&,&avatar&:{&id&:&v2-efbbbde&,&template&:&https:\u002F\u002Fpic2.zhimg.com\u002F{id}_{size}.jpg&},&isOrgWhiteList&:false,&isBanned&:false},{&bio&:&&,&isFollowing&:false,&hash&:&b4bf6968380&,&uid&:60,&isOrg&:false,&slug&:&cao-mo-97&,&isFollowed&:false,&description&:&&,&name&:&红猪&,&profileUrl&:&https:\u002F\u002Fwww.zhihu.com\u002Fpeople\u002Fcao-mo-97&,&avatar&:{&id&:&3524908fdce9cd54caad5f&,&template&:&https:\u002F\u002Fpic2.zhimg.com\u002F{id}_{size}.jpg&},&isOrgWhiteList&:false,&isBanned&:false},{&bio&:&&,&isFollowing&:false,&hash&:&64fc19e9edb837e1e13f5f9&,&uid&:52,&isOrg&:false,&slug&:&gao-shi-jun-2&,&isFollowed&:false,&description&:&&,&name&:&无状态&,&profileUrl&:&https:\u002F\u002Fwww.zhihu.com\u002Fpeople\u002Fgao-shi-jun-2&,&avatar&:{&id&:&v2-49be232fabab2bb189f14b3&,&template&:&https:\u002F\u002Fpic2.zhimg.com\u002F{id}_{size}.jpg&},&isOrgWhiteList&:false,&isBanned&:false}],&summary&:&来源：Keegan小钢 \u003Ca href=\&http:\u002F\u002Fkeeganlee.me\u002Fpost\u002Farchitecture\u002F\& data-editable=\&true\& data-title=\&App架构设计经验谈:接口的设计\&\u003EApp架构设计经验谈:接口的设计\u003C\u002Fa\u003E App与服务器的通信接口如何设计得好，需要考虑的地方挺多的，在此根据我的一些经验做一些总结分享，旨在抛砖引玉。 安全机制的设计 现在，大部分App的接口都采用RESTful架构，RESTFul最重要的一个设计原则就…&,&reviewingCommentsCount&:0,&meta&:{&previous&:{&isTitleImageFullScreen&:false,&rating&:&none&,&titleImage&:&https:\u002F\u002Fpic7.zhimg.com\u002F50\u002Fv2-f6ee577c_xl.jpg&,&links&:{&comments&:&\u002Fapi\u002Fposts\u002F2Fcomments&},&topics&:[{&url&:&https:\u002F\u002Fwww.zhihu.com\u002Ftopic\u002F&,&id&:&&,&name&:&信息技术（IT）&},{&url&:&https:\u002F\u002Fwww.zhihu.com\u002Ftopic\u002F&,&id&:&&,&name&:&IT 行业&},{&url&:&https:\u002F\u002Fwww.zhihu.com\u002Ftopic\u002F&,&id&:&&,&name&:&IT 工程师&}],&adminClosedComment&:false,&href&:&\u002Fapi\u002Fposts\u002F&,&excerptTitle&:&&,&author&:{&bio&:&有情怀→渴望做出一款颠覆性App的代码工作者&,&isFollowing&:false,&hash&:&fd983d762fb8&,&uid&:528000,&isOrg&:false,&slug&:&amin706&,&isFollowed&:false,&description&:&
奇点日报创始人，追求产品交互和设计的产品经理一枚\n 高逼格程序员技术分享平台 → http:\u002F\u002Fwww.qidianlife.com\n『心动屋』→ 发现令您心动的好物\n『壹日程』→ 专注任务管理和待办计划提醒
\n『拾光记』→ 拾起你走过的时光\n『口袋密码』→ 安全简洁的账号管家\n『破壳日』→ 精美的生日 · 节日 · 纪念日礼物提醒工具\n 邮箱 → &,&name&:&Larry&,&profileUrl&:&https:\u002F\u002Fwww.zhihu.com\u002Fpeople\u002Famin706&,&avatar&:{&id&:&v2-a5db75ec863beb&,&template&:&https:\u002F\u002Fpic3.zhimg.com\u002F{id}_{size}.jpg&},&isOrgWhiteList&:false,&isBanned&:false},&column&:{&slug&:&lishichao&,&name&:&互联网笔记&},&content&:&\u003Cp\u003E怕看见父母一年比一年老去\u003C\u002Fp\u003E\u003Cfigure\u003E\u003Cimg src=\&https:\u002F\u002Fpic2.zhimg.com\u002Fv2-99675ccb3edff882bb59a_b.jpg\& data-rawwidth=\&640\& data-rawheight=\&341\& class=\&origin_image zh-lightbox-thumb\& width=\&640\& data-original=\&https:\u002F\u002Fpic2.zhimg.com\u002Fv2-99675ccb3edff882bb59a_r.jpg\&\u003E\u003C\u002Ffigure\u003E\u003Cbr\u003E\u003Cp\u003E怕问干啥工作的？\u003C\u002Fp\u003E\u003Cfigure\u003E\u003Cimg src=\&https:\u002F\u002Fpic3.zhimg.com\u002Fv2-42e4ff129a488f0cfb07b80_b.jpg\& data-rawwidth=\&640\& data-rawheight=\&348\& class=\&origin_image zh-lightbox-thumb\& width=\&640\& data-original=\&https:\u002F\u002Fpic3.zhimg.com\u002Fv2-42e4ff129a488f0cfb07b80_r.jpg\&\u003E\u003C\u002Ffigure\u003E\u003Cbr\u003E\u003Cbr\u003E\u003Cp\u003E怕一个人的孤单\u003C\u002Fp\u003E\u003Cfigure\u003E\u003Cimg src=\&https:\u002F\u002Fpic3.zhimg.com\u002Fv2-f7a249eaaffa9ebec0dd0_b.jpg\& data-rawwidth=\&640\& data-rawheight=\&289\& class=\&origin_image zh-lightbox-thumb\& width=\&640\& data-original=\&https:\u002F\u002Fpic3.zhimg.com\u002Fv2-f7a249eaaffa9ebec0dd0_r.jpg\&\u003E\u003C\u002Ffigure\u003E\u003Cbr\u003E\u003Cbr\u003E\u003Cp\u003E怕亲戚问收入\u003C\u002Fp\u003E\u003Cfigure\u003E\u003Cimg src=\&https:\u002F\u002Fpic3.zhimg.com\u002Fv2-748b4bcdd10c5daf078a66_b.jpg\& data-rawwidth=\&640\& data-rawheight=\&318\& class=\&origin_image zh-lightbox-thumb\& width=\&640\& data-original=\&https:\u002F\u002Fpic3.zhimg.com\u002Fv2-748b4bcdd10c5daf078a66_r.jpg\&\u003E\u003C\u002Ffigure\u003E\u003Cbr\u003E\u003Cp\u003E怕躺在床上没信号\u003C\u002Fp\u003E\u003Cfigure\u003E\u003Cimg src=\&https:\u002F\u002Fpic3.zhimg.com\u002Fv2-4da3aa0ddf7cf340c7f3ee1_b.jpg\& data-rawwidth=\&640\& data-rawheight=\&441\& class=\&origin_image zh-lightbox-thumb\& width=\&640\& data-original=\&https:\u002F\u002Fpic3.zhimg.com\u002Fv2-4da3aa0ddf7cf340c7f3ee1_r.jpg\&\u003E\u003C\u002Ffigure\u003E\u003Cbr\u003E\u003Cp\u003E怕客户出故障\u003C\u002Fp\u003E\u003Cfigure\u003E\u003Cimg src=\&https:\u002F\u002Fpic3.zhimg.com\u002Fv2-65a35b7ae35d64d31ebfe17b984e4299_b.jpg\& data-rawwidth=\&640\& data-rawheight=\&441\& class=\&origin_image zh-lightbox-thumb\& width=\&640\& data-original=\&https:\u002F\u002Fpic3.zhimg.com\u002Fv2-65a35b7ae35d64d31ebfe17b984e4299_r.jpg\&\u003E\u003C\u002Ffigure\u003E\u003Cbr\u003E\u003Cp\u003E怕把没完成的工作带回家，让爸妈担心\u003C\u002Fp\u003E\u003Cfigure\u003E\u003Cimg src=\&https:\u002F\u002Fpic1.zhimg.com\u002Fv2-e533ccd79cce7ac8643eeab1fa7fad36_b.jpg\& data-rawwidth=\&640\& data-rawheight=\&390\& class=\&origin_image zh-lightbox-thumb\& width=\&640\& data-original=\&https:\u002F\u002Fpic1.zhimg.com\u002Fv2-e533ccd79cce7ac8643eeab1fa7fad36_r.jpg\&\u003E\u003C\u002Ffigure\u003E\u003Cbr\u003E\u003Cbr\u003E\u003Cp\u003E怕遇到曾经爱过的人\u003C\u002Fp\u003E\u003Cfigure\u003E\u003Cimg src=\&https:\u002F\u002Fpic3.zhimg.com\u002Fv2-8e3520defdd32f_b.jpg\& data-rawwidth=\&640\& data-rawheight=\&418\& class=\&origin_image zh-lightbox-thumb\& width=\&640\& data-original=\&https:\u002F\u002Fpic3.zhimg.com\u002Fv2-8e3520defdd32f_r.jpg\&\u003E\u003C\u002Ffigure\u003E\u003Cbr\u003E\u003Cp\u003E怕离别时妈妈的眼泪\u003C\u002Fp\u003E\u003Cfigure\u003E\u003Cimg src=\&https:\u002F\u002Fpic1.zhimg.com\u002Fv2-a5a975a9532dfc0ada42_b.jpg\& data-rawwidth=\&640\& data-rawheight=\&310\& class=\&origin_image zh-lightbox-thumb\& width=\&640\& data-original=\&https:\u002F\u002Fpic1.zhimg.com\u002Fv2-a5a975a9532dfc0ada42_r.jpg\&\u003E\u003C\u002Ffigure\u003E\u003Cbr\u003E\u003Cp\u003E虽然我很怕过年回家\u003C\u002Fp\u003E\u003Cp\u003E但我更怕过年回不了家\u003C\u002Fp\u003E\u003Cbr\u003E\u003Cp\u003E▼\u003C\u002Fp\u003E\u003Cbr\u003E\u003Cp\u003E怕高铁的票抢不到\u003C\u002Fp\u003E\u003Cp\u003E怕航班延误晚点\u003C\u002Fp\u003E\u003Cp\u003E怕预定的专车司机会爽约\u003C\u002Fp\u003E\u003Cp\u003E怕挤不上公交地铁\u003C\u002Fp\u003E\u003Cp\u003E怕堵在高速路上看风景\u003C\u002Fp\u003E\u003Cp\u003E怕晕船的老毛病又犯\u003C\u002Fp\u003E\u003Cp\u003E怕崎岖的山路十八弯\u003C\u002Fp\u003E\u003Cbr\u003E\u003Cp\u003E但是\u003C\u002Fp\u003E\u003Cp\u003E跨越千山万水，我们也要回家\u003C\u002Fp\u003E\u003Cp\u003E我知道，回家的路并不孤单\u003C\u002Fp\u003E\u003Cp\u003E▼\u003C\u002Fp\u003E\u003Cp\u003E和无数张总、王总、李工、赵工一起\u003C\u002Fp\u003E\u003Cp\u003E和无数Tony、Michael、Lily、Andy一起\u003C\u002Fp\u003E\u003Cp\u003E\u003Ca href=\&https:\u002F\u002Flink.zhihu.com\u002F?target=http%3A\u002F\u002Fmp.weixin.qq.com\u002Fs%3F__biz%3DMzI3MzAzNDAyMQ%3D%3D%26mid%3D%26idx%3D1%26sn%3Df743b222a0a6fchksm%3Df0ba7264c7cdfb6a6bf1ce33589def6efd%26mpshare%3D1%26scene%3D23%26srcid%3D0122JflRlKCOTexXHf9ajmgx%23rd\& class=\& wrap external\& target=\&_blank\& rel=\&nofollow noreferrer\&\u003E阅读原文\u003C\u002Fa\u003E\u003C\u002Fp\u003E&,&state&:&published&,&sourceUrl&:&&,&pageCommentsCount&:0,&canComment&:false,&snapshotUrl&:&&,&slug&:,&publishedTime&:&T23:29:31+08:00&,&url&:&\u002Fp\u002F&,&title&:&IT人为什么怕回家过年？&,&summary&:&怕看见父母一年比一年老去 怕问干啥工作的？ 怕一个人的孤单 怕亲戚问收入 怕躺在床上没信号 怕客户出故障 怕把没完成的工作带回家，让爸妈担心 怕遇到曾经爱过的人 怕离别时妈妈的眼泪 虽然我很怕过年回家但我更怕过年回不了家 ▼ 怕高铁的票抢不到怕航班…&,&reviewingCommentsCount&:0,&meta&:{&previous&:null,&next&:null},&commentPermission&:&anyone&,&commentsCount&:108,&likesCount&:600},&next&:{&isTitleImageFullScreen&:false,&rating&:&none&,&titleImage&:&&,&links&:{&comments&:&\u002Fapi\u002Fposts\u002F2Fcomments&},&topics&:[{&url&:&https:\u002F\u002Fwww.zhihu.com\u002Ftopic\u002F&,&id&:&&,&name&:&技术选型&}],&adminClosedComment&:false,&href&:&\u002Fapi\u002Fposts\u002F&,&excerptTitle&:&&,&author&:{&bio&:&有情怀→渴望做出一款颠覆性App的代码工作者&,&isFollowing&:false,&hash&:&fd983d762fb8&,&uid&:528000,&isOrg&:false,&slug&:&amin706&,&isFollowed&:false,&description&:&
奇点日报创始人，追求产品交互和设计的产品经理一枚\n 高逼格程序员技术分享平台 → http:\u002F\u002Fwww.qidianlife.com\n『心动屋』→ 发现令您心动的好物\n『壹日程』→ 专注任务管理和待办计划提醒
\n『拾光记』→ 拾起你走过的时光\n『口袋密码』→ 安全简洁的账号管家\n『破壳日』→ 精美的生日 · 节日 · 纪念日礼物提醒工具\n 邮箱 → &,&name&:&Larry&,&profileUrl&:&https:\u002F\u002Fwww.zhihu.com\u002Fpeople\u002Famin706&,&avatar&:{&id&:&v2-a5db75ec863beb&,&template&:&https:\u002F\u002Fpic3.zhimg.com\u002F{id}_{size}.jpg&},&isOrgWhiteList&:false,&isBanned&:false},&column&:{&slug&:&lishichao&,&name&:&互联网笔记&},&content&:&\u003Cblockquote\u003E\u003Cp\u003E\u003Ca href=\&https:\u002F\u002Flink.zhihu.com\u002F?target=http%3A\u002F\u002Fmp.weixin.qq.com\u002Fs%3F__biz%3DMzA5Nzc4OTA1Mw%3D%3D%26mid%3D%26idx%3D1%26sn%3Def5bc2cd7e7b27c19b8fae5%26chksm%3D8be9974abc9e1e5c94217f4bcf5c5c3c18d8a98d1b4cfb4d386cf9da84%26mpshare%3D1%26scene%3D23%26srcid%3D0206KrF78w32RJiuu07zAU2H%23rd\& class=\& wrap external\& target=\&_blank\& rel=\&nofollow noreferrer\&\u003E技术选型最怕的是什么？\u003C\u002Fa\u003E\u003Cbr\u003E\u003C\u002Fp\u003E\u003Cp\u003E作者｜ 一乐\u003C\u002Fp\u003E\u003Cp\u003E个人微信一乐来了，id是yilecoming，欢迎关注。\u003C\u002Fp\u003E\u003C\u002Fblockquote\u003E\u003Cbr\u003E\u003Cp\u003E这也许是我上半年最大的欠账，在去普吉的飞机上突发无聊，想想还了这债吧。\u003Cbr\u003E\u003C\u002Fp\u003E\u003Cp\u003E去年的时候，我们使用Cassandra出了一次问题，定位加修复用了一晚上。当我把经历发出来的时候，收到了下面一段话：\u003Cbr\u003E\u003C\u002Fp\u003E\u003Cp\u003E“一个开源产品，连官方文档都没看完大半，然后匆匆忙忙上生产环境，出了问题团团转。若是不能掌控就先不要玩，说回这Cassandra的例子，在对它不了解的情况下，仅通过Google就能解决问题，不正说明它不难掌握有大量资料可查吗，实在不行还能翻代码。”\u003C\u002Fp\u003E\u003Cp\u003E我现在都不知道这位神仙从哪里看到的匆匆忙忙上和团团转，当时我还是忍了，因为实在太忙，口水又没那么多。当然我思考了很多，这就是你现在看到的文章。我相信它会有一些价值，毕竟有些事情有的人你不告诉他，他永远不可能知道。比如个体认知的局限，比如口无遮拦的损失，比如做事之人才会有的思考角度\u003C\u002Fp\u003E\u003Cp\u003E本文讲的是技术选型。\u003C\u002Fp\u003E\u003Cp\u003E大多数技术都存在选型问题，因为技术的发展已经让一件事情可以有多种解决方案，选型问题就自然出现。前段时间也有人说过语言选型，这里举的例子是在组件、框架、服务的范畴。其中有相通之处，各位可以自行领会。\u003C\u002Fp\u003E\u003Cbr\u003E\u003Cp\u003E\u003Cstrong\u003E选型最怕什么\u003C\u002Fstrong\u003E\u003C\u002Fp\u003E\u003Cp\u003E怕失败么？那肯定的。你的服务崩溃，用户愤而投诉，客户电话打到老板那里，明天你要洗干净到办公室去一趟（笑...）。而所有对失败的无法容忍，最终都会变成一句话，为什么你要选这个型？\u003C\u002Fp\u003E\u003Cp\u003E你总要回答这个问题，所以选型一怕随意，公鸡头母鸡头，选上哪头是哪头；二怕凭感觉，某某已经在用听起来还不错。你需要真正的思考，而且尽可能的全面。我下文会详细讲解，但这还不是最怕的。\u003C\u002Fp\u003E\u003Cp\u003E最怕的是什么？看看本文开头引用的那句话，你体会一下。\u003C\u002Fp\u003E\u003Cp\u003E嗯，最怕的是喷子。怕任意总结，如果再加上一些诋毁，一次选型失败足以让人心碎一万次。\u003C\u002Fp\u003E\u003Cp\u003E失败不可怕，可怕的是没有总结，因为没有总结就没有提高。而比没有总结更可怕的是乱总结。\u003C\u002Fp\u003E\u003Cp\u003E为了方便理解，我再帮你换个角度。你天天在河边走，一次不小心湿了鞋。如果是本文说的这种人，那肯定要说：\u003C\u002Fp\u003E\u003Cp\u003E一条公共的河，你连旱季旺季都没搞清楚，就匆匆忙忙跑过来散步，湿了鞋还到处讲。若是脚不行就别在这玩，说回这条河，湿了鞋就能爬上来，不正说明他水不深么。\u003Cbr\u003E\u003C\u002Fp\u003E\u003Cp\u003E这种人实在不算少见。他说的每一句话都有一点道理，但都跟事情的本质毫无关系，每一句话又都掺加了嘲讽，来体现那无处安放的莫名优越感。而所有的这些，对于解决问题和后续提高通常毫无帮助。\u003C\u002Fp\u003E\u003Cp\u003E想想也真遗憾，人生本是如此美好，有的人却硬生生地活成了奇葩。\u003C\u002Fp\u003E\u003Cbr\u003E\u003Cp\u003E\u003Cstrong\u003E选型需要什么\u003C\u002Fstrong\u003E\u003C\u002Fp\u003E\u003Cp\u003E言归正传，我认为有三点不可或缺：分析、实验和胆量。\u003Cbr\u003E\u003C\u002Fp\u003E\u003Cbr\u003E\u003Cp\u003E\u003Cstrong\u003E分析\u003C\u002Fstrong\u003E\u003C\u002Fp\u003E\u003Cp\u003E分析主要有定性分析和定量分析。实际操作中，前者主要针对的是模型维度的估计，用来考虑一个组件是否有可能达到它宣称的目的，后者主要用来验证，用来确认它是否在真的做到了。\u003C\u002Fp\u003E\u003Cp\u003E比如在语言选型时，你要考虑它的范型、内存模型和并发设计；数据库选型时你要考虑存储模型、支撑量级、成本开销；开源项目要考虑它的社区发展、文档完善程度；如果是库或者中间件，还要考虑他的易用性、灵活性以及可替代性，等等。\u003C\u002Fp\u003E\u003Cp\u003E需要说明的一点是，我个人并不觉得阅读全部源码或者文档这种事情是必须的，这不局限在OS、VM层面。不仅因为这样的事情会耗费过多精力，而且受制于代码以及文档质量，就算真正阅读完毕也未必意味着完全领会。\u003C\u002Fp\u003E\u003Cp\u003E这些都是定性的，而定性的东西就有可能存在理解偏差。一个库可以完成工作，并不代表它在高并发压力下依然表现正常；一个语言做到了自动管理内存，并不代表他能做得很好没有副作用；一件事情设计者觉得达到了目标并不代表能够满足使用者期望。因此我们还需要量化分析，也就是一直口口相传的，用数据说话。\u003C\u002Fp\u003E\u003Cp\u003E量化分析需要你构建或使用现成的工具和数据集，对服务进行特定场景下的分析。通过提高压力、增加容量或者针对性的测试，来验证之前的定性分析是否达到预期，并分析不同技术之间的差异和表现。\u003C\u002Fp\u003E\u003Cbr\u003E\u003Cp\u003E\u003Cstrong\u003E实验\u003C\u002Fstrong\u003E\u003C\u002Fp\u003E\u003Cp\u003E量化分析可以为真正的实验做一些准备和帮助，但是实验要走的明显更远。到了这一步，意味着要在真正的业务场景下进行验证，这跟量化分析中通用性场景有所不同。\u003C\u002Fp\u003E\u003Cp\u003E在真正的业务中采用需要很多细致和琐碎的工作，除此之外，还要构建自己的测试工具集，这需要非常扎实的业务理解能力和勤奋的工作。而所有这些，你需要在开发环境做一次，在沙箱环境做一次，然后在仿真环境再做一次。\u003C\u002Fp\u003E\u003Cp\u003E这几步经常被简化，但经验告诉我们，如果你想做一个高可用的系统，你就不应该少走任何一步。\u003C\u002Fp\u003E\u003Cblockquote\u003E\u003Cp\u003E步子大了，容易扯到蛋。\u003C\u002Fp\u003E\u003C\u002Fblockquote\u003E\u003Cbr\u003E\u003Cp\u003E\u003Cstrong\u003E胆量\u003C\u002Fstrong\u003E\u003C\u002Fp\u003E\u003Cp\u003E实验做完，剩下的就是上线，但这一步有很多人跨不过去。因为就算做了再多准备，你依然不敢说百分百保证没问题。现实情况是，80%的线上问题都是升级或者上线引起的。\u003C\u002Fp\u003E\u003Cp\u003E你需要胆量。\u003C\u002Fp\u003E\u003Cp\u003E这不是说要硬着头皮做，人家都是艺高才胆大。所以为了让胆子大一点，你首先需要考虑降级和开关。从最悲观的角度来重新审视整个方案，如果升级出现问题怎么办，如何才能让出现的问题影响最小化。\u003C\u002Fp\u003E\u003Cp\u003E而只要弄完了这些，也就只要再记住一句话就行：\u003C\u002Fp\u003E\u003Cblockquote\u003E\u003Cp\u003E你行你上呀！\u003C\u002Fp\u003E\u003C\u002Fblockquote\u003E\u003Cbr\u003E\u003Cp\u003E\u003Cstrong\u003E对技术服务的提醒\u003C\u002Fstrong\u003E\u003C\u002Fp\u003E\u003Cp\u003E\u003Cstrong\u003E得到认可\u003C\u002Fstrong\u003E\u003C\u002Fp\u003E\u003Cp\u003E刚才在胆量里没说的一点。我们经常会看到，一项新技术在公司内久久难以推行，因为业务主管百般阻挠。即使排除利益纠葛，仍然会发现一种发自心底的不信任存在。而这种不信任，又往往来源于对同事工作的不认可。\u003C\u002Fp\u003E\u003Cp\u003E这个问题原因很多，也许没有通用的解决方案，但我说一个例子。\u003C\u002Fp\u003E\u003Cp\u003E我们最近开始使用Codis，就是@goroutine 和几个家伙之前搞过的玩意儿。虽然他们最近已经独立开搞像Google Spanner但拥有更高级特性的TiDB（就是太牛了的意思）。由于我对他们比较熟悉和认可，所以在Codis尝试方面也多出很多底气。这种信任并非完全来自于出问题之后的直接电话支持，而是真心觉得活儿好。\u003C\u002Fp\u003E\u003Cp\u003E反过来，这对很多服务也是一个提醒，特别是云服务。也许只要你得到合作伙伴的认可，或者至少让他们觉得，自己动手不会比你做得更好，你基本也就成功了。\u003C\u002Fp\u003E\u003Cp\u003E对于大多数理性创业公司来讲，他们还是更愿意把精力放在自己的主要业务上，不会希望所有的服务都自己做，因为这个年代，唯快不破，创业等不起一辈子。\u003C\u002Fp\u003E\u003Cbr\u003E\u003Cp\u003E\u003Cstrong\u003E产品意识\u003C\u002Fstrong\u003E\u003C\u002Fp\u003E\u003Cp\u003E回到开始那句话，“在对它不了解的情况下，仅通过google就能解决问题，不正说明它不难掌握有大量资料可查吗，实在不行还能翻代码。” 这话有些道理，然而却存在一个问题，这个问题就是：\u003C\u002Fp\u003E\u003Cp\u003E作为一个使用者，是否有能力解决遇到的问题，与是否有意愿去遇到并解决问题，是两回事。\u003C\u002Fp\u003E\u003Cp\u003E你有本CPU设计手册，你可以说处理器很简单，但我只想看个电影啊？给你Linux内核的源码，你可以说内核设计不难掌握，但我只想跑个游戏啊？何况他们是否因此就变得不难了，也是值得怀疑的。\u003C\u002Fp\u003E\u003Cp\u003E这其实反映了技术人的产品意识。\u003C\u002Fp\u003E\u003Cp\u003E很多技术人员喜欢玩酷的东西，他们愿意去探索新的领域，把不可能的变为可能。但是很多时候，他们做出来的东西却很难使用。\u003C\u002Fp\u003E\u003Cp\u003E有的库可以增加很多参数，参数之间却有耦合，导致你在采用的时候需要写很多设置代码，而有点库却只需要一行代码；有的服务功能众多，却需要用户学习繁杂的步骤，而有的服务却可以开箱即用；有的服务功能可以实现，却会有很多不稳定甚至崩溃的情况出现，等等。\u003C\u002Fp\u003E\u003Cp\u003E对于实现的工程师来讲，可能最大的区别在于，你是否考虑从用户的角度审视过自己的东西。即使这个服务也许只是为其他技术人员使用的。\u003C\u002Fp\u003E\u003Cblockquote\u003E\u003Cp\u003E技术人员可以，也应该，让技术人员更幸福。\u003C\u002Fp\u003E\u003C\u002Fblockquote\u003E\u003Cp\u003E最后，聊聊架构为大家送上一个关于技术选型的小漫画。其实技术并没有错，错的也许是我们.....\u003Cbr\u003E\u003C\u002Fp\u003E\u003Cp\u003E\u003Cfigure\u003E\u003Cimg src=\&https:\u002F\u002Fpic3.zhimg.com\u002Fv2-6cac7be4af8f4_b.jpg\& data-rawwidth=\&547\& data-rawheight=\&750\& class=\&origin_image zh-lightbox-thumb\& width=\&547\& data-original=\&https:\u002F\u002Fpic3.zhimg.com\u002Fv2-6cac7be4af8f4_r.jpg\&\u003E\u003C\u002Ffigure\u003E\u003Ca href=\&https:\u002F\u002Flink.zhihu.com\u002F?target=http%3A\u002F\u002Fmp.weixin.qq.com\u002Fs%3F__biz%3DMzA5Nzc4OTA1Mw%3D%3D%26mid%3D%26idx%3D1%26sn%3Def5bc2cd7e7b27c19b8fae5%26chksm%3D8be9974abc9e1e5c94217f4bcf5c5c3c18d8a98d1b4cfb4d386cf9da84%26mpshare%3D1%26scene%3D23%26srcid%3D0206KrF78w32RJiuu07zAU2H%23rd\& class=\& wrap external\& target=\&_blank\& rel=\&nofollow noreferrer\&\u003E阅读原文\u003C\u002Fa\u003E\u003Cbr\u003E\u003C\u002Fp\u003E\u003Cfigure\u003E\u003Cimg src=\&https:\u002F\u002Fpic2.zhimg.com\u002Fv2-25d18abcd533dddc4f85d110c3b16867_b.jpg\& data-rawwidth=\&900\& data-rawheight=\&500\& class=\&origin_image zh-lightbox-thumb\& width=\&900\& data-original=\&https:\u002F\u002Fpic2.zhimg.com\u002Fv2-25d18abcd533dddc4f85d110c3b16867_r.jpg\&\u003E\u003C\u002Ffigure\u003E&,&state&:&published&,&sourceUrl&:&&,&pageCommentsCount&:0,&canComment&:false,&snapshotUrl&:&&,&slug&:,&publishedTime&:&T23:11:56+08:00&,&url&:&\u002Fp\u002F&,&title&:&技术选型最怕的是什么？&,&summary&:&\u003Ca href=\&https:\u002F\u002Flink.zhihu.com\u002F?target=http%3A\u002F\u002Fmp.weixin.qq.com\u002Fs%3F__biz%3DMzA5Nzc4OTA1Mw%3D%3D%26mid%3D%26idx%3D1%26sn%3Def5bc2cd7e7b27c19b8fae5%26chksm%3D8be9974abc9e1e5c94217f4bcf5c5c3c18d8a98d1b4cfb4d386cf9da84%26mpshare%3D1%26scene%3D23%26srcid%3D0206KrF78w32RJiuu07zAU2H%23rd\& class=\& wrap external\& target=\&_blank\& rel=\&nofollow noreferrer\&\u003E技术选型最怕的是什么？\u003C\u002Fa\u003E 作者｜ 一乐个人微信一乐来了，id是yilecoming，欢迎关注。 这也许是我上半年最大的欠账，在去普吉的飞机上突发无聊，想想还了这债吧。 去年的时候，我们使用Cassandra出了一次问题，定位加修复用了一晚上。当我把经历发出来的时候…&,&reviewingCommentsCount&:0,&meta&:{&previous&:null,&next&:null},&commentPermission&:&anyone&,&commentsCount&:3,&likesCount&:25}},&annotationDetail&:null,&commentsCount&:9,&likesCount&:64,&FULLINFO&:true}},&User&:{&amin706&:{&isFollowed&:false,&name&:&Larry&,&headline&:&
奇点日报创始人，追求产品交互和设计的产品经理一枚\n 高逼格程序员技术分享平台 → http:\u002F\u002Fwww.qidianlife.com\n『心动屋』→ 发现令您心动的好物\n『壹日程』→ 专注任务管理和待办计划提醒
\n『拾光记』→ 拾起你走过的时光\n『口袋密码』→ 安全简洁的账号管家\n『破壳日』→ 精美的生日 · 节日 · 纪念日礼物提醒工具\n 邮箱 → &,&avatarUrl&:&https:\u002F\u002Fpic3.zhimg.com\u002Fv2-a5db75ec863beb_s.jpg&,&isFollowing&:false,&type&:&people&,&slug&:&amin706&,&bio&:&有情怀→渴望做出一款颠覆性App的代码工作者&,&hash&:&fd983d762fb8&,&uid&:528000,&isOrg&:false,&description&:&
奇点日报创始人，追求产品交互和设计的产品经理一枚\n 高逼格程序员技术分享平台 → http:\u002F\u002Fwww.qidianlife.com\n『心动屋』→ 发现令您心动的好物\n『壹日程』→ 专注任务管理和待办计划提醒
\n『拾光记』→ 拾起你走过的时光\n『口袋密码』→ 安全简洁的账号管家\n『破壳日』→ 精美的生日 · 节日 · 纪念日礼物提醒工具\n 邮箱 → &,&badge&:{&identity&:null,&bestAnswerer&:null},&profileUrl&:&https:\u002F\u002Fwww.zhihu.com\u002Fpeople\u002Famin706&,&avatar&:{&id&:&v2-a5db75ec863beb&,&template&:&https:\u002F\u002Fpic3.zhimg.com\u002F{id}_{size}.jpg&},&isOrgWhiteList&:false,&isBanned&:false}},&Comment&:{},&favlists&:{}},&me&:{},&global&:{&experimentFeatures&:{&ge3&:&ge3_9&,&ge2&:&ge2_1&,&growthSearch&:&s2&,&nwebQAGrowth&:&experiment&,&qawebRelatedReadingsContentControl&:&close&,&liveStore&:&ls_a2_b2_c1_f2&,&qawebThumbnailAbtest&:&new&,&nwebSearch&:&nweb_search_heifetz&,&seE&:&0&,&showVideoUploadAttention&:&true&,&isOffice&:&false&,&enableTtsPlay&:&post&,&newLiveFeedMediacard&:&new&,&newMobileAppHeader&:&true&,&androidPassThroughPush&:&all&,&hybridZhmoreVideo&:&no&,&nwebGrowthPeople&:&default&,&nwebSearchSuggest&:&default&,&qrcodeLogin&:&qrcode&,&enableVoteDownReasonMenu&:&enable&,&androidDbFollowRecommendHide&:&open&,&isShowUnicomFreeEntry&:&unicom_free_entry_off&,&newMobileColumnAppheader&:&new_header&,&feedHybridTopicRecomButtonIcon&:&yes&,&androidDbRecommendAction&:&open&,&zcmLighting&:&zcm&,&androidDbFeedHashTagStyle&:&button&,&appStoreRateDialog&:&close&,&default&:&None&,&isNewNotiPanel&:&no&,&wechatShareModal&:&wechat_share_modal_show&,&growthBanner&:&default&,&androidProfilePanel&:&panel_b&}},&columns&:{&next&:{},&lishichao&:{&following&:false,&canManage&:false,&href&:&\u002Fapi\u002Fcolumns\u002Flishichao&,&name&:&互联网笔记&,&creator&:{&slug&:&amin706&},&url&:&\u002Flishichao&,&slug&:&lishichao&,&avatar&:{&id&:&v2-05a3efacf81bef39a0f44&,&template&:&https:\u002F\u002Fpic1.zhimg.com\u002F{id}_{size}.jpg&}}},&columnPosts&:{},&columnSettings&:{&colomnAuthor&:[],&uploadAvatarDetails&:&&,&contributeRequests&:[],&contributeRequestsTotalCount&:0,&inviteAuthor&:&&},&postComments&:{},&postReviewComments&:{&comments&:[],&newComments&:[],&hasMore&:true},&favlistsByUser&:{},&favlistRelations&:{},&promotions&:{},&switches&:{&couldSetPoster&:false},&draft&:{&titleImage&:&&,&titleImageSize&:{},&isTitleImageFullScreen&:false,&canTitleImageFullScreen&:false,&title&:&&,&titleImageUploading&:false,&error&:&&,&content&:&&,&draftLoading&:false,&globalLoading&:false,&pendingVideo&:{&resource&:null,&error&:null}},&drafts&:{&draftsList&:[],&next&:{}},&config&:{&userNotBindPhoneTipString&:{}},&recommendPosts&:{&articleRecommendations&:[],&columnRecommendations&:[]},&env&:{&edition&:{&baidu&:false,&yidianzixun&:false,&qqnews&:false},&isAppView&:false,&appViewConfig&:{&content_padding_top&:128,&content_padding_bottom&:56,&content_padding_left&:16,&content_padding_right&:16,&title_font_size&:22,&body_font_size&:16,&is_dark_theme&:false,&can_auto_load_image&:true,&app_info&:&OS=iOS&},&isApp&:false,&userAgent&:{&ua&:&Mozilla\u002F5.0 (compatible, MSIE 11, Windows NT 6.3; Trident\u002F7.0; rv:11.0) like Gecko&,&browser&:{&name&:&IE&,&version&:&11&,&major&:&11&},&engine&:{&version&:&7.0&,&name&:&Trident&},&os&:{&name&:&Windows&,&version&:&8.1&},&device&:{},&cpu&:{}}},&message&:{&newCount&:0},&pushNotification&:{&newCount&:0}}