开源地址： https://github.com/callmelanmao/dhtspider。

开源的dht爬虫已经有很多了，有php版本的，python版本的和nodejs版本。经过一些测试，发现还是nodejs版本的爬虫效率最高，测试使用的是github上面的已有开源项目， https://github.com/dontcontactme/p2pspider/。

p2pspider开发的时候es2015才刚出来，所以决定用es2015把p2pspider项目重写一遍，顺便深入学习一下dht爬虫的原理。

dht爬虫总体分成两个模块。

dht模块

dht模块实现一个dht节点，用来和网上的其他dht节点进行通信，在通信的过程中完成收集磁力链接的任务。

bt模块

bt模块实现一个bt协议的客户端程序，当发现一个磁力链接可以下载的时候，通过bt客户端和远程的服务器通信，下载种子的元数据，

原理解析

0×01 相关术语

1.1 P2P网络

对等计算（Peer to Peer，简称p2p）可以简单的定义成通过直接交换来共享计算机资源和服务，而对等计算模型应用层形成的网络通常称为对等网络。相信大家都用过迅雷，就不多说了。

1.2 DHT网络

DHT（Distributed Hash Table，分布式哈希表），DHT由节点组成，它存储peer的位置，是一种分布式存储方法。在不需要服务器的情况下，每个客户端负责一个小范围的路由，并负责存储一小部分数据，从而实现整个DHT网络的寻址和存储，其中BT客户端包含一个DHT节点，用来联系DHT中其他节点，从而得到peer的位置，进而通过BitTorrent协议下载。

简单来说DHT就是负责管理提供信息和服务节点的管理与路由功能，两个需要区分的概念：

“peer” 是在一个 TCP 端口上监听的客户端/服务器，它实现了 BitTorrent 协议。

“节点” 是在一个 UDP 端口上监听的客户端/服务器，它实现了 DHT(分布式哈希表) 协议。

1.3 Kademlia算法

Kademlia是DHT网络的一种实现。在Kademlia网络中，距离是通过异或(XOR)计算的，结果为无符号整数。distance(A, B) = |A xor B|，值越小表示越近。

1.4 KRPC协议

KRPC 是节点之间的交互协议，是由 bencode 编码组成的一个简单的 RPC 结构，他使用 UDP 报文发送。一个独立的请求包被发出去然后一个独立的包被回复。这个协议没有重发。它包含 3 种消息：请求，回复和错误。对DHT协议而言，这里有 4 种请求：

ping 检查一个节点是否有效

find_node 向一个节点发送查找节点的请求，在初始路由表或验证桶是否存活时使用

get_peers 向一个节点发送查找资源的请求

announce_peer 向一个节点发送自己已经开始下载某个资源的通知
一条KRPC消息由一个独立的字典组成，其中t和y关键字是每条信息都包含的

1.5 MagNet协议

MagNet协议，也就是磁力链接。是一个通过sha1算法生成一个20字节长的字符串，P2P客户端使用磁力链接，下载资源的种子文件，然后根据种子文件下载资源。

因已有现成的脚本实现，只需要对相关协议有个大概了解就可以动手了。

0×02 DHT爬虫

####　2.1 实现原理

伪装成DHT节点加入DHT网络中收集信息，DHT中node（加入网络的时候随机生成）与infohash都是使用160bit的表示方式，也就是40位的16进制，意味着数量级有2^160，爬虫主要收集get_peer、announce_peer这两个请求的信息

####　2.2 get_peer

get_peers与torrent文件的infohash有关，找到待查资源是否有peer。这时KPRC中的q=get_peers，其中包含节点id和info_hash两个参数，如果被请求的节点有对应info_hash的peers，将返回一个关键字values，如果无则返回关键字nodes，同时也返回一个token，token在annouce_peer中需要携带。

参数：

{"id" : "<querying nodes id>", "info_hash" : "<20-byte infohash of target torrent>"}

回复：

{"id" : "<queried nodes id>", "token" :"<opaque write token>", "values" : ["<peer 1 info string>", "<peer 2 info string>"]}

或者

{"id" : "<queried nodes id>", "token" :"<opaque write token>", "nodes" : "<compact node info>"}

这里过来的info_hash不一定是有真实存在的

####　2.3 announce_peer

这个请求用来表明发出announce_peer请求的节点，正在某个端口下载torrent文件。包含四个参数请求节点id、info_hash、整型端口port和tonken，收到请求的节点检查这个token，如果相同，则返回节点的IP和port等联系信息。爬虫中不能直接用announce_peer，否则很容易从上下文中判断是通报虚假资源而被禁掉。

参数：

{"id" : "<querying nodes id>", "implied_port": <0 or 1>, "info_hash" : "<20-byte infohash of target torrent>", "port" : <port number>, "token" : "<opaque token>"}

回复：

{"id" : "<queried nodes id>"}

0×03 bt爬虫

准确的来说是bt客户端，因为到这里一步我们已经知道种子存放的服务器ip，端口，只需要通过bt协议向服务器请求对于的种子文件就可以了。

还有另外一个方法是根据磁力哈希码通过网上的种子缓存库下载种子， http://bt.box.n0808.com/， http://torrage.info/

缓存库下载的缺陷是有可能种子不存在，而通过bt客户端下载几乎可以99%获取到完整的种子元数据，所以p2pspider的效率还是很高的。

0x04 常用库

node.js常用的torrent相关库有 https://github.com/feross/webtorrent, https://github.com/themasch/node-bencode

0x05 在线搜索

在线磁力搜索网站有很多，这个只是用作测试用途， bt问问

现在的磁力搜索站点非常多，其实这都是跟百度学来的，在大陆是不能建设网站传播非法内容的，被发现轻则查水表，重则进小黑屋保你衣食无忧（你懂的），但是提供搜索技术就不一样，第一你不存储任何实质性的内容，第二你只是提供一个搜索界面，可以声称自己没有进行内容传播。百度就是这样的，你用百度能搜索到很多黄色内容吧，但是百度负责吗？百度不仅不负责，甚至还基于你的搜索给你提供带诈骗性质的广告，魏则西的故事这个大家都知道吧。

磁力搜索也可以利用百度这一套，如果涉及到版权等侵权内容还可以利用 避风港原则避免法律风险。

磁力搜索开源的程序有很多，大部分是用php，python开发磁力搜索脚本，把数据保存到mysql数据，然后利用sphix建立索引，最好开发一个web界面，就能实现一个完整的磁力搜索网站了。

安装ssbc

github上能找到的完整的磁力搜索网站源码就只有 ssbc了，大部分都是提供磁力搜索引擎，没有web界面和建立数据库索引的部分，这篇文章就介绍怎么基于ssbc搭建自己的磁力搜索网站。

环境检测

ssbc的DHT磁力搜索源码是使用python开发的，运行 python -v检测python的版本，确保安装了2.7版本的python。ubuntu 16.06默认安装的就是python2.7，如果你使用的是其他linux发行版，可以自行安装python。

ssbc源码托管在github上，如果你想用git方式下载源码，需要先安装git客户端。

下载源码和安装依赖

wget https://github.com/78/ssbc/archive/master.zip
sudo apt-get -y install zip
unzip master.zip
wget https://bootstrap.pypa.io/get-pip.py
python get-pip.py
cd ssbc-master
pip install -r requirements.txt

安装mysql数据库

ubuntu16.04默认使用的是mysql5.7的源，经过测试，ssbc的源码在mysql5.7上运行正常，如果是ubuntu14.04，你也可以用 sudo apt-get install mysql-server安装mysql5.5版本，这个是ssbc推荐的mysql版本。

ssbc的默认密码配置是root和空密码，使用空密码不安全，你需要修改源码中的数据库配置文件来完成密码的修改，使用github的基于项目的搜索功能，访问 https://github.com/78/ssbc/search?utf8=%E2%9C%93&q=root可以看到所有需要配置数据密码的脚本，根据需要自行修改。

创建数据库

mysql -uroot -p
create database ssbc default character set utf8;
quit

启动DHT爬虫

安装源码依赖和数据库之后就可以开始爬取种子信息了，

cd ssbc-master/workers
python simdht_worker.py

有些vps服务器会限制dht爬虫，因为会造成大量的网络请求，拖慢整个服务器的网速，如果运行上述的脚本10分钟左右在控制台能看到脚本打印爬取到的种子信息，说明你的爬虫运行正常，可以把爬虫进程关闭掉，然后以后台进程的方式重新启动。

nohup python simdht_worker.py > /tmp/dht.log 2>&1 &

这样启动还是不够安全，当服务器重启之后需要重新手动启动爬虫进程，如果你有能力，可以自己写一个 worker.service,把爬虫程序安装成系统服务，然后在系统启动的过程中自动启动你的爬虫程序。

安装sphinx索引

有了前面爬取的种子信息，当种子数很多的时候，直接使用mysql的搜索速度是很慢的，这个时候就需要使用第三方索引程序来提高种子搜索的响应速度，ssbc使用的是sphinx，其实简单改造一下也能使用elasticsearch或者solr等java开源索引框架，修改index_worker.py这个文件就行。

sudo apt-get install -y libmysqlclient-dev python-dev gcc sphinxsearch

这个过程中可能会遇到一些问题，基本上都是缺少sphinxsearch的一些依赖库，如果自己不会解决可以给我留言或者在 stackoverflow上提问，肯定有很多类似的问题，参考一些就能解决这些安装依赖的问题了。

配置sphinx目录和权限

mkdir  -p  /data/bt/index/db /data/bt/index/binlog  /tem/downloads
chmod  755 -R /data
chmod  755 -R /tem

生成索引，这一步还只是使用sphinx自带的命令生成索引，还没有索引前面爬取的种子信息

indexer -c sphinx.conf --all
searchd --config ./sphinx.conf

索引种子信息

cd ssbc-master
python index_worker.py

运行10分钟左右，如果程序没有报错就可以和爬虫程序一样，把这个索引程序运行放在后台运行

nohup python index_worker.py > /tmp/index.log 2>&1 &

启动web服务

为了让别人使用你的磁力搜索服务，还需要安装一个web服务，提供基于html的搜索入口，整个磁力搜索网站就算搭建完成了。

python manage.py makemigrations
python manage.py migrate
nohup python manage.py runserver 0.0.0.0:80 >/tmp/server.log 2>&1 &

ssbc的web是基于python的django框架开发的，前面两个命令是django提供的进行网站迁移的命令，如果是第一次安装，运行这两个命令没有任何效果，不过如果你启动web服务遇到问题，还是建议你把这两个命令添加上去。

除了直接使用80端口，还可以配置nginx等前端代理，流量大还可以做负载均衡，这些留待以后探索。

增加后台管理员

cd ssbc-master
python manage.py createsuperuser

根据提示：

• 输入管理员用户名
• 输入管理员邮箱
• 输入管理员密码
• 确认密码，完成
• 管理员登录地址： http://IP/admin

网上有一个ssbc的centos安装教程，centos和ubuntu的安装过程很不一样，所以就写了一个基于ubuntu 16.04的安装教程。

示例网站

最后贴上根据上述教程安装的磁力搜索站，点击 demo访问示例网站，本网站纯属教学意义。

写文章的时候经常需要插入图片，插入现有的图片很简单，有时候制作一些优秀的网站列表的时候需要添加网页截图，这个过程非常枯燥乏味，可以考虑开发一个命令行工具传入一个url，然后生成页面截图。

使用node-webshot进行网页截图

用到的npm模块有yargs和 node-webshot，关于yargs的文章参考这里 从零开始打造个人专属命令行工具集——yargs完全指南。

node-webshot是调用 phantomjs来生成网页截图的，phantomjs是非常有名的npm项目，相当于一个脚本版的WebKit浏览器 ，通过phantomjs可以使用脚本和网页进行交互，所以phantomjs经常用来进行网页自动化测试。

phantomjs会和普通的浏览器一样加载完整的网页内容，然后在内存里面进行渲染，虽然肉眼看不到它渲染的页面，但是通过生成图片就可以看到了，node-webshot使用的就是phantomjs的render接口来获取网页截图的。

node-webshot生成谷歌首页的示例代码：

var webshot = require('webshot');

webshot('google.com', 'google.png', function(err) {
  // screenshot now saved to google.png
});

phantomjs生成谷歌首页的示例代码：

var page = require('webpage').create();
page.open('http://github.com/', function() {
  page.render('github.png');
  phantom.exit();
});

那为什么不直接使用phantomjs呢？一个字懒！

另外node-webshot还对文件读写进行了简单的封装，相信任何熟悉node.js的开发人员，都能很简单的写出这样的接口，但是既然轮子好用就不要自己造了。

node-webshot流式调用的写法：

var webshot = require('webshot');
var fs      = require('fs');

var renderStream = webshot('google.com');
var file = fs.createWriteStream('google.png', {encoding: 'binary'});

renderStream.on('data', function(data) {
  file.write(data.toString('binary'), 'binary');
});

node-webshit还支持生成移动版的网页截图：

var webshot = require('webshot');

var options = {
  screenSize: {
    width: 320
  , height: 480
  }
, shotSize: {
    width: 320
  , height: 'all'
  }
, userAgent: 'Mozilla/5.0 (iPhone; U; CPU iPhone OS 3_2 like Mac OS X; en-us)'
    + ' AppleWebKit/531.21.20 (KHTML, like Gecko) Mobile/7B298g'
};

webshot('flickr.com', 'flickr.jpeg', options, function(err) {
  // screenshot now saved to flickr.jpeg
});

最后再把yargs和node-webshot进行集成，可惜这部分工作人家也帮我们做好了，直接安装就行。

npm isntall -g webshot-cli

使用desktop-screenshot进行系统截图

desktop-screenshot是一个跨平台的系统截图项目，用法和node-webshot类似，只是少了一个url参数。

var screenshot = require('desktop-screenshot');

screenshot("screenshot.png", function(error, complete) {
    if(error)
        console.log("Screenshot failed", error);
    else
        console.log("Screenshot succeeded");
});

这个是我的系统截图

问题是我用调用命令行的时候这个窗口也会出现在截图上面，而且没有太好的办法来去除这个窗口，系统截图还是使用windows自带的好用点。

图片优化

最后介绍两个图片优化的工具

• imagemin
• svgo

svgo使用用来优化svg图片，svg将会代替icon font成为新的趋势，详情阅读github的从icon font切换到svg的文章 Delivering Octicons with SVG，不服来辩。

已经一年半载没有写博客了，搞得上来不知道写些什么。博客上的内容还时不时有人评论，大部分我还是会一一回复的。有些人会关注我的博客用什么主机，我的博客现在是用Linode的主机，因为现在很便宜，而且配置不差。另外比较多的是问手撕包菜的源代码能否提供，能否出售。今天我写这个文章就是把手撕包菜的网站开源了，包括网站页面，DHT爬虫和搜索引擎相关部分。

2年前的那篇跟磁力搜索相关的文章在这里：
写了个磁力搜索的网页 － 收录最近热门分享的资源

作为最早在国内研究和实践DHT爬虫的人，我的灵感是来自芬兰Helsinki大学的这篇论文：
Real-World Sybil Attacks in BitTorrent Mainline DHT

英文好的同学应该很容易读懂，跟我写的不到300行的爬虫代码大致原理一样。初次接触DHT网络的可以结合我之前的文章阅读，或者拜读 Kevin Lynx的博客。所以具体原理在这里就不再阐述了。

手撕包菜一开始只是为了纯粹的技术研究，没有去想这个搜索引擎能给网民带来什么样的福利。当时采集了大量的数据，发现有一半以上的资源为限级内容，于是试图去对资源进行分类并且做了很多这方面的工作。譬如，基本上能通过一套规则能筛选出限级内容，对资源进行分类，如果是视频还能匹配出是哪一部影片。可惜，这些工作我主观上认为对生活应用并没有太大价值，于是就放弃了深入的研究。或许是因为网民使用此类搜索引擎大部分都是具有明显的目的性。

手撕包菜经历了多次点技术变更。开源版本使用了django网站框架重写，之前是Flask，再早期是tornado。电影FM也是使用tornado，后来发现tornado并不适用于任何场景。以内容为王的网站还是django比较擅长，只是入门时间比其他框架都较长。早期数据库采用了MongoDB，因为配合Python读写数据很方便，也不用关注数据结构，搜索功能采用自带的关键词搜索，不过后来随着资源数量增加，性能也明显跟不上。今年换了WiredTiger引擎，自带的fulltext search还是不给力。另外Amazon的cloudsearch是个坑，土豪可以考虑，性能真的很不错，就是比较贵。最后还是搭建一个SphinxSearch吧，数据库也换成MySQL（MyISAM引擎），配合起来也很方便。Sphinx创建全文索引的速度很给力，官方的自评也很高，我自己测试1000w的资源（大概3GB），1分钟左右就索引完毕。不信，大家可以自测一下。

网站和爬虫代码已经上传到GitHub，地址：

https://github.com/78/ssbc

代码采用GPLv2协议发布，使用时请遵循GPLv2的规定。
开源的目的是为了交流，学习和改进。如果商用，请务必告知。

附一个P2P网络协议QQ交流群：97912038。

综述

　　内存泄漏（memory leak）是指由于疏忽或错误造成程序未能释放已经不再使用的内存。那么在Android中，当一个对象持有Activity的引用，如果该对象不能被系统回收，那么当这个Activity不再使用时，这个Activity也不会被系统回收，那这么以来便出现了内存泄漏的情况。在应用中内出现一次两次的内存泄漏获取不会出现什么影响，但是在应用长时间使用以后，若是存在大量的Activity无法被GC回收的话，最终会导致OOM的出现。那么我们在这就来分析一下导致内存泄漏的常见因素并且如何去检测内存泄漏。

导致内存泄漏的常见因素

情景一：静态Activity和View

　　静态变量Activity和View会导致内存泄漏，在下面这段代码中对Activity的Context和TextView设置为静态对象，从而产生内存泄漏。

import android.content.Context;
import android.support.v7.app.AppCompatActivity;
import android.os.Bundle;
import android.widget.TextView;

public class MainActivity extends AppCompatActivity {

    private static Context context;
    private static TextView textView;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        context = this;
        textView = new TextView(this);
    }
}

情景二：Thread，匿名类，内部类

　　在下面这段代码中存在一个非静态的匿名类对象Thread，会隐式持有一个外部类的引用LeakActivity，从而导致内存泄漏。同理，若是这个Thread作为LeakActivity的内部类而不是匿名内部类，他同样会持有外部类的引用而导致内存泄漏。在这里只需要将为Thread匿名类定义成静态的内部类即可（静态的内部类不会持有外部类的一个隐式引用）。

public class LeakActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_leak);
        leakFun();
    }

    private void leakFun(){
        new Thread(new Runnable() {
            @Override
            public void run() {
                try {
                    Thread.sleep(Integer.MAX_VALUE);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        });
    }
}

情景三：动画

　　在属性动画中有一类无限循环动画，如果在Activity中播放这类动画并且在onDestroy中去停止动画，那么这个动画将会一直播放下去，这时候Activity会被View所持有，从而导致Activity无法被释放。解决此类问题则是需要早Activity中onDestroy去去调用objectAnimator.cancel()来停止动画。

public class LeakActivity extends AppCompatActivity {

    private TextView textView;
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_leak);
        textView = (TextView)findViewById(R.id.text_view);
        ObjectAnimator objectAnimator = ObjectAnimator.ofFloat(textView,"rotation",0,360);
        objectAnimator.setRepeatCount(ValueAnimator.INFINITE);
        objectAnimator.start();
    }
}

情景四：Handler

　　对于Handler的内存泄漏在(Android的消息机制——Handler的工作过程)[ http://blog.csdn.net/ljd2038/article/details/50889754]这篇文章中已经详细介绍，就不在赘述。

情景五：第三方库使用不当

　　对于EventBus，RxJava等一些第三开源框架的使用，若是在Activity销毁之前没有进行解除订阅将会导致内存泄漏。

使用MAT检测内存泄漏

　　对于常见的内存泄露进行介绍完以后，在这里再看一下使用MAT（Memory Analysis Tool）来检测内存泄露。MAT的下载地址为： http://www.eclipse.org/mat/downloads.php。
　　下面来看一段会导致内存泄露的错误代码。

public class LeakActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_leak);
        EventBus.getDefault().register(this);
    }

    @Subscribe
    public void subscriber(String s){

    }
}

　　在上面这段代码中有会导致内存泄漏，原因是EventBus没有解除注册。下面就以这段代码为例来看一下如何分析内存泄漏。
　　打开AndroidStudio中的Monitors可以看到如下界面。

　　
　　在这里可以看到在应用刚启动的时候，所占用的内存为15M，然后我们现在开始操作APP，反复进入退出LeakActicity。点击上如中的GC按钮。这时候我们在看一下内存使用情况。

　　在这里我们可以看到，内存一直在持续增加，已经达到33M，并且无法被GC所回收。所以我们可以判断，这时候必然出现内存泄漏的情形。那么现在再点击Dump Java Heap按钮，在captures窗口看到生成得hprof文件。但这时候所生成的hprof文件不是标准格式的，我们需要通过SDK所提供的工具hprof-conv进行转化，该工具在SDK的platform-tools目录下。执行命令如下：

　　hprof-conv XXX.hprof converted-dump.hprof

　　当然在AndroidStudio中可以省去这一步，可以直接导出标准格式的hprof文件。

　　
　　这时候可以通过MAT工具来打开导出的hprof文件。打开界面如下图所示：

　　在MAT中我们最常用的就是Histogram和Dominator Tree，他们分别对应上图中的A和B按钮。Histogram可以看出内存中不同类型的buffer的数量和占用内存的大小，而Dominator Tree则是把内存中的对象按照从大到小的顺序进行排序，并且可以分析对象之间的引用关系。在这里再来介绍一下MAT中两个符号的含义。

• ShallowHeap:对象自身占用的内存大小，不包括他引用的对象
• RetainedHeap:对象自身占用的内存大小并且加上它直接或者间接引用对象的大小

Histogram

　　 由于在Android中一般内存泄漏大多出现在Acivity中，这时候可以点击Histogram按钮，并搜索
Activity。

　　 在这里可以看出LeakActivity存在69个对象，基本上可以断定存在内存泄漏的情形，这时候便可以通过查看GC对象的引用链来进行分析。点击鼠标右键选择Merge Shortest paths to GC Roots并选择exclude weak/soft references来排除弱引用和软引用。

　　
　　 在排除软引用和弱引用以后如下图所示：

　　 在这里可以看出由于EventBus导致的LeakActivity内存泄漏。
　　 在Histogram中还可以查看一个对象包含了那些对象的引用。例如，现在要查看LeakActivity所包含的引用，可以点击鼠标右键，选择list objects中的with incoming reference。而with outcoming reference表示选中对象持有那些对象的引用。

Dominator Tree

　　 现在我们点击这时候可以点击Dominator Tree按钮，并搜索
Activity。可以看到如下图所示：

　　
　　 在这里可以看到存在大量的LeakActivity。然后点击鼠标右键选择Path To GC Roots->exclude weak/soft references来排除弱引用和软引用。

　　
　　 之后可以看到如下结果，依然是EventBus导致的内存泄漏：

总结

　　内存泄漏往往被我们所忽略，但是当大量的内存泄漏以后导致OOM。它所造成的影响也是不容小觑的。当然除了上述内存泄漏的分析以为我们还可以通过 LeakCanary来分析内存泄漏。对于LeakCanary的使用在这里就不在进行详细介绍。

(:з」∠) RT

公司的项目使用的是Nodejs进行开发，基于两年的开发经验写了一些工具库，现在已经用在了上线项目中。
这些项目还在持续更新中，难免会有些瑕疵，欢迎issue和PR。

排名不分先后。

1. mongostate
   Data state machine. Support transaction in mongoose.
   这个库是我们项目中的一个核心库，为什么这么说？Mongodb没有很好的实现Transaction，没有数据回滚的话，上线项目的数据会极容易造成污染（比如执行到一半的程序报了个错，前面更新的数据就是脏数据了）。这个问题困扰我很久，于是开发了这么一个核心库mongostate，基于mongoose的Transaction的实现。实现方案借鉴了FSM的理论。

2. mmq
   Mongodb-Message-Queue.
   详情请戳 基于mongodb实现的消息队列

3. koa-jwt-mongo
   Koa middleware to deal with JSON-web-token in mongodb
   将JWT在mongodb中进行维护，是对koa-jwt中间件的一个补充

4. errrr
   Custom error class.
   自定义的Error类，主要是为了方便。。。和内置的Error对象区分开来。

5. detector.io
   基于socket.io实现的探针工具。主要用于项目调试，搭建一个socket.io-client即可对埋入探针的地方进行实时监控。配套的还有一个用RN开发的客户端，这里就不放上来了。

6. oss-serve
   Serve static web pages on Aliyun OSS.
   使用阿里云OSS来Serve静态网站，用这个工具可以实现一键部署。增量更新。

7. mongoose-better-id
   A plugin for mongoose to generator better id
   一个mongoose插件用于生成文档id，该id是可读的并且可以定制化的。如默认会生成这样的id：1610211329190（时间戳+三位自增数）

8. tlan
   Time nature langurage
   console.log('today'.ending.is.over('12 hours'.after('today'.beginning))); //true如果操作Date对象可以像说话一样，想想就不错。tlan是对一些内置类进行的方法补充。

9. koa-docs
   An automatic documentation generator for koa.js APIs
   这是从外国友人 Amandeep那里fork过来的项目，用于自动生成API文档，我对该库添加了PR做补充，已经被原作者merge。

10. mongoose-json-diff
    Diff history plugin for mongoose documents
    mongoose插件，给schema添加若干方法，可以记录数据历史。和mongostate配合起来用效果极好。以后会出教程:D

以上所有库全部发布至npm。
安装方法
npm install xxx --save or yarn add xxx

再次欢迎issue和PR，这些项目都还年轻，如果你看得上，就用吧（所有项目都是MIT license）。

我对 ElasticStack可以说是既熟悉又陌生，说熟悉是因为很久以前就已经开始使用 ELK 来分析日志了，说陌生是因为以前的 ELK 环境都是同事搭建的，我主要是看看 Kibana 面板而已。随着 V5的发布，ELK 全面进化为 ElasticStack，是时候动手了。

实际操作前最好大致浏览一下 官方文档，以便对 ElasticStack 各个组件的作用有一个基本概念，如果看完文档还没搞清楚，那么至少要看明白下面这张图：

ElasticStack

整个流程相当简单，首先服务器通过 Filebeat 把数据上报给 Logstash，然后 Logstash 分析后把数据保存到 ElasticSearch 里，最后用户通过 Kibana 浏览数据。

废话少说，接下来让我们按顺序 安装 ElasticStack 的各个组件，不过安装前我们需要确保系统已有  Java 且版本足够新，一般这种运行环境我习惯用包管理工具：

shell> yum install java-1.8.0-openjdk

同时记得创建一个系统账号（比如叫 elastic）以便后续运行服务使用。

第一步：安装 ElasticSearch

shell> tar zxvf elasticsearch-<VERSION>.tar.gz
shell> mv elasticsearch-<VERSION> /usr/local/elasticsearch
shell> /usr/local/elasticsearch/bin/elasticsearch

服务启动后，我们可以通过 elasticsearch 提供的 API 来确认一下基本信息：

shell> curl http://localhost:9200/
{"name" : "...","cluster_name" : "...","cluster_uuid" : "...","version" : {"number" : "...","build_hash" : "...","build_date" : "...","build_snapshot" : false,"lucene_version" : "..."
  },"tagline" : "You Know, for Search"
}

缺省情况下，elasticsearch 服务会监听 9200 端口，如果你想自定义监听地址和端口，那么可以设置 elasticsearch.yml 配置文件中的 network.host 和 http.port 选项。

此时，elasticsearch 服务已经完全准备好了，不过还不算完，推荐安装 x-pack 插件，它在安全，监控等方面为 elasticsearch 提供了完善的支持：

shell> /usr/local/elasticsearch/bin/elasticsearch-plugin install x-pack

安装好 x-pack 后，会生成一个管理用户，用户名是 elastic，密码是 changeme，此时我们如果还想通过 curl 命令来操作 elasticsearch 的话，就要设置好用户名密码了：

shell> curl -u elastic http://localhost:9200/

不过使用缺省密码明显是不安全的，所以我们应该修改它：

shell> curl -XPUT -u elastic -d '{"password": "<PASSWORD>"}' \'localhost:9200/_xpack/security/user/elastic/_password'

至此，elasticsearh 的安装算是基本工作了，我们还可以确认一下服务的健康与否：

shell> curl -u elastic http://localhost:9200/_cluster/health?pretty
{"cluster_name" : "my-application","status" : "yellow","timed_out" : false,"number_of_nodes" : 1,"number_of_data_nodes" : 1,"active_primary_shards" : 3,"active_shards" : 3,"relocating_shards" : 0,"initializing_shards" : 0,"unassigned_shards" : 2,"delayed_unassigned_shards" : 0,"number_of_pending_tasks" : 0,"number_of_in_flight_fetch" : 0,"task_max_waiting_in_queue_millis" : 0,"active_shards_percent_as_number" : 60.0
}

你可能已经注意到在上面的结果中，状态被标记为危险的黄色，而不是安全的绿色。实际上我们的安装步骤没有问题，之所以会显示黄色，实际上是因为从集群的角度看，这个集群目前只有一个节点，所以是不安全的。多节点的配置大家就自己看文档吧。

第二步：安装 Kibana

shell> kibana-<VERSION>-linux-x86_64.tar.gz
shell> mv kibana-<VERSION>-linux-x86_64 /usr/local/kibana
shell> /usr/local/kibana/bin/kibana

不过启动服务器需要先设置好配置文件 kibana.yml，此外同样需要安装 x-pack：

shell> /usr/local/kibana/bin/kibana-plugin install x-pack

缺省情况下，Kibana 服务会监听 5601 端口，如果有需要也可以在配置文件中修改。

第三步：安装 Logstash

shell> tar zxvf logstash-<VERSION>.tar.gz
shell> mv logstash-<VERSION> /usr/local/logstash
shell> /usr/local/logstash/bin/logstash -f /path/to/logstash.conf

关键在于配置文件 logstash.conf 的编写，它包含 input、filter、output 三部分：

input {
  beats {
    host => "<HOST>"
    port => 5044
  }
}

filter {
  grok {
    match => {"message" => "%{HTTPD_COMBINEDLOG} (?:%{NUMBER:time:float}|-)"
    }
  }

  kv {
    prefix => "request_"
    source => "request"
    field_split => "&"
  }

  urldecode {
    all_fields => true
  }

  date {
    match => ["timestamp" , "dd/MMM/YYYY:HH:mm:ss Z"]
  }
}

output {
  elasticsearch {
    hosts => ["<HOST>:9200"]
    user => "<USER>"
    password => "<PASSWORD>"
  }
}

其中，input 和 output 很简单，无须多言，难点在于 filter 的编写，下面以 nginx 日志为例来说明一下，缺省情况下，nginx 包含了 combined 的 日志格式，也就是：

log_format combined '$remote_addr - $remote_user [$time_local] ''"$request" $status $body_bytes_sent ''"$http_referer" "$http_user_agent"';

不过我们通常还关心响应时间，所以我们多记录一个 $upstream_response_time：

log_format logstash '$remote_addr - $remote_user [$time_local] ''"$request" $status $body_bytes_sent ''"$http_referer" "$http_user_agent" ''$upstream_response_time';

在 filter 中又属 grok 最难懂，不过有很多例子，其中也包含了  COMBINED 正则，再配上 debug工具，并不难搞定，如果有问题，那么可以把 output 改成调试模式来纠错：

output {
  stdout { codec => rubydebug }
}

其它诸如 kv，urldecode，date 等等的说明，大家参考官方文档即可。

第四步：安装 Filebeat

有很多种 Beat，比如 Packetbeat，Winlogbeat，Metricbeat，因为我们是通过 Nginx 日志来收集数据，所以我们选择的是 Filebeat，配置文件 /etc/filebeat/filebeat.yml大致如下：

filebeat.prospectors:

- input_type: log
  paths:
    - /path/to/nginx/logstash/format/log/file

output.logstash:
  hosts: ["<HOST>:5044"]

在我们安装 ELK 的过程中，都是使用手动启动服务的方式，不过需要说明的是 ELK 都是内存消耗大户，保不齐就会出现 OOM 之类的意外情况，所以推荐用 supervisor 管理：

[program:elasticsearch]
command=/usr/local/elasticsearch/bin/elasticsearch
numprocs=1
autostart=true
autorestart=true
user=elastic

[program:logstash]
command=/usr/local/logstash/bin/logstash -f /path/to/logstash.conf
numprocs=1
autostart=true
autorestart=true
user= elastic

[program:kibana]
command=/usr/local/kibana/bin/kibana
numprocs=1
autostart=true
autorestart=true
user= elastic

如此，一个基本可用的 ElasticStack 就算是配置好了，理论上 ELK 三部分都是可以水平扩展的，如果性能有问题，一般加节点就行了，下面给一个实际的日志统计图表：

TIME

通过分析日志里的 $upstream_response_time 数据，我们可以把响应时间分割到多个区间里：90%，95%，99%，如此比单纯取全体平均值更合理。

更多的功能就靠大家自己去挖掘了，希望本文能起到抛砖引玉的作用。

昨晚， 金融新媒体一本财经曝出了一条信息：一个 12G 的数据包开始在地下渠道流通，其中包括用户名、密码、邮箱、QQ号、电话号码、身份证等多个维度，数据多达数千万条。

而黑市买卖双方皆称，这些数据来自京东。

一本财经的记者获取了这个数据包，尝试根据部分用户名和破解的密码登陆，确实大部分可登陆京东账户。通过在数据库中搜索自己的名字，一本财经的记者甚至发现自己的信息也早已泄露。

今天凌晨，京东就通过其官方微信公众号“京东黑板报”进行了回应：“经京东信息安全部门依据报道内容初步判断，该数据源于 2013 年 Struts 2 的安全漏洞问题。当时国内几乎所有互联网公司及大量银行、政府机构都受到了影响，导致大量数据泄露。”

也就是说，这些数据是真的。

另外，京东表示：

京东在 Struts 2 的安全问题发生后，就迅速完成了系统修复，同时针对可能存在信息安全风险的用户进行了安全升级提示，当时受此影响的绝大部分用户都对自己的账号进行了安全升级。但确实仍有极少部分用户并未及时升级账号安全，依然存在一定风险。

那 2013 年的 Struts 2 安全漏洞到底是怎么回事？

软件里的所谓框架，是基于现有技术设计的一个可复用的设计构件，它把原技术变得更加简单易用，同时功能和扩展性更强大。

Struts2 就是一个多用于企业级 Web 应用的框架，而且，它被认为是 Web 开发的宝典级框架之一。国内几乎所有的互联网公司、银行、政府机构等网站都或多或少使用了 Struts2 框架。

2013 年 7 月 17 日，Struts2 的开发者 Apache 基金会发布了该框架的新版本，但非常奇葩的是，在版本更新记录里，Apache 基金会透露了上一版本的一个远程执行漏洞，更加奇葩的是，它们直接公布了一段利用这个漏洞的示例代码。这个漏洞可以被黑客利用，获取网站用户的用户名、密码等各种敏感信息。

使用 Struts2 框架的开发者们，只有通过手动更新的方式，才能修复这个漏洞。也就是说， Apache 基金会在发布新版本的同时，把一个非常危险的漏洞，以及漏洞利用方法直接公诸于众。

Struts 2 安全漏洞的危害有多大？

首先，因为用于企业级应用的底层框架，Struts 2 的远程执行漏洞被恶意利用后，电商网站、视频网站、银行的用户都有泄露的危险。实际上，在 7 月 17 日漏洞被公布当天，国内的白帽子平台乌云上就收到了 100+ 各种漏洞报告，其中不乏国内各大互联网公司，甚至连苹果开发者网站都受到影响。

乌云当时曝出的部分漏洞

这个漏洞还有更严重的一面。由于 Apache 基金会直接公布了利用漏洞的代码，于是，各种傻瓜式窃取网站数据的工具一下涌现出来。 安全圈的知名人士道哥还透露，黑客们把越来越多的存在漏洞的网站公布在第三方平台上，更引发了类似杀人比赛一样恶性循环；同时，以前不关注这个漏洞的人也被吸引而来，进一步让局面失控。

道哥当时提醒，“可以不夸张的说，整个中国互联网应该被狠狠的捋了一遍。”

2014 年 9 月， 《法制晚报》报道过一个案例，某公司安全测试工程师王某，在看到 Apache 基金会公布的漏洞之后，利用该漏洞入侵了 263 邮箱的服务器，将该邮箱的 1.6 万多家企业用户的数据全部拿下。

这个案例中，263 邮箱属于迟迟未修复漏洞的。其实，很多小网站开发水平有限，他们可能根本就不知道 Struts 2 漏洞的存在，对于黑客来说，这些网站基本就是囊中之物。

在漏洞被官方曝出后， 国内各大互联网公司都宣称“第一时间修复了漏洞”， 京东当时的回复也是，第一时间就修复了漏洞，业务和用户数据都没有受到该漏洞的任何影响。

如果京东“第一时间修复漏洞”的回复属实，那就有另一种可能，在 Struts 2 的漏洞被官方公布前，就已经有黑客发现了该漏洞，并入侵了相关网站。

2013 年 7 月 21 日， 道哥在他的微信公众号写到，“先爆个小道消息，据某地下黑客组织成员透露，Struts 这个漏洞在 12 号就有人在批量利用了。”

为什么 3 年以后，才有京东的用户数据被贩卖？

这个问句可能不太准确，因为这些用户数据很可能已经被多次转手。最早曝出该消息的一本财经也在报道中表示，据业内人士称，数据已被销售多次，“至少有上百个黑产者手里掌握了数据”。而为什么现在再次流通，“原因不明”。

有一种可能是，数据泄露后，黑客们会先进行“洗库”，即将有价值的账户先洗劫一遍，之后，才会把数据拿到黑市上销售。这个过程中，黑客还要对加密过的密码进行破解，以及去别的网站“撞库”，即使用相同的帐号、密码，尝试登录其他网站。

所以，现在流通的这份数据，很可能已经是价值已经被压榨到极致的“渣”。

可以肯定的是，Struts 2 的漏洞早已被京东修复，而京东也确实提醒用户修改密码，如果你在 2013 年 7 月之后修改过京东密码，那这次对你不会有什么影响。

但是，从一本财经记者的实验中可以看到，可能还是有很多用户没有修改密码，导致帐号依然处于“裸奔”的状态。

除了让我们更小心，互联网公司们在安全上要承担什么责任？

每一次出现用户数据大规模泄露事件，我们总会被严厉教育一次：要使用复杂密码，不同网站要使用不同密码，密码要勤于更换……

但其实稍微总结一下，就会发现，大规模泄露事件一般是因为网站漏洞，使用复杂密码、频繁更换密码只是增加了黑客破解密码的难度；不同网站使用不同密码，只是能防止黑客“撞库”。

除了让我们更小心，互联网公司要为安全承担怎样的责任呢？

2014 年 12 月，13 万条 12306 网站的用户数据在网上被疯狂贩售，据瑞星透露，在对 12306 网站安全监测时，发现 6 个子网站存在 Struts2 远程监控漏洞。

对于劣迹斑斑的 Struts2，在涉及到用户信息的部分，开发人员或许该下定决心换个框架。

另外，国内的大部分网站，包括京东，还没有推出或强制用户使用两步验证。对于已经出现问题的帐号，建议其修改密码，并不是一个一劳永逸的解决方案。

安全无小事，不应该只是对用户说。

相关阅读：

     在互联网监管的知识水平上，俄罗斯还是要跟中国学习一个

     全球产品在中国电商渠道落地？京东灵机一动做成一门生意

     校园贷三年兴亡史：从集体狂欢到万劫不复

     数字漂亮敌不过热情消退，双十一还能狂欢多久？

对于“知乎”，你真的知乎？一份关于“知乎”的全方位产品体验报告帮你了解知乎。

1、产品概述

1.1 体验环境

体验机型：MI 5

系统版本：6.0.1MXB48T

App版本：4.11.0

体验时间：2016.12.3-2016.12.9

体验人：Grocery

1.2  产品简介

Logo：以代表诚实、信赖、知性的蓝色为底色，以“知”字作为产品标识，特别是对其右侧的“口”做了仿对话框的改动，点明知乎是汇聚智慧的知识交流平台。

Slogan：与世界分享你的知识、经验和见解——清晰易懂的平台功能介绍。

1.3 产品定位

以大学生、办公职场人士为主要对象的中文互联网最大的知识社交平台。

1.4 目标人群

“知乎的生态基于内容输出者、内容获取者以及第三方之间的价值关系。”——by 尼古拉斯 chaos 郭。

这样看来，知乎的用户主要有以下三种类型：

1、内容输出者——内容输出者分为两类。一类是各领域的专家级人物，以互联网领域居多，作为知乎的早期用户，这类专家级人物多是社区、移动互联网领域的CEO或者创始人，还有不少经理、总裁级别的专家。另一类是有相关从业经验但还称不上专家的学习型用户；

2、内容获取者——寻求高质量专业性解答，希望成为某领域专家的小白用户；

3、第三方——有广告、招聘等引流需求的用户。

1.5 产品功能

问答（包括付费语音问答“值乎”）、专栏、知乎书店（知乎周刊、一小时、知乎盐）、在线讨论（圆桌）、话题分享（知乎Live）

2、产品详情

2.1 需求及解决方案

1、问答

（1）需求分析

用户行为：搜索、提问和回答问题，对热门回答进行分享/投票/感谢/收藏/屏蔽/评论（包括拷贝、回复、踩、赞、举报评论等）

基本需求：获得专业解答，通过经验分享打造个人IP，问答双方需要信息反馈和良性互动的渠道

深层需求：主要满足小白用户的求知欲，以及专家和“中产阶级”对尊重和自我实现的需求

（2）关键因素分解

用户体验目标：针对特定问题能在最短时间内获得高质量的解答、能快速针对自己感兴趣或领域相关且有价值的问题作出回答

担忧：搜不到对应的问题、回答质量过低、得不到对方反馈和回应、低端问题（百度知道可以解决的问题）遍布、邀请信息过多等

障碍：用户基数不够大、问题覆盖面不全、不能对用户提问内容作过多限制、对回答质量进行筛选可能加大运营成本

（3）解决方案：

1. 在扩大用户基数方面，知乎起初招募圈子精英先玩，然后开放公众注册，通过大V的口碑营销和名人光环效应进行社会化分享推广，用户量多了，问题覆盖面也逐渐扩大；
2. 在减少低端问题和重复性问题方面，知乎虽不强行阻拦用户提交重复问题，但对问题进行聚类和重定向；
3. 在保证问题和回答质量方面，知乎限制每人每日提问数及回答数，建立用户自筛选、举报和主页推送机制，优化算法，让好的答案排列靠前，对“没有帮助”的回答进行折叠；
4. 建立回答邀请模式，同时鼓励用户修改题目以获得更多关注；
5. 完善设置，让用户自行选择想接收的信息类型（例如用户可选择只允许自己关注的人给自己发私信）。

2、专栏

（1）需求分析

用户行为：写专栏（有@功能）、对专栏文章进行点赞/赞赏/评论/收藏/分享/关注等

基本需求：让用户可以撰写笔记、发表见解和分享经验（打造个人IP）；自动推送特定主体的优质内容，降低搜索成本

深层需求：主要满足专家和“中产阶级”对尊重和自我实现的需求

（2）关键因素分解

用户体验目标：简便快捷地发布文章，能得到读者反馈、能找到感兴趣的话题

担忧：专栏内容支持格式过少编辑麻烦、写完专栏后没人看到没有反馈、找不到有趣的内容、无法保留优质内容

障碍：缺乏技术支持、“马太效应”即用户大多只关注大V、用户行业过于集中、专栏内容不够丰富、用户记性差

（3）解决方案：

1. 从优化文字编辑开始，逐步对图片、语音和视频给予技术支持；
2. 用户可利用@功能引起大V注意，同时知乎工作人员会定时筛选出普通用户的高质回答，放在首页推荐或知乎周刊中，增加曝光率；
3. 邀请各行业的专业人士加入知乎专栏；
4. 设置“收藏”和“浏览历史”功能，帮助用户轻松保留和找回优质内容。

3、知乎书店

（1）需求分析（整合价值，为优秀内容输出者提供变现渠道，以下仅考虑内容消费者）

用户行为：购买和下载电子书，进行阅读/书签/分享/点赞/评论

基本需求：找到感兴趣的电子书，阅读方便，能做标记和分享

深层需求：满足用户的求知欲、好奇心，让其获得将碎片时间都利用起来的充实感

（2）关键因素分解

用户体验目标：能找到感兴趣的书目并获得高效流畅的阅读体验

担忧：价格贵、内容不够丰富、篇幅过长、某些场景下使用不方便、买了之后才发现读不下去

障碍：用户对付费阅读有排斥心理；内容仅取自知乎问答和专栏，内容丰富度受限

（3）解决方法：

1. 知乎周刊部分免费，收费部分定价多在3元左右，在多数人可承受范围之内；
2. 推出“知乎周刊”、“知乎周刊Plus”“一小时”和“知乎盐”三种系列，丰富产品内容，篇幅有长有短；（注：“知乎周刊”多为时事和科技主题、“知乎周刊Plus”为结构化的技能经验合集、“一小时”为各行专业人士对一个问题的见解、“知乎盐”则属于深度行业介绍）
3. 提供“试读”，允许用户阅览部分内容后再决定是否购买；
4. 阅读体验方面，为用户提供“书签”和“评论”“分享”等实用功能。

4、在线讨论

（1）需求分析

用户行为：提问、回答或邀请参与活动的嘉宾回答，对动态和讨论进行关注/评论/感谢/分享/收藏/举报

基本需求：为用户和各专业领域的优质嘉宾提供和对方交流接触的途径

深层需求：满足用户的社交需求和品牌（主办方）的推广传播需求

（2）关键因素分解

用户体验目标：能与受邀嘉宾及其他用户展开高效有序的讨论和交流

担忧：提出的问题没有得到回答、讨论区变成“水区”、嘉宾都来自同一品牌、观点可能有失客观

障碍：受邀嘉宾参与积极性不高、讨论时用户言论不可预测、需要给予品牌一定的推广空间

（3）解决方法：

1. 允许用户提问时邀请到场嘉宾或热门回答者回答问题，同时圆桌期间主持人也会将讨论区中较有价值的热门话题收录至圆桌中，提高曝光率；
2. 在防止讨论区变成“水区”方面，主持人会做些引导，用户也可对不良内容进行举报；
3. 邀请的嘉宾中包括来自同一领域但不同机构的专业人士。

5、话题分享

（1）需求分析（内容输出变现的新模式，以下同样只考虑内容消费者）

用户行为：赞助参与、赠送给好友、对知乎Live的内容进行赞赏/点赞/感谢/祝贺/鼓掌/收藏/评价/提问等

基本需求：高效专注的学习氛围，能有效地与播主进行实时互动交流

深层需求：满足用户的求知欲、归属感，以及尊重和自我实现的需求

（2）关键因素分解

用户体验目标：清晰、顺畅、反馈及时且无干扰的直播过程，支持多格式内容

担忧：价格贵、直播内容以语音为主不方便保存、主讲的解说容易被刷屏的问题淹没导致查找费力、提交的问题没得到答复、Live质量过低

障碍：技术问题无法支持多格式内容；问题过多主讲忙不过来

（3）解决方法：

1. 功能刚起步，先做好语音和图文的分享，后续技术在逐步实现对PPT和小视频等格式的支持；
2. 知乎Live最低1元起，高低由用户自选，不定时会有限时特价活动；
3. 为用户提供“语音收藏”和“只看主讲”的功能；
4. 知乎Live的所有听众可对直播中出现的问题表达“喜欢”，主讲根据问题“喜欢”次数的多少挑重点问题进行回答；
5. 每场Live结束时都会邀请参与者进行评分和反馈，据此规范Live的质量。

2.2 产品分析

1、功能结构图

以下将从产品结构的清晰度和延展性两方面来评价知乎的功能结构。总体来看（左图），知乎的产品骨架比较清晰，底部共5个标签页：

• “首页”的信息分为三种，顶部标签栏为搜索（重要功能）以及Live（热门子产品）的入口；中间卡片列表部分为内容推荐（包括关注人的动态、优质问答和热门Live）；局部信息块为用户活动提供入口（写文章、提问、回答）。
• “发现”是对各类细分内容的推荐。
• “消息”是在用户收到“通知、赞与感谢、关注”时给予用户提醒。
• “私信”方便用户与知友进行交流。
• “更多”的信息也分为三种，上半部分属于用户信息的记录，下半部分为其他子产品提供入口（知乎书店、知乎Live、值乎），最后还有常规设置。

知乎从最初只做问答功能，到现在已成功添加“知乎书店、知乎Live、值乎”等多个子产品，界面结构仍保持清晰简洁，由此可见知乎产品结构的延展性还是很不错的。

关于知乎的产品功能结构，我有以下的一点想法：

相比于在首页有明显入口的“知乎Live”，知乎另外两个子产品“知乎书店”和“值乎”显然藏得较深，从推广付费内容的角度讲，建议将“私信”归到“消息”菜单下，同时将“更多”中与个人记录相关的内容提出来，放在一级菜单“我的”名下，效果如上面右图所示。

撤去“私信”菜单的理由有两个，一，尽管知乎想做的是知识社交，但大部分用户上知乎主要还是为了找答案，最常用的功能是搜索、问答、评论和写文章；二，很多时候在知乎上发“私信”会有去无回（对方觉得陌生人私信是种骚扰，选择屏蔽），且“私信”不配备表情包，实际体验一般。以上两者都会减少用户打开“私信”菜单的频率，因此建议撤去。

2、核心流程分析（注：以下用 粗体标出对应的功能）

（1）提问

首先，对照线下经验，提问是“一对多”的业务流程，其过程大概如下：

找到同伴——我提出一个问题——每个人发表自己的看法（没有见解的会表示支持/反对/做出评论等）——讨论——总结起来得出结论——问题解决

由于app要做的是线上“一对多”的模式，所以区别会在哪呢？

【1】要怎么“召集同伴”：由于互不相识，所以相对比较被动，主动召集只有一种方式：“邀请”，那么这里需要做的就是 推荐一些“可被邀请的人”。由于用户提问时默认面向所有对象，因此知乎定义，只要问题有人回答，就为公众所有。

【2】每个人发表看法阶段：就像线下讨论，总有几个意见领袖，有几个没想法的就对意见领袖的观点表示支持或反对，这里需要做的功能，一是让意见领袖的 回答人人可见，二是允许非意见领袖们 表达赞同、反对、举报等功能。

【3】讨论：参照线下，每人发表观点完毕，会发现存在分歧或有些值得深入探讨的点，这时候要给这群人提供的功能，一是能对每条回答都进行 评论，二是更便捷的沟通方式像 私信。

【4】总结得出结论：提问是为了得到结果，与线下不同，在线提问的对象是所有用户，那么根据“一万个读者就有一万个哈姆雷特”法则，统一结论是困难且非必要的，因此这里只要提供类似投票的功能，如 没有帮助，点赞，让用户自筛选高价值内容即可。

【5】最后问题解决：在现实生活中，找到一个难题的解决方法，你担心日后忘了所以你会找本东西把方法记下来，或者你会想把方法分享给朋友们。那么这里需要提供的，一个就是历史保存功能，像 我的提问，一个是 分享功能。

从以上整个提问的流程来看，由于在线问答不像线下，不是多人实时互动模式，所以也许你还需要一个消息提醒，像 通知，这样就允许你转移精力做别的事同时在第一时间了解问题的动态。

（2）回答

相对于提问，回答是个“多对一”的模式，其流程可以参考学生课上老师的提问：

老师提出问题——学生主动回答/老师点名回答——学生回答问题——老师点评回答，问其他同学意见

【1】老师提出问题：对应地，线上有人提交了一个新问题。

【2】学生主动回答/老师点名回答：

一个是答主主动寻找问题来回答，这时候要给他提供获取途径，像 搜索、推荐功能等。在线下，能引起学生回答兴趣的问题主要有两种，一种是有把握、能回答的问题，另一种是近期比较流行而自己也有点见解的话题。因此针对前一种我们要知道用户擅长的领域，对于后一种，考虑推荐 最新的、 热门的问题。另一个是答主被动受到 邀请，这时要给答主提醒。

【3】学生回答问题：面对课堂上老师的提问，同学举手之前一般会打腹稿，有的可能会做点笔记。应用到线上，也可以给用户提供 草稿的功能。

【4】老师点评同学回答，问其他同学意见：现实场景中，学生答完，老师会感谢同学站出来回答问题，其他同学如果还有想法会站起来补充，如果觉得他的回答很精彩，会用笔记下来，课后还会分享给其他人。这样看来，线上也可以允许用户对答主表达 感谢，收藏或评论答主的回答。

（3）专栏

对应现实中给杂志写专栏的流程，知乎“专栏文章”的发布不需要经过审核，其流程大体如下：

打草稿——修改内容、排版——发布

【1】打草稿：用纸笔写作时草稿笔记不会突然消失，而线上用户如果不注意保存草稿就会丢失。要做到像笔纸一样自动留下草稿的痕迹，此处为用户提供 自动保存的功能，同时让用户可以从随时查看草稿。

【2】修改内容、排版：杂志内容一般注重图文并茂，结构分明，类似的，线上专栏也应给支持用户 上传图片，并能 对图文的段落结构进行修改和排版。

【3】发布：对于给杂志写专栏的作者来说，尽管文章在发布前会有审核，但偶尔出现错别字或信息错漏在所难免，读者反馈问题，杂志社一般会在下一期对问题声明修正。而在线写专栏无需经过审核，问题可能更多，应为作者提供更方便快捷的 修改方式。对于杂志的读者来说，喜欢一个专栏，有人会持续订阅这本杂志，喜欢一篇专栏，有人会把它给剪下来收藏，还会在朋友间进行分享。类似的，我们也可以给用户提供 订阅、收藏、分享的功能。

杂志订阅量高了，作为一种激励，作者的稿费价位也会相应提高。与之不同，在线专栏的发布没有“杂志社”作为中间人，为激励作者，可允许读者用户对优质内容进行评分和评价，因此应该提供 点赞/赞赏/评论的功能。缺少像杂志这样拥有大量受众的载体，知乎上普通用户所写专栏一开始往往关注度低，曝光率不足，为激励用户可以为其提供 @功能，让用户有机会引起大V注意从而借力传播。

总的来说，以上三个流程都具有目的性，刨去用户闲逛知乎的场景需求，以上各部分涉及的功能都能做到与业务需求一一对应，不过少也不冗余。

3、界面体验分析

（1）入口

左图为知乎首页，一眼看去有三个局部块特别显眼，一个是顶部搜索框，一个是旁边的闪电符号（用户起初不知道是知乎Live的入口，所以会去探索），以及用互补色突出的，位于右下角的黄色元件。点击黄色元件出现右边界面，该过程，元件旋转的同时，“写文章”“回答”“提问”的图标并列跳出，对应标签向左划出，同时卡片列表区出现白色遮罩层。

此处入口设计的巧妙在于：

【1】采用互补色突出元件，并将元件放置在移动端用户拇指容易触及之处，方便点击，一键找到入口。

【2】点击元件后，动态弹出入口捕捉用户视线，同时弱化背景提高对比度。

【3】受点击的黄色元件发生旋转，明确提示用户所处状态已发生变化。

（2）提问

左图由首页黄色元件弹出的“提问”入口而来，为问题撰写页面。灰白搭配的页面风格清爽干净，在这类配色相对单调的背景上，自带阴影的弹出框对弹出内容起到了恰到好处的突出。该页面的元素非常简单：灰色提示文字、水平线、发布/设置/关闭元件，用法也一目了然。右图是在“问题”一栏输入关键字后出现的页面，为减少重复问题产生，该步骤会自动弹出“相关问题”列表，引导用户查看。

此处提问设计的优点在于：

【1】背景干净，能有效突出内容。

【2】结构清晰。页面顶部是编辑“问题”的位置，采用浅灰色背景突出层次，同时通过水平线提醒用户，“问题”和“话题”是必填项，“补充说明”可选填。

【3】为避免页面元素过于单调，采用飞机图形代替“发布”按钮，形象简洁；通过将灰色水平线变为蓝色来提示用户其所在位置。

缺点在于：弹出的“相关问题”列表中，由于排版问题文字有时会与数字重叠，导致用户看不清问题，同时影响美观。建议在重叠的地方对数字另起一行。

（3）回答

左图由首页黄色元件弹出的“回答”入口而来，据前面核心流程分析，用户回答问题前要先确定擅长的领域。按照提示添加后出现中间页面，“推荐”中出现问题列表，点击“写回答”调转到第三页。前两个页面主题色采用知乎蓝，回答撰写页面采用浅灰/白色，与“提问”处保持一致。相较于“提问”页面，“撰写回答”一页的界面更为简洁，还多了@、上传图片功能以及禁止转载的设置。

此处设计的优点在于：

【1】思路清晰，用户撰写答案前要先确定擅长领域，找对问题。

【2】保持编辑页面风格前后一致，对于查找问题和撰写回答页的主题色，采用蓝色和灰色加以区分。

【3】有效地突出内容。上面前两张图都对重点信息（如“点击添加”、问题的内容和“写回答”）进行加粗或变色处理，以便突出。

需要说明的是，用户在成功提问和回答问题之后，都会默认关注该问题。因此用户有两条途径可查看提问和回答记录，一是：更多——个人主页——我的回答/提问，二是：更多——我的关注——问题。

（4）写文章

左图由首页黄色元件弹出的“写文章”入口而来，可以发现“撰写文章”和“撰写回答”不仅风格一致，功能也十分相似。不同点在于“撰写文章”新增了导入草稿的功能，但从写作方便性来看，此页基本不具备排版功能。这会增大作者检查和读者阅读的难度。

此处写文章设计的建议是：

1、左侧键盘收起功能可去掉。目前主流输入法如讯飞、百度、搜狗等都自带该功能，如上图最右侧红框所示。

2、在技术允许的情况下，在界面底部可扩展一些基础的排版功能，如撤销键/字号/加粗/项目符号（尽管只有极少数用户会用app打长文，但不同字号的标题能帮助缕清文章的结构，这对中短文来说也同样重要）

3、 竞品分析

3.1 市场现状

1、行业分析

据易观数据今年12月2日发布的《中国知识付费行业发展白皮书2016》，近年来我国居民人均可支配收入快速增长，消费结构发生变化，人们对于“内容”和“知识”的付费意愿和消费逐渐发生改变，从不愿付费变得对于显著高质量、服务更好的类似产品愿意付费；同时随着移动互联网和移动支付的普及，人们的消费方式也发生了根本性的变化；人们获取信息的方式也从漫无目的地接受变为主动获取知识，信息的选择行为更为成熟。这些基础条件日渐成熟，推动知识付费行业成为新风口。

知识付费不同于出行和外卖行业“高频+刚需”的应用场景，知识交易的频率相对低且个性化程度高。但基于认知盈余分享的供给需求、用户对专业化和垂直化等优质内容的认知渴求，以及为有一技之长的个体提供闲置时间和知识技能的分享平台，知识付费行业仍存在巨大的潜在市场。

2、产品数据

钛媒体注：本文作者是青云QingCloud联合创始人兼CEO黄允松，作为一个在云计算方面有多年从业经验的创业者，他对云计算的未来提出了三个预测，本文浓缩了他在实践中总结的经验、对行业的观察以及对未来的思考。独家授权钛媒体编辑发布。这也是黄允松专栏的第一篇哦，欢迎持续关注。

今天想和大家分享一下我从业这么多年，对于 IT 行业过去发展的一些看法以及对云计算未来发展的一些思考。事物的发展都是一个自然延续和平滑演化的过程，不知过去，焉知未来。

IT 行业是依附于所有其他行业的一个纯正的工具性基础行业。从上世纪六、七十年代开始的“硬件层面”革命开始，八十年代和九十年代上半段基本属于软件行业的第一波浪潮。

我经常讲一句口头禅——『代码写得天花乱坠总得有地方跑』，运行软件就需要芯片、内存，需要一个完整的计算机体系架构，所以最早的 IT 时代，需要有类似于 Intel、IBM 这样的公司存在。

随着骨干网的发展，PC 互联网火了起来，此时 Cisco 变得非常关键，正是因为 Cisco 的努力，骨干网变成了一个普通人能够碰到的东西，这点很关键。

接下来，随着设备的微型化以及基础设施的发展，PC 互联网逐渐过渡到移动互联网。比如现在的手机和 Pad 都支持 3G、4G，我年轻的时候没有 3G，用的是 GPRS，只能发发彩信，用 WAP 浏览网页。但移动互联网真正火起来，是因为现在这些年纪更小的同行们，他们非常热情地投入心血在移动互联网领域。

讲到这里我稍微暂停一下，回归到今天的主题——云计算，我想在座各位应该都有自己对于“云”的理解。

我自己的观点一直没有变过——Cloud is Everything! 现在有什么不叫“云”的吗？举个例子：乐视有乐视云，它的 Television、Movie、Video 的视频云服务做的非常棒；前一段时间我拜访的 TCL 公司也有自己的 TCL 云平台、TCL 云电视等等。我们可以看到不管是家电、汽车，还是公共设施、写字楼宇、安防行业等任何事都是“云”。

“云”只是代表人对于计算机和通讯技术下一代演化的预期。

我们从拥有一个东西本身之后才能使用它，到现在不一定拥有它本身就能使用它，这个转变称为“云”的过程。

实际上我们每天都在和“云”打交道，比如邮件，你虽然没有购买服务器或者 CPU，但是有人帮你处理 SMTP 和 POP3。不管是买了演唱会的票还是高铁车票，或是订了酒店，当你在手机界面做了一些操作，而在事件本地什么都没做，但事件已经完成，这都是云的模式。“云”没有非常明确的功能层面的划分。

​云计算的分工会变得更加细化

云计算未来的分工将会变得更加细化。其实从美国来看“云”的分工已经很细化了，比如说美国的 AWS，看上去它的服务包罗万象，实际上就三大块：

再举个例子，Salesforce 在 CRM 领域是龙头企业，同时他们也在努力做 Force.com，想要把自己下沉一级到通用 PaaS 层面去赢得更多的机会，但也面临更多的挑战。

我一直有个论断，五年之内第一名的云公司是微软，而不是 AWS，为什么呢？你要看一个公司的主营业务在哪里，一定要在自己的细分领域做好。

像微软这样的公司，Iaas、PaaS、SaaS 都有，但是 SaaS 才是它发力以及厉害的地方，比如说它的 Office365，在办公、自处理、制表以及协同是行业第一。不过微软的 PaaS 也很厉害，它有自己的开发者平台，更重要的是它有两个宝贝，Visual Studio 还有 MSDN，它的团队和精力都能保证 PaaS 做得很好。

我们回过头来看一个呼声最高的公司，也是云计算领域的鼻祖之一的 Google ，它在“云”上反而没有什么建树。

迄今为止，谷歌在 IaaS、SaaS 和 PaaS 都有产品，但实际上在美国的云计算版图里面都是一个极小极小的存在，我们能看到谷歌厉害的地方在哪儿？还是推出帮中国人翻墙的 GAE，但是 GAE 到现在为止也是以免费的个人服务为主，说明它的时间未到（这是我一会儿讲的第三点，PaaS 层到底要分成哪几个步骤以及青云怎么应对 )。

实际上谷歌 GAE 目前是很尴尬的，Google Office 的 Google Docs 和微软 Office365 是竞争对手，一度获得了加州整个州的合约，很可惜 2015 年 Satya Nadella 出任微软 CEO 后这个州的合约又被微软拿回去了。 谷歌在 SaaS 领域很努力，但其实谷歌真正能力所在是在偏互联网方向的 App Engine，即 Platform 的建设。

在美国有一个很有意思的现象，VMware 在企业级虚拟化和私有云的市场基本上一家独大。

一个企业的 IT 是很复杂的，没有人能决定是搞私有云或者公有云。大多情况下甲方往往是要公私兼顾，只不过多要公或多要私而已。但一个公司只要公有云概率不高，只要私有云概率也不高，所以混合云非常关键。

在美国怎么做这个事呢？在私有云和企业级虚拟化市场上 VMware 一家独大，在公有云 IaaS 上 AWS 一家独大，PaaS 有微软、谷歌，以及 Salesforce，在 SaaS 层更是百花齐放。可以看到在美国， Cloud 的分工是非常细分的。

刚才讲的是偏技术层面的公司，如果偏应用就太多了，有做电商的，还有做支付的，还有做社交的等等。Facebook 在云上投资非常大，但是 Facebook 基本上是社交范畴之内的 PaaS 平台，这非常类似 QQ 和微信背后的腾讯云。

腾讯云做什么？第一社交，第二是 Gaming，尤其是 Mobile Gaming。腾讯是世界上最大的游戏公司，也是世界上最大的游戏运营商之一。这时候一个统一的 IT 支撑平台非常关键，但是 IaaS  对于腾讯不重要，因为它要的是对游戏流量的控制。

那么有没有一个公司能够吃掉所有的一切呢？不可能，专业搞电子邮件的不擅长社交，一个做游戏的公司搞电商会差一点，擅长搞互联网的做银行和保险公司的记账本不会太擅长，而擅长做金融行业的人去做安全部门业务系统也不会太擅长，做 IaaS 和 PaaS 的人做 SaaS 就不会太擅长。所以云的分工细化是一个大的趋势

万物互联要求云计算基础设施层具备更强大的能力和更丰富的功能

从移动互联网向 IoT 的迅速转变过程中会对基础设施带来新一轮的挑战。这个挑战表现在几个层面，第一个敏捷性，第二个成本，第三个复杂性。

敏捷性表现在当企业需要一个 IT 系统去解决问题的时候，在传统领域一般用几个月或者几年的时间上线一套 IT 系统在数据中心，而且企业心理承担能力是非常强的，经常说今天不行明天再来，反正不着急。

过去的 Business Model 是非常静态的，市场的竞争也没有那么激烈。 但是随着业务的变化，尤其是跨界竞争变得越来越常见之后，消灭你的往往不是你的同行，而是你不认识的人。

前段时间产生了一个很流行的词叫降维攻击，别人在一个更高的维度降维攻击你，你根本不认识它并且毫无反击之地。这种情况下需要我们 IT 行业要变得极其的敏捷，尤其是 IoT 出来之后要求会非常的高。

CT 行业也是一样的，不管是中国还是美国的骨干网。美国比我们好得多，在我们国家没有一个互联互通平等对等的骨干网存在。从基础设施层面就是不存在的。在价格方面，更是令人匪夷所思。

在美国，BGP 1 MB 的开销大概是一个月 0.8-1.2 美元，而在我们国家要贵几十上百倍。

移动互联网之所以能起来是因为 3G、4G 便宜了。我年轻的时候拿着手机就紧张，老怕超标，一超标 ¼ 的工资就没了，所以那时候老有一系列的工具帮你监控手机的流量，在桌面上我们还会放一个开关，帮助我关闭手机的 Mobile Traffic 。

其实现在也是一样的，想要从移动互联网到万事万物兼联网的状态，就要弱化骨干网的存在。美国国家电报公司 AT&T 已经有开始做一张实验网，但是 AT&T 有无作为都不重要，Google Fiber 的网已经遍布美国大型城市了，我们中国也需要这样的东西。

同时，我们还需要一个很重要的东西 —— SDN，为什么 SDN 很关键？很 多人觉得 SDN 是为了让大家降低对交换机的依赖，其实根本不是这样子的。我们要解决的问题是，把由 Cisco 定义的结构清晰的静态网络，变成百分之百动态网络。

SDN 有一个新的分支—— SDN-WAN，即软件定义的骨干网，在这种格局之下我们才有可能迎来移动互联网下一步的变化。

所以，在基础设施和敏捷性之后，降低成本是非常关键的。我在讲带宽的价格的时候已经提到这一点。直播行业是 2016 年最热门的行业，有几千家，他们在带宽方面的开销是巨大的。

在这个层面上说，基础设施层面需要新的变化，我们迫切地需要在接下来 3-5 年的时间使得我们国家基础设施即 ICT 行业，变得更廉价、更敏捷、更可靠，这样才能迎来下一步的发展。

那么这个和云计算有啥关系呢？这是我们 IaaS 层做的事情，原来仅仅覆盖 Computing Power，现在要覆盖横跨整个中国的 SDN-WAN，这对我们国家是非常重要的事情。

明年功能层面的存储是一个重点领域，尤其是对象存储、NAS、Flash SAN、Virtual SAN。

因为 IaaS 之后一定是 PaaS 和 SaaS，一旦行业聚焦在 PaaS 和 SaaS 之后，企业眼中就没有硬盘了，那数据放在哪里？有数据要放但没有硬盘，所以需要有一个行业能够代替硬盘——网盘，这也会成为云计算明年很大的需求。

这和我讲的第一点行业性的细化有一定的相关，功能层面的存储明年应该会有一轮的蓬勃兴起，我相信投资和行业研究的专家们会有共识。

PaaS 层的分解、发展与迭代

云计算未来发展的第三点是 PaaS 层的分解，PaaS 层会分成三个步骤发展和迭代，不同的厂商会扮演不同的角色。第一个是 Technical PaaS，第二个是 Solution PaaS，第三个是 Industry PaaS。

我的团队从 2015 年第三季度开始就不在 IaaS 投入研发了，裸机、机器虚拟化、容器化和 Unikernel，IaaS 基本上四位一体全覆盖后，路已经比较清晰了。PaaS 层为什么变得关键？因为太多开发者和甲方已经没有耐性停留在操作系统层面这块。

青云QingCloud 主要服务金融行业银行、保险、证券的客户最多，其他行业也看，我们未来还会做很多方面。

在 PaaS 层面，以我们做得最多的银行业客户为例，银行业基本上没有哪个开发团队还会愿意花时间安装中间件和数据库。大家想到的是找青云QingCloud 提供一套中间件，其实是中间件编排，我们也把它叫 Technical PaaS 。

Technical PaaS 更多的是中间件层面的高度自动化，这使得开发者不需要接触操作系统就可以编制代码、运行代码、维护代码，因为它不仅仅让硬件透明化，并且让技术本身也透明化。

写代码的人只需要理解数据模型、代码逻辑、测试逻辑，简单地说一个银行的软件工程师第一任务是理解银行的存、贷、债各种各样的业务，这个很关键。

Solution PaaS 面对的是一个过渡的阶段，是带有共性问题的打包方案。

我们刚刚讲的是一对一解决具体技术的问题，而 Solution PaaS 是以打包的方式解决客户应用的东西，它都是由偏传统的中间件所组成的。

这个过渡阶段 SI（系统集成商）很有优势，我们很明确地观察到不论是中国还是美国，在这个领域活跃的人基本上都是原来资深的 SI（系统集成商）。

Industry PaaS 是 PaaS 的终极形态，是带有行业属性的 PaaS 平台。像 BAT 的云平台就是带有极强 Industry PaaS 的特性，网易云和京东云也都是非常典型的。

未来两年在中国和美国都会广泛地出现一个词是行业云服务，我们会看到银行云、保险云、证券云、物流云，大家不要惊讶，这是因为人们（开发者、CEO、CTO、CIO）对于技术性的东西越来越不可忍耐。

这时候就把技术的东西留给我们来做，所以我们会解决硬件、网络、存储、安全系统、操作系统、中间件、调度、运维、升级、版本管理控制等问题。

然后我们输出 API，与合作伙伴合作打造 Industry PaaS，最后孵化出各种各样 SaaS 应用程序。这样一来我们的行业就能从基础层面解决技术问题，以便于孵化下一个革命 IoT 的浪潮。

迎接漂亮的 IoT 时代

在 IoT 到来以后，大家会发现各个行业的从业者在技术上非常不专业，但在行业上非常专业。这也就是我一直强调的一点：让专业的人做专业的事情，企业只需要将精力放在自己的业务与创新上。

比如做养殖业，如何让养猪的事情变得极度的科学，这个不是 IT 和 CT 的技术问题，而是养猪的问题，你得理解猪，你得知道它心情好不好，什么时候给它听钢琴，是听莫扎特还是贝多芬。我不是开玩笑，这是北京一个农业科技公司的养殖场做的事情。

如果能做好以上云计算三个大的转变，我相信很快会迎来一个比移动互联网更加漂亮的 IoT 时代。我经常讲，当再也没有记者愿意采访 IT 和 CT 行业，IT 行业也不会上娱乐头条花边新闻，IT 和 CT 变得高度透明、简单、廉价的时候，它就成为社会存在的基石了。（本文独家首发钛媒体）

2017年大数据发展的10大趋势经由全球专业机构发布，希望可以为你所在机构的年的发展规划提供战略政策依据。

　　数据量将持续增长

数据量的不断增加意味着通过数据的快速分析获取宝贵的市场洞察已经成为大数据业务运营的关键环节。机构和企业组织必须将其内部未被利用的每一字节的大数据，也就是我们所谓的“黑暗数据”(dark data)加以合理化的整合并转化成可以利用的数据资源。

如果大数据还没有为你的企业带来可供战略参考用的新见解，那么在2017年记得为你所在的企业提出有关大数据的创新计划，只有这样才能提升企业的竞争优势。

　　利用大数据提升客户体验

对于企业的并购，可以将遗留下来的数据资源转交到分包商系统，这种大数据的使用方式除了可以改进消费者体验之外，还可以升级核心系统。

让消费者使用灵活性的自助服务方式可以让大数据分析为企业快速掌握市场发展的主导趋势，还可以为客户需求增长机遇带来更多有竞争力的市场洞察。

利用大数据更深入的了解客户需求可以让搭配销售或者促销活动提高企业的一线财政收入水平，同时还可以免除因客户流失所导致的业绩缩水风险。

　　Hadoop 的应用领域将更加广泛

将会有越来越多的企业选择采用Hadoop和其他类型的大数据存贮架构，相应的，分包商们也将为业主提供更加有创新功能的Hadoop解决方案。

当Hadoop架构占据有利地位时，企业使用高级分析方法所处理大量数据可以为盈利决策找到宝贵信息的金矿。

　　预测分析将崭露头角

精准地预测未来可能放生的行为和事件可以提高企业的利润。为降低企业收入风险暴露所使用的欺诈行为快速鉴别和预判技术将会迎来质的飞跃，同时企业运营的卓越性将进一步得到改进。

　　基于云的数据分析将获得更多关注

将数据分析业务迁移到云端可以加速企业采用最新的技术能力，并实现数据资源到行动计划的快速转变。数据分析业务转移到云端之后，企业的运营和技术维护成本也将削减不少。

　　向信息学领域进军并注重数据价值的界定

新的一年，使用信息学助推复杂数据收集、分析与可视化技术的整合可以从数据资源中推导出企业所需的收益来源。从未被充分利用的数据当中提取资源可以提高企业运营绩效。

　　数据可视化将放大商业智能的作用与优势

数据可视化技术让隐藏在大数据资源背后的真相呈现在众人面前。无论数据怎样形成，无论数据资源在哪里，图形数据可视化可以让企业组织在业务繁忙的同时对数据进行检索与处理。

　　物联网、云技术、大数据和网络安全深层融合

数据管理技术，比如说数据质量控制、数据准备、数据分析以及数据整合等方面的融合程度将在新的一年当中达到新的高度。当我们对智能设备的依赖程度增加时，互通性以及机器学习将会成为保护资产免遭网络安全危害的重要手段。

　　提升数字渠道优化与多渠道体验

以客户偏好的渠道与其保持有效接触可以让企业在传统渠道与数字渠道之间找到最佳平衡点。通过不同渠道不断寻求创新手段提高客户体验度可以带来企业的竞争优势。

　　数据准备和分析的自助式服务将提高效率

无论企业数据类型属于结构化、半结构化还是非结构化，自助服务式的数据预备工具可以加速企业数据准备的时间。使用自助式数据技术可以降低企业对开发团队的依赖程度，从而更重视用户的使用感受，同时企业的运营效率也可以提升。

您可能也喜欢的文章：
2017年大数据十大发展趋势	2014年大数据发展的十大趋势	2016 年大数据技术发展趋势解读	十大消费者趋势	全球大数据发展呈现六大趋势（国际观察）
无觅

近日，凯文·凯利在成都进行了一个名为《回到未来》的 主题演讲。主要分享了对 AI 等前沿科技的看法。

KK 提到：“要预测未来是非常困难的。但是我们有我们的优势，因为技术都是有偏见的。通过技术的物理的特性，我们能够预见、能了解未来技术会到哪里去，未来技术很长一段时间会是怎样……”

以下是凯文·凯利的演讲内容：

今天我想预测一下未来25年的技术发展趋势：什么即将到来，哪些是不可阻挡之势。很多未来会出现的事物其实无法预测，因为技术是一种趋势，会侧重某些方向，任何一门科学的发展都有其规律，包括数字技术。技术又会随着实际情况的变化而发生趋势性的变化，所以我的兴趣在于探讨技术发展趋势变化的方向。

电线发明之后，人们希望寻找它的工作模式，而无论在什么国家，甚至什么星球，其实它的模式都是一样的，这种反复出现的工作模式会为技术发展指明方向。

这些趋势都是25年内的趋势，具体的技术发明没有办法预测，因为具体的预测是不可能的，我们不知道未来 苹果 是否仍然是一家成功的公司，iPhone是不是还会继续受消费者喜爱，也不知道BAT会不会继续存在。

这里谈的都是长期趋势的预测，技术将走向何方。我们理解事物的形态是没有办法改变的，比如四个轮子的车，四只脚的动物，这是都是事物自身规律决定的，这种形态也就必然的，但是就某种物种或者产品而言，比如斑马或者某种机器人，就是偶然出现的，是我们可能没有预料到的，我这里要讨论的是关于技术的大方向。

想象一下，山谷里飘来一阵雨，每一个雨滴的路径是不可预测的，但是他们运动的方向是可以预测的，都是向下的。像数字技术行业中哪家公司会赢，哪家公司会输的问题，我在这里不做讨论，我要讨论的是不可逆转的大方向。电话的出现是必然，而iPhone不是，互联网的出现是必然的，而 Twitter 不是。我会讨论电话，互联网领域的发展趋势。

人工智能早已来临，只是你没有感受到

最为重要的技术发展趋势之一是人工智能，感知并让产品更为智能的技术。大家可能对人工智能都不陌生，但是我想从一个不一样的角度解释它，让大家对未来的智能制造业有所了解。

首先，人工智能的时代已经来临，只是很多时候扮演幕后的角色，我们并没有直接的了解。人工智能系统解读X光片的本领已经比医生更高；查阅法律证据的能力也比律师要高；我来中国坐的飞机大部分时间也是由人工智能系统，而不是飞行员在控制；开车的时候，带有人工智能技术的刹车系统比人的判断更好。 百度 和 谷歌 的人工智能技术可以分析照片，告诉你照片里面正在发生什么事情。

最近谷歌的人工智能系统战胜了顶级的围棋人类选手，这个系统甚至还可以不断地学习如何下棋。过去十多年的电脑游戏，都是在和人工智能系统对战，现在的系统不过知道如何对战，还知道如何学习新的对战本领，这有很大的不同，机器学习也是当今人工智能系统的最重要功能。

其实人工智慧（artificial smartness）要比人工智能（artificial intelligence）可能更适合来形容这种技术，因为现在应用这种技术的产品已经比人更聪明。比如，计算器要比人脑的算数能力高很多，GPS导航设备要比人对空间的认知好很多，百度可以记住6万亿个网页，这远远超出人脑的记忆能力。

我们在汽车上采用人工智能系统，是因为它没有人的那些不良驾驶习惯，去年死于交通肇事的人数有100万，人类本就不应该开车，所以我们希望用人工智能技术来代替人，人工智能系统不会因为其他事情分心，也不会像人一样想问题。

人工智能总在某方面超过人类，但不可能和人类一模一样

人类对智力和智能的理解是错误的，单一维度的，片面的，只是认为老鼠的智力水平没有猴子高，一般人的智力没有天才高，这种理解可能并不正确。智力其实是一套思考方式，知识体系和工具，而这些方式，体系和工具构成了我们的思考和学习能力，每个人都不同，数量有几百种，比如演绎推理，归纳推理，符号推理，逻辑，空间导航，记忆等等。

动物的智力也是由很多思维方式构成的，有的时候他们看待人类的方式也是它们所独有的。一只松鼠或者其他啮齿类动物的记忆能力超过人类，因为即使过了好多年，它们还可以记得当初在什么地方埋下了成千上万颗橡果，这一点没有人可以做到，所以某些动物的智力在某些方面下是超出人类的。

在设计人工智能系统的时候，我们遵循同样的原则，让它们可以以某一种特定的方式看待人类，而不是像人类一样思考，其中有一条设计理念所有的工程师都会铭记心中，那就是产品不可能每一方面都能做到最优，总需要做出权衡。

各种人工智能系统产品总会在某一方面超出人类智力，但不可能做得跟人类一样。在看待人类智能的时候，我们可能会将自己视为中心，其他智能围着我们转，就像宇宙学的地心说理论，而其实我们并不是什么中心。

我们对人类智能的理解会随着人工智能技术提高而改变，而开发人工智能系统的过程就是不断发现不同智力和思考模式的过程，而每一种模式对于研究人工智能都有用。很多时候，人类智能无法或者有相当大的难度去理解一些问题，无论是科学上的还是商业上的。

我们可以通过两步法来解决这些问题，第一是开发一套异与人类思考方式的人工智能系统，第二是利用这些系统加上人类智能来共同解决这些问题。这个过程就是证明我们不是智能中心的过程，思维方式真的是多种多样。

新经济的财富引擎就是在接触社会的同时拥有创造性思考的能力。一个人如果不接触社会，可能会有异于常人的想法，但是如果他一直接收各方面信息，很难有创造性的想法。有些人工智能系统可能没有人类聪明或者反应更快，但可能拥有不一样的想法，这就是价值所在。

人工智能带来的优势不在于用不用，而在于怎么用

我还想介绍一下关于人工智能另一方面的观点，人工智能还是第二次工业革命。第一次工业革命是从自然能源到人造能源的变革，那之前的农业时代都是靠人或者牲畜的肌肉力量，比如马，驴等等的畜力：想修路就只能靠人力，而那之后有了蒸汽机，电动机等等设备；日用品，工业品都是用这些设备制造出来，人类也有了驾驭自然力的能力。比如驾驶一辆汽车，你就拥有了250马力的功率，也可以使用机械设备建起摩天大厦，铺设贯通全国的铁路系统，建设生产鞋和椅子的工厂。

我们之所以有现在的生活，都是因为我们将人造能源作为一种商品进行交换，这些商品通过电力形式在全国范围内流通，所有人都可以购买人造能源。农民不需要创造人造能源，而只需要购买就可以得到。

人造能源的流通是创新和创业精神的巨大引擎，比如一个农民有一套人力水泵，有了人造能源之后，他可能就会产生将其改造为自动水泵的想法，因为有了电和水泵，就可以制造电动泵。而将电动泵的例子放大几万倍，也就有了我们的城市，这就是我们所说的第一次工业革命。

现在人工智能的研制也要达到同样目的，我们会在电动泵中加入人工智能系统，让它变成一款智能水泵。而将智能水泵的例子在城市建设中放大，就是第二次工业革命，也就是让电能驱动的设备具有认知功能，变得智能。这个进程不只包括制造业，而是整个经济的升级。而如果没有公司经营的智能升级和消费者的智能升级，制造业的智能升级也是不可能实现的。

第二次工业革命将实现整体经济的智能化。在250马力的汽车上匹配250种思维方式，不是人类的思维方式，而是人工智能的算法。问题是，如果你的企业有1000种思维方式24小时为你服务，你会用它们来做些什么？

未来，人工智能系统将部署在云端，作为一种商业资源，所有公司都可以购买这些资源来为商业拓展提供动力，人工智能将成为像电一样的能源和人人可以购买使用的服务，这就是第二次工业革命的结果，让人工智能的资源自由流动。

未来一万家的新创企业所采用的模式可能非常相似，就是将他们的业务加入人工智能系统。正如第一次工业革命，将一种工具自动化一样，第二次工业革命令自动化设备具有感知能力。谷歌认为人工智能就是下一次浪潮，所以它抓住这个机遇，从移动优先战略过渡到人工智能优先战略。现在，一些公司，比如谷歌， 微软 ， 亚马逊 和Facebook ，已经开始出售云端人工智能系统的服务，价格大概是每100次查询6美分。

未来制造业的竞争优势不在于使用人工智能，因为所有人都会使用人工智能，竞争优势在于用人工智能系统做什么事情，和别人有什么不同。真正实现将人工智能技术应用于自动可移动机器人，可能还有很长很长的路要走，因为功耗是一个很大的问题。人体的能效是非常高的，功率只有四分之一马力，大脑的功耗也很小。

追求效率的工作归于机器，不追求效率的工作归于人类

虽然将人工智能技术应用于自动可移动机器人有困难，我们可以制造其他类型的机器人，比如那些并不用编程，只需要观察你是怎么做一件事情的，然后就可以学会的那种机器人。这种机器人也有试错的能力，在不断的尝试中，逐渐学会并掌握技能，这些已经实实在在地发生了。

有人担心这些机器人会夺走工人的工作。是的，机器人可以帮人们完成某些任务，任何一份工作都需要完成许多任务，而人工智能和机器人所创造的任务数量要比他们拿走的任务数量多很多。

对于那些追求生产效率的工作，机器人最合适不过，反过来说，人类对于那些追求效率的工作并不重要。不追求效率的工作也有很多，创新这件事情本身就是不追求效率的，因为在创新的过程中，必然会有很多失败；科学工作也是不追求效率的，因为实验室的工作就是不断试错的过程，如果不犯错误，就不可能学到东西；艺术也是不追求效率的；人际关系也是不追求效率的。

很多我们认为重要的事情都是不追求效率的，这些就是需要人适合去完成的工作，也是需要我们付出更高代价得到的东西。所以，追求效率的工作归机器人，不追求效率的工作让人去做。创造，探索，实验的工作，人可以比人工智能做得更好。

国际象棋世界冠军加里·卡斯帕罗夫20年前输给了超级电脑“深蓝”，卡斯帕罗夫跟组织者抱怨说比赛不公平，因为IBM的深蓝把所有与它交战棋手的记录都存储在数据库里面，如果卡斯帕罗夫也能使用这样的数据库，他也能取得胜利。

卡斯帕罗夫于是就发起了一项全新的国际象棋赛事，参赛者可以以拥有人工智能数据库的人类身份参赛，参赛者也可以是人类“辅助”的人工智能。他把这个合成人工智能和人脑智能的“团队”比喻成“人头马（centour）”，一半是人工智能，一半是人脑智能。过去四年，世界上最强的棋手还是这样的“人头马”，有人类智慧的人工智能系统，它比单纯的人脑智慧或者单纯的人工智能都要聪明许多，因为它的思维方式与他们都不相同。

美国军方也在利用人工智能来装备部队，让人工智能和士兵共同完成任务。未来工人工资的高低也要视他们与人工智能，与机器人合作的情况而定，所以人类与人工智能的关系不是对立的，而是合作关系。人与人工智能的沟通交流方式采取的也应该是对话，而非打字的方式，而互联网就是对话的途径；未来，使用互联网本身就是与人工智能系统对话。

这就是我们会看到的根本转变，人工智能将对制造业产生影响，也会影响机构和公司。没有智能的公司就没有智能的制造业，这些准备拥抱人工智能的公司需要知道自己利用人工智能可以干什么，需要有敏锐的决策能力，需要分权管理。对于制造业企业而言，最大的挑战是建立与人工智能相适应的生产流程和企业文化。

虚拟现实带来的不是知识，是体验

我在这里想讨论的另外一个趋势就是，人类需要与产品进行更多交流。斯蒂芬·斯皮尔伯格执导，汤姆·克鲁斯主演的电影《少数派报告》就描绘了2050年的时候，汤姆·克鲁斯所扮演的角色用各种方式，身体各个部位夸张的肢体运动与电脑的交流，抑或是手指，眼睛和面部表情细腻的姿态被智能设备，雷达所捕捉。而与电脑互动的最终途径就是进入电脑，这就是我们称为人工智能的技术。

杰伦·拉尼尔（Jaron Lanier）在1989年提出了虚拟现实的概念，通过一个头戴式眼镜打开了通向虚拟世界的大门。那时候很多人认为只要5年时间就可以实现，但其实花了25年的时间。为什么没能马上实现？因为那时候拉尼尔发明的头戴式设备，按照现在美元的币值要100万美元，这个价格根本没有办法创造消费市场。

20多年以来，科技业发生了一些变化，其一就是智能手机的出现，智能手机研发的技术正是将虚拟现实推向市场所需要的，头戴式设备的价格也因此大大降低。目前市面上有两种虚拟现实技术，当然这两种技术也是会演进的，一种沉浸式虚拟现实，一种是混合虚拟现实（MR）。

沉浸式虚拟现实可以让人感觉置身从未到过的地方，比如山巅或者火星；混合虚拟现实让人在真实的体验房间中看到虚拟物体就像真实存在的东西一样，体验者甚至可以操控这些物体。

混合虚拟技术的研制更有挑战性，但是如果开发混合虚拟技术不是问题，那么纯虚拟现实的技术就也不是问题。

沉浸式虚拟现实可以带人到去那些平时到不了的地方，或者因为这些地方不能去，或者太危险。而混合虚拟技术的用途其实更多，可以用于教学和训练，比如去探索星系，从事设计工作，在虚拟情境中试用产品；也可以有虚拟多屏，想要多少有多少，微软就有这样一个系统，可以在头戴式设备中创造虚拟的办公室，可以读书，看高清电影，视觉效果非常不错，也可以有虚拟的同事。将现实和虚拟世界结合会产生非常有力的效果，比如Pokémon Go将虚拟物体和现实世界结合，造就了非常流行的游戏。

虚拟效果的产生需要用到手指和听力，更重要的是虚拟现实得到了大脑的配合。一个很著名的虚拟现实技术试验，就是让体验者站在一个房间里，戴上虚拟现实设备，虚拟世界当中的地突然塌陷出一个洞，并出现一个窄板横跨在坑的两端，需要实验者配合从上面走过去。对于大脑不同部位，这个虚拟现实实验有不同作用，对于阅读区域和感受区域的作用是不同的；可能实验者感觉要掉落下去，但其实他们知道并不会出现这种情况。

虚拟现实技术给人们带来的不是知识或者信息，而是体验。未来我们通过互联网获得的不只是知识，还有体验，我们购买的是头戴式设备体验，下载的是体验，分享的还是体验。通过虚拟现实技术，我们可以体验坐在别人旁边，参加游行等等，而摘下设备之后，我们可能不记得看到了什么，但是那种经验可能是难以忘怀的，这就是虚拟现实的力量。

虚拟现实技术在社交属性方面，超过一切社交媒体，因为我的感受是，最令人惊叹的不是虚拟世界，而是这个虚拟世界之中的人，我与他们分享经验，我知道这些人并不真的存在，但是我真真切切地感受到他们的存在；我不会离他们太近，要保持距离，但可以和这些虚拟的人有情感上的联结。虚拟现实技术创造的这种感觉和现实世界非常不同，可以帮助社交媒体提高社交属性。

所有权本身是一种负累，不如思考产品怎样向服务转化

未来技术发展的另外一个趋势是财产所有权的淡化，Uber是世界上最大的出租车公司，但是它本身不拥有出租车，Facebook是世界上最大的媒体公司，但是它本身没有内容的所有权， 阿里巴巴 是世界上最大的零售公司，但是它没有库存，Airbnb是世界上最大的住宿服务提供商，但是它没有地产。

所有权已经没有以前那么重要，如果你随时都可以使用到各种各样的商品或者服务，那么所有权就没有太大意义，因为所有权本身也是一种责任和负累。这种转变对于制造业而言有非常重大意义，比如消费者只是使用而不是拥有车，对市场会产生很大影响，有计算表明，城市的汽车只有六分之一是真正必需的。

在数字领域也一样，我已经不会去买电影碟片，因为如果随时随地可以看到电影的话，有什么必要买碟片呢？音乐和图书也是一个道理。我可以通过订阅的方式的看书，看电影，玩游戏，我也可以用同样方式来预订车辆来解决我的交通需要，或者预订其他什么东西。

这种趋势在交通领域非常明显，Uber就是一个很好的例子。这种按需服务的模式还可能在其他领域不断出现，比如3D打印，一小时递送，其实就等于即时服务。

目前整个经济中出现一个趋势就是产品向服务的转化，比如汽车是产品，但是在交通领域，可能人们并不买车，而是用其他方式获取车辆带来的便利，这会对汽车厂商的生产造成影响，对他们制造的车型造成影响。还有什么事情可以做？现在硅谷有超过9千家新创企业正在从事产品转化为服务的业务，比如帮助食品，家具，酒店，医院，医疗测试，玩具等等行业实现产品向服务的转化。

分享经济正在增长，这个毋庸赘言，而这个经济形态还仅仅处于初期，还有很多待开发的领域，可以通过分享经济增加他们的价值。

我所说的分享不仅是指汽车，还有许多可以通过协同合作，去共享那些可以共享但还没有共享的东西，比如衣服，任务。我们正在开发这方面工具来帮助不同国家，不同大洲之间的人们合作完成共同的任务。比如维基百科就是技术发展的成果，很多互相不认识的人可以通过这个平台分享知识；阿里巴巴和eBay也是一样，互不认识的人在进行买卖。这个行业还处于初期，未来需要找到和100万，500万人协作的方式。

区块链是另外一种分享经济，一个基于信任的分布式计费协作系统；技术的进步让我们可以使用加密系统来构建信任，有办法与陌生人共同完成复杂的任务。分享，协作，追踪，消息传播，都可以实现商业变现。

流动、短暂的屏幕阅读未来趋势，所以真实性将成为稀缺资源

另一个行业趋势与屏幕有关，屏幕无处不在，在中国，很多楼宇里有屏幕，甚至有些屏幕和纸一样薄，可以弯曲。电子书不必只是一块屏幕，可以是很多屏幕的合成。屏幕也不是单一的，可能会有多屏，第二张屏，第三张屏。

我们在使用屏幕浏览信息的同时，屏幕也在审视我们，软件会监测，分析用户的浏览内容，哪些内容吸引用户的注意，甚至感知用户的情绪。现在有软件可以识别用户的28种情绪，比如用户是否是困惑的，心烦意乱的，不知所措的，感兴趣的或者不喜欢的，软件可以进而根据用户的反应对内容做出相应改变。就像有人和你说话，会根据你脸上的表情变化来调整谈话方式内容。

无论是东方还是西方，书籍都是文化的核心，法律具有权威，发生的事情都会记录下来，几千年来都是如此，而现在屏幕成了文化传播的媒介，并且拥有和书籍完全不同的属性。

书籍的内容是固定的，有权威的，而屏幕的内容是一直变化的，流动性很大，短暂存在的和开放的。所以我想从屏幕上得到真实性的东西会更难，更具挑战性，但这就是屏幕文化的特点，数据流更大。

所有业务都是数据业务，业务的开展就是数据的流动

产品是静止的，而加工处理和服务是流动的。流媒体，标签和云计算都是流动的，不是一成不变的，因为数据是一直变化的，无论从事什么行业，比如钢铁业，制造业或者运输业，所有行业的业务都和数据有关，业务的开展就是数据的流动。

智能制造业意味着无论你生产什么产品，你都必须成为一家软件公司，和数据打交道，追踪数据，了解客户数据，以数据为中心。很多大的互联网公司都意识到，数据其实比客户本身更为有价值。所有能够被跟踪的数据都会得到跟踪，这是不可避免的。比如经营一家店需要跟踪顾客的数据，来分析购物时间，选择商品类别，这样就可以对经营策略做出调整。

虚拟现实技术也是对数据跟踪的技术，所有的数据都被追踪。《阿凡达》的制作就是通过追踪人身体，手和脸部肌肉的运动完成的动效，角色的创造就是通过数据跟踪完成的。

在虚拟世界中，我们对彼此的数据跟踪要远比在现实世界中对彼此的关注更多，我的预测是未来最大的公司一定是虚拟现实技术公司，因为虚拟现实公司会掌握更多的数据，更多的个人数据。

比如我们的运动轨迹，浏览内容和大脑活动，无所不在的数据追踪帮助那些虚拟现实技术公司建筑他们的基础设施。有很多像苹果公司，Fitbit一样追踪我们的健康数据，我们其实也在通过这些技术追踪自己的健康数据，以前可能每年进行一次的体检，通过这些技术，其实时时刻刻都在发生，贯穿整个生命过程。

你的身体是否正常将会是可见的，我的身体是否正常的标准可能和你的不一样，因为年龄和季节的不同；这些情况只有通过数据追踪我们才能了解，也只有在数据完整的情况下才能做出个性化的诊断和药物使用。

你的历史数据很重要，同样这种个性化的诊断也会随着新数据的出现和分析发生变化。别人也在追踪我们的数据，我们的朋友在追踪我们的数据，这也是微信的功能之一。还是在那部《少数派报告》的电影里，连广告都在追踪汤姆克鲁斯。

这些数据追踪可能让人感到不舒服，所以我们要考虑如何摆脱这种不舒服的感觉，对称追踪可能是一个解决办法，也就是我需要知道谁在追踪我的数据，他们要对我的数据负责任，并且我需要从这种追踪中获益。

如果这些都可以实现，那么这种数据追踪就是没有问题的。另外，数据追踪和隐私是相关联的。如果你想得到个性化的服务，无论是来自政府或者企业，抑或是交朋友，他们必须对你有所了解，你需要介绍自己。所以完全的个性化就意味着完全的透明，你需要对数据追踪持开放的态度，反之，你就不可能得到个性化的产品和服务，这都是每个人可以做出选择的，是否愿意接受这种数据追踪意味着会得到个性化的服务。

我感觉比较吃惊的是，人们更倾向于选择保持透明，接受数据追踪来获得某种技术带来的便利，而不是相反。

未来25年最伟大的产品还没被发明，你还没迟到

这仅仅是一个开始，未来是难以预测的，如果时间倒退20年，我们不可能预料到会有现在的技术，在线地图，数码相机，信息技术等等。过去这三十年电脑和人工智能设备越来越小，未来可以将每个设备装上一个芯片，就可以连接到物联网，比如在灯泡上装芯片，在椅子上，在鞋上，在门上，这些在以前都会被认为是不切实际的想法，可是现在，酒店的每扇门上都有一个计算设备。

对于未来不可知的世界，我们要保持开放的心态。我们目前只是出于虚拟现实技术发展的早期，我们对这个领域知之甚少，没有在虚拟现实或者人工智能领域的专家。这是人工智能发展的最好时代，去放手创造些什么吧。开发工具比以往都更加优化，价格更加便宜。

未来25年的科技趋势可能难以预测，不过有一件事是确定的，那就是我未来25年中，最伟大的产品今天还没有被发明出来。

也就是说，你没迟到。

• AI时代真的要到来了
  

• AI时代的Do and Don't
  

• 硬件的方向
  

• 有意思的亚马逊
  

今天抽空将 blog 增加了 HTTPS 支持，并停止了原来的 HTTP 服务。

由于证书仅网站域名需要，因此使用了免费的 Let’s Encrypt证书服务。

根据维基百科的说明，Let’s Encrypt 是一个于2015年三季度推出的数字证书认证机构，将通过旨在消除当前手动创建和安装证书的复杂过程的自动化流程，为安全网站提供免费的SSL/TLS证书。Let’s Encrypt 是由互联网安全研究小组（ISRG，一个公益组织）提供的服务。主要赞助商包括电子前哨基金会，Mozilla 基金会，Akamai 以及思科。

2015年12月3日，该服务进入公测阶段，正式面向公众。

2016年4月12日，该项目正式离开Beta阶段。

到2016年9月9日，Let’s Encrypt 已经发放 1000 万张证书。因此对于大部分中小型网站来说，是一个值得考虑的选择。

HTTPS 启用及配置的主要步骤如下，假设你已经有一个正常运行的 HTTP 网站。

1. 打开 https://certbot.eff.org/选择对应操作系统与 Web 服务器，选完后出现响应的平台说明。由于我的系统运行在 nginx 及 Ubuntu，选完之后出现的说明地址是 https://certbot.eff.org/#ubuntuxenial-nginx

2. 执行命令，并根据需要修改相应域名参数。

$ sudo apt-get install letsencrypt
$ letsencrypt certonly --webroot -w /var/www/timyang.net -d timyang.net -d www.timyang.net

3. 修改 nginx
将 80 端口相关配置改成 443 端口，并增加相关配置

# listen       80;
listen 443 ssl;
server_name timyang.net www.timyang.net;

ssl_certificate /etc/letsencrypt/live/timyang.net/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/timyang.net/privkey.pem;

再增加 80 端口自动跳转

server {
    listen 80;
    server_name timyang.net www.timyang.net;
    return 301 https://$host$request_uri;
}

4. 重启 nginx，并用 chrome 访问，如果 URL 地址之前出现锁标记，则说明设置成功。
如果页面中还包含有嵌入的 HTTP 元素，chrome 会仍然显示 i 标记，通过点击 i 之后的元素说明逐个修复即可。

另外注意 Let’s Encrypt 每次只有 90 天有效期，但可以通过脚本进行更新

测试运行

$ sudo letsencrypt renew --dry-run --agree-tos

如果运行成功，建议将正式更新脚本加到 cron 脚本中，一劳永逸。

$ sudo letsencrypt renew

虽然 Let’s Encrypt 是一个免费的服务，但对 letsencrypt 使用感到满意的朋友，还可以去他们网站进行赞助。

• C, Erlang, Java and Go Web Server performance test
• 如何写nginx module
• python web.py使用flup lighttpd优化过程
• 构建高性能的微博系统(QCon Beijing 2011演讲)
• Kubernetes – Google分布式容器技术初体验

什么是小程序（应用号）呢？看看小龙先生怎么说。
小程序是一种不需要下载安装即可使用的应用，它实现了应用“触手可及”的梦想，用户扫一扫或者搜一下即可打开应用。也体现了“用完即走”的理念，用户不用关心是否安装太多应用的问题。应用将无处不在，随时可用，但又无需安装卸载。
——Allen Zhang
按照我的理解：其实就是web app，但不同于轻应用。
小程序对于创业者来说是福音，为什么呢？
成本
native的成本到底有多高？
推广：平均成本5元一个下载 ，100万的下载量，月留存能有10w的都是少数中的少数
开发：安卓，ios要分开做，大量的机型、os版本差异、交互特殊等
就这两项能承受起的就不多了，最低起步价30w+左右，巨额的成本将大量的idea扼杀在摇篮里
而这些死掉的idea大部分就是因为市场小，盈利跟不上巨大的成本而看不到未来
从外部走进微信生态内部
服务更加快捷方便，用户的使用门槛大大降低。通过微信生态的流量转化更有效率，多少app的用户是通过微信文章推广流量带去的？一旦你就在这个生态里，只需要简单的操作，比如扫码，这个效率高了多少？
微信想为创业者提供怎样的价值
微信做的就是把开发和推广这两项成本尽可能的降低，推掉成本这座大山，改变移动互联网应用的规则，让创造者能把核心资源（钱和时间）关注到用户体验上，去真正为用户创造价值
服务是核心！
这就和native app时期有了一定的区别，这里更欢迎的是服务性的app，也就是他说的用完即时走。
早在8个月前，我就说微信要做的是一个长尾市场，聚合那些无法承担成本去独立做成app的服务。就像当年的亚马逊一样，几乎没有什么商品你在亚马逊上找不到一样。而现在微信就相当于是把商品变成了服务这种非标的东西。
“小而美”的产品更适合应用号，能获取较多的红利，真正高频常用的还是在原生app那边更好，当然像同程旅行火车票这种刚需路径短的还是很适合微信生态的。
小而美的服务是什么？
答：低频、非刚需基于场景的服务，在特定场景下（也就是够垂直）可以较好得解决用户需求。
许多付费的服务可能借力因此焕发出第二春，教育、医疗、家政、求职招聘、二手买卖、旅游、票务、金融理财、汽车后市场等等

那小程序到底现在做出怎样的东西？
一个简单的demo（可以本地或摄像头拍摄视频，展示）

上面源码地址： https://github.com/edagarli/w...（(顺便说下上传视频官方文档的用法有点小错误，具体看我代码)）

但是目前小程序问题还是很多的。
小程序的一些限制：

1 不支持HTML、没有 Dom。网页用的 JS、CSS 基本要全部重写，WXML 的语法和 HTML 差异还挺大，基本是一个个照着手册的属性去改。CSS 选择器不支持级联。

2 小程序源码打包后的大小限制为1M，超大传不上去。单次通过 wx.request传输的数据最大也是1M。（才1M啊，fuck中）

3 MINA 框架实现的 tab bar，最多5个 tab；通过 wx. navigateTo 推入后台的页面最多5层，超过会无法打开新页面。

4 小程序没有 webview 控件，自带的 view 和 text 又不支持图文混排，还不能动态 set WXML …… 所以小程序上的富文本也就只能做到固定焦点图+纯文本+emoji了

5 不支持 A 标签，无法打开普通网页。
整体上来讲，小程序本身被设计为处理简单逻辑的「工具型」应用；同时具有很强的内容封闭性。

总结：
“小程序”更适合提供内容和服务为主、但又需要功能性的小应用，比如服务相对单一的O2O应用如连咖啡、出门问问，再比如在内容之外还希望提供简单功能的。但对功能和交互要求很多的，如美图秀秀，京东商城，大众点评这些“大”应用，是不适合微信小程序的。
其他：
我整理了一些微信小程序资料，有兴趣的看看。 https://github.com/edagarli/w...
如果你是个产品经理或是设计人员，可以先去看一下「微信小程序设计指南」( https://mp.weixin.qq.com/debu...，用来做产品设计规范指导非常好。

我是卤肉(edagarli), 我会不定期分享一些技术，产品以及我创业方面的事。

本文简单的讨论一下随机分配红包的算法实现。若有雷同，纯属巧合。

如何生成指定范围内的随机整数

Python的random库提供了randint函数用于得到整数a和整数b之间的一个随机的整数（包括a和b，其中a<=b）。

import random
a=1
b=100
print random.randint(a,b)

randint函数可以基于random函数实现。random函数可以随机生成 [0.0, 1.0)之间的一个小数，注意是左闭右开的区间。

下面的my_randint01函数可以得到一个左闭右开区间中的随机整数：

import random

def my_randint01(left, right):
    if left>=right:
        raise Exception('...')
    rand_number = random.random()
    result = left+rand_number*(right-left)
    return int(result)

if __name__ == '__main__':
    for _ in range(10):
        print my_randint01(2, 6)

下面的my_randint02函数可以得到一个左闭右闭区间中的随机整数：

import random

def my_randint02(left, right):
    if left>right:
        raise Exception('...')
    rand_number = random.random()
    result = left+rand_number*(right-left+1)  # 此处略有改动
    return int(result)

if __name__ == '__main__':
    for _ in range(10):
        print my_randint01(2, 6)

红包分配要考虑的情况

用户看到的是红包单位是 元，不过RMB的最小单位是分，将金额从 元转换为 分也许更容易处理。

用户拿到的红包转换为 分时，必须是整数。

4分钱发给4个朋友，每个人都应该得到1分的红包。

4分钱不能发给5个朋友。

100分钱发给4个朋友要体现出随机性。

来，发红包

100分钱发给4个人，可以先得到4个大于0的在一定范围内的随机整数。每个人对应一个随机整数，通过这个随机整数可以得到他收到的红包大小在100分钱中的比例，然后按照比例分配。在此基础上还需要考虑下面的细节问题：

1、涉及到浮点数的乘除法，如果一个人最终得到了 0.2分钱，转转成整数该是0分钱还是1分钱？ 解决办法是先给每个人分配1分钱。

2、涉及到浮点数的乘除法，最后分配的红包取整后的和不一定等于100。解决方法是：每个人的红包向下取整，第4个人直接把剩下的拿到手即可。

3、按照上面的思路，5分钱分给4个人，第四个人稳拿2分钱。解决方法是：红包分配好后再随机打乱。

最终算法如下：

#coding: utf-8
import random

def red_envelope(cents, people_number):

    if (not isinstance(cents, int)) or (not isinstance(people_number, int)):
        raise Exception('invalid type!')

    if cents < people_number:
        raise Exception('too many people!')

    if cents <= 0 or people_number <= 0:
        raise Exception('Are you kidding me ?')

    if cents == people_number:
        return [1] * people_number

    if people_number == 1:
        return [cents]

    fix_result = [1] * people_number
    cents = cents - 1*people_number
    balance = cents
    rand_result = []
    rand_numbers = []
    for _ in range(people_number):
        rand_numbers.append(random.randint(10,100))
    rand_sum = float(sum(rand_numbers))

    for idx in range(people_number):
        if idx == people_number - 1:
            rand_result.append(balance)
        else:
            scale = rand_numbers[idx] / rand_sum
            your_cents = int(cents*scale)
            rand_result.append(your_cents)
            balance = balance - your_cents

    result = []
    for fix, rand in zip(fix_result, rand_result):
        result.append(fix+rand)

    random.shuffle(result)  # shuffle the result

    return result


# test
if __name__ == '__main__':
    result = red_envelope(100, 10)
    print result, sum(result)

某次输出结果：

[15, 10, 11, 10, 3, 7, 14, 3, 20, 7] 100

2015-04-03

本文讲述如何使用scikit-learn的KNN工具对文本进行分类。

关于KNN

K-近邻算法，简称KNN（k-Nearest Neighbor），是一个相当简单的分类/预测算法。其主要思想就是，选取与待分类/预测数据的最相似的K个训练数据，通过对这K个数据的结果或者分类标号取平均、取众数等方法得到待分类/预测数据的结果或者分类标号。

关于KNN，笔者在 浅入浅出：K近邻算法有较为详细的介绍。

数据集介绍

数据集是有8个分类的文本数据集，使用了结巴分词对每个文本分词，每个单词当作特征，再利用二元词串构造更多特征，然后去掉停用词，去掉出现次数太多和太少的特征，得到了19630个特征。取1998个样本用于训练，509个用于测试。基于词袋模型的思路将每个文本转换为向量，训练集和测试集分别转换为矩阵，并用python numpy模块将其保存为npy格式。

在 https://github.com/letiantian/dataset下载text-classification.7z，解压后导入数据：

$ ls
test_data.npy  test_labels.npy  training_data.npy  training_labels.npy  
$ ipython>>> import numpy as np>>> training_data = np.load("training_data.npy")>>> training_data.shape
(1998, 19630)>>> training_labels = np.load("training_labels.npy")>>> training_labels
array([6, 6, 6, ..., 2, 2, 2])  >>> training_labels.shape
(1998,)>>> test_data = np.load("test_data.npy")>>> test_data.shape
(509, 19630)>>> test_labels = np.load("test_labels.npy")>>> test_labels.shape
(509,)

如何找一样本的最近k个邻居

方法1：

>>> from sklearn.neighbors import NearestNeighbors>>> nbrs = NearestNeighbors(n_neighbors=6, algorithm='ball_tree')>>> nbrs.fit(training_data)  # 构造BallTree，可以快速找出6个最近邻居，原理待学习
NearestNeighbors(algorithm='ball_tree', leaf_size=30, metric='minkowski',
         metric_params=None, n_neighbors=6, p=2, radius=1.0)>>> distances, indices = nbrs.kneighbors(test_data[0])  # 找training_data中离样本test_data[0]的最近的6个样本
>>> indices  # 6个最近样本，每个值是指在training_data中的第几个样本
array([[500, 294,  62, 802, 732, 703]])
>>> distances  # 对应的距离
array([[ 13.37908816,  13.60147051,  13.60147051,  13.60147051,
         13.60147051,  13.6381817 ]])

也可以依次找出多个测试样本的最近的6个训练样本：

>>> distances, indices = nbrs.kneighbors(test_data[0:2])>>> indices
array([[ 500,  294,   62,  802,  732,  703],
       [  62,  294,  636, 1945,  802, 1091]])>>> distances
array([[ 13.37908816,  13.60147051,  13.60147051,  13.60147051,
         13.60147051,  13.6381817 ],
       [  7.93725393,   7.93725393,   8.1240384 ,   8.36660027,
          8.54400375,   8.54400375]])

方法2：

>>> from sklearn.neighbors import BallTree>>> bt = BallTree(training_data, metric='euclidean')>>> distances, indices = bt.query(test_data[0], k=6)                  >>> indices
array([[500,  62, 802, 294, 732, 703]])>>> distances
array([[ 13.37908816,  13.60147051,  13.60147051,  13.60147051,
         13.60147051,  13.6381817 ]])

基于KNN的文本分类

令k=6：

>>> from sklearn.neighbors import KNeighborsClassifier>>> knn = KNeighborsClassifier(n_neighbors=6, metric='euclidean')>>> knn.fit(training_data, training_labels) # 训练
KNeighborsClassifier(algorithm='auto', leaf_size=30, metric='euclidean',
           metric_params=None, n_neighbors=6, p=2, weights='uniform')>>> predict_labels = knn.predict(test_data) # 预测
>>> sum(predict_labels == test_labels)
230>>> 230./509  # 正确率
0.4518664047151277

令k=20：

>>> from sklearn.neighbors import KNeighborsClassifier>>> knn = KNeighborsClassifier(n_neighbors=20, metric='euclidean')>>> knn.fit(training_data, training_labels) # 训练
KNeighborsClassifier(algorithm='auto', leaf_size=30, metric='euclidean',
           metric_params=None, n_neighbors=20, p=2, weights='uniform')>>> predict_labels = knn.predict(test_data) # 预测
>>> sum(predict_labels == test_labels)
276  # 效果比k=6时提升了一些
>>> 276./509   # 正确率
0.5422396856581533

这个正确率并不高。在 基于贝叶斯的文本分类实战中笔者使用了多项式贝叶斯对同样的数据集进行分类，正确率达到近90%。

做个优化

我们将每个样本归一化，看看效果。

先写一个归一化工具（mytools.py）：

# !/usr/bin/env python
# -*- encoding:utf-8 -*-

import numpy as np

def uniformization(X):
    if X.ndim != 2:
        return None
    X2 = X.copy()
    X2 = X2.astype(float)
    rows = X2.shape[0]
    for i in xrange(0, rows):
        sum_of_squares = sum(X2[i, :]**2)
        if sum_of_squares == 0: continue
        sqrt_sum_of_squares = sum_of_squares**0.5
        X2[i, :] = X2[i, :] / sqrt_sum_of_squares
    return X2 

if __name__ == '__main__':
    arr = np.array([[1,2,3],[4,5,6],[0,0,0]])
    print uniformization(arr)

运行结果如下：

[[ 0.26726124  0.53452248  0.80178373]
 [ 0.45584231  0.56980288  0.68376346]
 [ 0.          0.          0.

处理原始数据集，生成新的数据：

>>> from mytools import uniformization>>> new_training_data = uniformization(training_data)>>> new_test_data = uniformization(test_data)

令k=6：

>>> knn = KNeighborsClassifier(n_neighbors=6, metric='euclidean')>>> knn.fit(new_training_data, training_labels) # 使用新数据训练
KNeighborsClassifier(algorithm='auto', leaf_size=30, metric='euclidean',
           metric_params=None, n_neighbors=6, p=2, weights='uniform')>>> predict_labels = knn.predict(new_test_data) # 预测
>>> sum(predict_labels == test_labels)
294  # 由230提升到294
>>> 294./509  # 正确率有提升
0.5776031434184676

令k=20：

>>> from sklearn.neighbors import KNeighborsClassifier>>> knn = KNeighborsClassifier(n_neighbors=20, metric='euclidean')>>> knn.fit(new_training_data, training_labels)  # 使用新数据训练
KNeighborsClassifier(algorithm='auto', leaf_size=30, metric='euclidean',
           metric_params=None, n_neighbors=20, p=2, weights='uniform')>>> predict_labels = knn.predict(new_test_data)  # 预测
>>> sum(predict_labels == test_labels)
314  # 由276提升到314
>>> 314./509  # 正确率有提升
0.6168958742632613

可以看到，归一化后，预测分类的正确率提升很多。

参考

1.6. Nearest Neighbors
sklearn.neighbors.KNeighborsClassifier

（完）

12月12日，南方都市报的一篇文章《恐怖！南都记者700元就买到同事行踪包括乘机开房上网吧等11项记录》在朋友圈刷屏了，里面描述了一些恐怖的调查现象：几百块钱就可以买到某个人被泄露的全套个人信息，四大银行存款记录、手机实时定位、手机通话记录……都可以查到，甚至可以进行手机定位，“服务最到位”的是，还有第三方软件为这样的服务提供担保。

雷锋网编辑不禁想到，两个月前，去安全企业白帽汇公司采访时，白帽汇安全研究人员告诉编辑：“你想不想查一下自己被泄露的信息？”编辑一惊，这都有？！该安全研究人员表示，是的，以他们长期潜伏黑灰产群的经验来看，很多社工库都可以查到个人被泄露的信息。

于是，在看到这篇文章后，编辑火速与白帽汇的安全研究人员联系，确认该文的一些事实，并知道了一些“了不得”的事情。

1.700块钱买到全套资料有可能吗？黑产是有统一的数据库吗？

白帽汇安全团队：是的，完全有可能。但是，黑产是否有统一的数据库，这个不确定，黑产为了做全套资料，不排除会到处搜集资料，整合成一个比较齐全的库；

2.住宿、航班、银行开户、网吧上网各种记录一应俱全，这是不是意味着泄露的源头就是酒店、订票网站……？

白帽汇安全团队：这倒不一定。比如，你可能从很多网络渠道订过车票，是谁泄露的，真不好说。就算拿到泄露的数据库资源，也很难溯源。除非把这个原始数据库留了下来，才能可能让被泄露的厂商确认，这是他的数据库。但是，一般会而言，黑产拿到数据库后会进行脱敏、加工，这样就很难找到泄露源头。另一原因是，目前监管不得力，谁都敢做信息泄露这件事情，很多信息泄露的情况是——内部人员把数据拿出来卖。

3.报道里提到：“一个名为“分布式查询”的文档里，记录了该同事自2011年4月以来的旅馆住宿记录、常住人口记录、暂住人口记录和网吧上网记录，另一个“人员基础信息—×××”文档中则是火车记录、航班记录、银行开户核查记录、驾驶证记录、驾驶证违章记录、机动车登记记录等。”看到这些，感觉很震惊，在信息泄露上还有什么更让人震惊的案例吗？

白帽汇安全团队：我一点都不震惊。现在市面上确实有这些信息卖，很容易做到。而且，个人信息泄露，一定是有的，信息泄露发生在你进入互联网的一瞬间，只要你在互联网上填写了个人信息，如曾经订过机票、填写过地址、电话……不要怀疑，一定会有。

我感觉也没什么更恐怖了，第一次看到信息泄露后会很震惊，第二次就会习以为常，而且有些公司之间还会进行数据交易和买卖。

雷锋网还注意到，这篇报道提到“南都记者决定再换个同事的手机号码，查一下其手机定位情况，前述工作人员表示仅可查询联通号码的手机定位，查询时间为半小时，收费是600元。南都记者提供手机号码并付款半个多小时之后，对方发来了定位信息的图片，内含地图、经纬度信息(精确到小数点后六位)，与记者同事所在的位置完全一致。”

这是如何发生的？一位匿名人士提醒编辑：“你有没有注意到，工作人员表示仅可查询联通号码的手机定位，这意味着是否是其中一家电信运营商的接口被黑产利用了？值得探究。”

在该报道中，还提到了社工库。白帽汇安全团队帮助编辑找到了其中一个社工库的可用网址，如图所示：

编辑尝试了一把，输入自己的 QQ 号后，果然看到了曾经用过的密码信息。另外，这个社工库页面还显示，可以提供别的“高级搜索”，比如，开房信息，但需要汇款成为会员。

最后，比较悲剧的是，在编辑尝试了输入身份证号查询后，发现白帽汇的安全研究人员发来提醒——千万不要输入身份证号，不然这个社工库会进一步绑定你的查询信息，编辑知道后心情如图所示。

在 App Store 搜索广告（Apple Search Ads）推出两个月后，来自移动应用跟踪与归因分析平台 AppsFlyer 的一份报告显示，在这项服务上线的一个月内，广告商们对投放结果十分满意。在这个月，他们在 Apple 搜索广告上的支出增长显著。今年 9 月 29 日，App Store 搜索广告正式上线，在此之前，这一搜索推广机制已经在美国试运行了三个多月。

早在一年多之前 Google 公司开始 Google Play store 的搜索广告业务时，分析师就认为苹果公司的 App Store 具备更好的搜索广告盈利前景。目前，整个 App Store 里有超过 200 个应用。据市场研究公司 Sensor Tower 估计，苹果 App Store 的应用数量未来将会越来越多，他们预计这一数字会在今年年底之前增长到 300 万，2020 年则会增加到 500 万。

而在应用数量不断膨胀情况下，开发者却没有什么太好的推广方式——要么是产品足够优秀，可以获得 App Store 的官方推荐，或者是联系媒体做点宣传，一些线下或者线上的推广活动也能增加 App 在用户中的曝光率和知名度。当然，如果一点钱也不想花，那就只能期盼奇迹发生了。

这种情况下，App Store 搜索广告开始测试。AppsFlyer 的报告显示，开发者直接在 App Store 里推广，效果确实比其他途径来的好——与其他媒体源相比，Apple 搜索广告的第一日和七日留存率更高，另外， 在前 20 位广告平台通过一次应用安装产生的应用内事件数量排名中，Apple 搜索广告的效果也名列前茅。

之前曾有观点认为，苹果的这一举措对那些资金雄厚的大型开发者更为有利，他们可以轻而易举地包揽相关领域的广告，使得该领域的小型开发者永无出头之日。对此 App Store 的负责人 Phil Schiller 回应称，有钱也没用——因为搜索的相关性优先级要高于广告投放，只有关联度高的结果才出现在搜索广告栏，而且开发者不能获得搜索词条的专有权。因此，资金雄厚的开发者也不会统治搜索结果。

AppsFlyer 在 10 月份的调查结果表明，正确使用关键词对开发者来说的确至关重要，只要关键词足够精准，贴近相关需求，即便是囊中羞涩的小型开发者也能获得抛头露脸的机会。也就是说，广告位关键词的搜索关联性比出价更加重要，App Store 并不会因为高额的广告出价而选择设置一些会带来恶劣用户体验的广告位，比如搜索音乐 App 却推荐社交 App。而在一段时间的广告后，如果用户对广告的点击反馈很差或对此 App 不感兴趣，苹果也可能会将广告下架。

业内人士普遍认为，App Store 搜索广告将在很大程度上弱化上述两种传统的 App 营销方式，使得搜索优化和关键词不再重要，以往的各种推广活动也不再那么有效。

目前 iOS 系统 65%的应用程序下载量来源于 App Store 搜索，这对苹果来说几乎是唾手可得的营收。面对硬件销量的下跌，服务业务正在成为苹果最重要的业务板块，而苹果最重要的服务产品，就是面向全世界 iOS 用户的 App Store 软件商店。如果一切顺利，App Store 搜索广告很可能为苹果带来很多额外的经济收益。

不过，中国的开发者目前还无法使用这项服务，他们还得再刷刷榜。