对比一下各种大众点评之类在O2O领域的标杆企业，可以看出：对于一个纯正的互联网公司而言，基于统一平台基础上的平台化研发、平台化运营是其核心的竞争优势，在统一平台基础上才可能沉淀用户、沉淀内容、吸引流量，从而在规模效应基础上建立起业务模式。因此大部分互联网公司都会围绕统一的平台来展开业务。

    同时由于互联网公司核心的能力之一在于运营能力，因此这些巨头们基于核心利益的考虑，在平台运营上基本为自主运营，但自主运营随之而来的问题是庞大运营团队对应的巨大成本、管理挑战、规模化问题等等。可以看出：在本地化运营上，那些巨头们面临巨大的挑战：

• 业务主要集中在一二线城市，这样才能满足规模效应的优势。如果像三四线城市拓展，就必须养庞大的运营团队
• 全平台统一运营，本地只为商户拓展及合作，很难发挥本地资源优势，从而实现本地化深度的运营，而深度的本地化运营始终是那些巨头们不愿意过多涉足的领域
• 各巨头本地的团队只是一个打工者而已，并不会有太多的人会把工作当成事业来投入

    基于此，对众多的移动互联网创业者而言，在二三四线城市基于本地化运营的O2O其实挺有机会的。

    那么这里所说的本地化包括那些呢？

1、本地化元素

• 本地化运营
• 本地化营销
• 本地化美景
• 本地化点评
• 本地化社会化问答
• 本地化旅游攻略
• 本地化的导游
• 本地化的交友
• 本地化的特产
• 本地的文化
• 本地的游记
• 本地化的广告推送
• 本地化电子杂志
• 本地化优惠券
• 本地化的团购
• 本地化的移动电子商务
• 本地化的互动游戏
• 本地化的离线地图
• 本地化的新闻、天气等等
• 本地化的线下合作
• 基于位置及场景的个性化推荐
• 等等

2、那些地方站的个人站长们

    在互联网时代一些由个人站长自己搭建并运营的地方站做得风生水起,地方站成功的原因大致可以总结为如下几点：

• 最接近市场一线，熟悉本地的市场及用户需求，在内容及服务上更能满足当地用户的需求
• 与当地资源合作最为擅长
• 基于个人使命和利益驱动的热情，这种热情可以攻克任何艰难险阻，无人可挡

    应该说：各本地站的个人站长是最适合做本地化运营的人群。

    但可以看出，在互联网时代个人站长们其实举步维艰，在移动互联网时代更为严峻。个人站长没落的原因有几个：

• 缺少持续的产品研发能力和运营能力，无力“满足人民群众日益增长的物质与文化生活的需要”
• 缺少能够持续提供支持的平台，帮助其不断超越瓶颈
• 缺少持续的盈利能力，维持艰难
• 热情的丧失

    传统互联网下有Discuz之类的建站工具（可以也称之为开放平台吧）来帮助降低建站门槛，个人站长只需关注本地化运营即可。在移动互联网时代工具及运营模式上都有所变化，而且在当前移动互联网相关的研发人才极度缺乏，在资源有限的情况下，大家都将注意力集中于自己产品的研发运营上，在移动互联网时代谁来提供类似Discuz这样的工具呢？

    谈到本地化运营和开放平台，在互联网时代Discuz是最有机会的，腾讯收购它应该也有此意图，但最终毫无声息，原因有几个：

    1、Discuz定位为纯技术平台而非运营型平台

    2、未建立一种对个人站长们有价值的业务模式，无法参与利益分配

    3、并未在平台运营、营销上为个人站长们提供其他有价值的服务

     在移动互联网时代谁来做移动互联网时代的Discuz呢？相信一定会有公司来承担此角色，如果能吸取Discuz的经验教训，采用开放平台的模式，结合移动互联网及聚焦垂直行业，一定能够开拓出一种全新的业务模式。

3、本地化一些杂思

   注：原本打算成体系把所想的写出来，写到一半，没兴趣了，直接把近期微博上思考的东西汇总贴出来，也算是自己对思路的梳理。说得再多、想得再多，还不如动手就去做。

    本地化是移动互联网应用竞争的焦点，怎样更好满足用户对本地化的需求呢？是采用一个app通吃天下+集中化的运营+本地化数据，还是采用每一个本地化app+本地化的运营+本地化数据模式呢？或许本地化app结合开放平台的思路能够诞生出一些颠覆性的业务模式。

    对O2O类的移动互联网应用，是否应当遵循“面向全局规划设计、本地化运营”的思路？尽管直接面向全国范围的用户及地域提供服务貌似市场巨大，但在模式尚未验证及完善情况下贸然全面开花，对模式的构建并不利。在产品及技术架构规划设计时候应当考虑全网用户需求，但在运营上应当遵循本地化运营思路。

    对众多的个人站长而言，要做好本地化运营，有一个类似联盟的组织或商业公司还是有价值的，可以弥补个人站长单打独斗所面临的各种困境，核心在于利益分配及平台所能提供的价值。平台价值的典型例子为：产品的集中采购、各地方站分销。为何以前那些做地方站整合的最终都失败了呢，值得思考？

    本地化的运营能力决定了产品和服务的品质、品牌，也是规模化的最大挑战。即便像大众点评等也很难做好本地化运营，在局部重要区域可以招聘人来做本地运营，但这些靠薪水驱动的有多少愿意投入全身精力去把繁琐的本地运营做到极致？

    本地化运营最大的挑战不是资金、资源等物质因素，而是缺少对本地化运营充满激情的人，这样的人并非极度匮乏，个人使命+合适的利益结合肯定能找到这样的人。本地化运营的标杆是那些传统互联网的个人站长们，原因无他：基于个人使命和利益驱动的热情，这种热情可以攻克任何艰难险阻，无人可挡。

    关于开放平台的一些思考 1、平台开放的节奏很重要，在模式尚未验证、标杆尚未建立前就全面开放并非好事 2、开放的心态很重要，但建立公正透明的游戏规则更为重要 3、用户体验是第一位的 4、平台必须持续能提供核心价值 5、平台与合作伙伴间的双向淘汰机制以及信用体系

    纯技术平台的开放并无太多价值，用户关注的是平台所提供业务带来的核心价值，因此成功的开放平台首先聚焦某点进行业务模式的创新，然后在此基础上笼络更多的合作伙伴来一起完善业务模式，同时输出相关的运营工具等帮助合作伙伴更好为用户提供服务。旅游+移动互联网+开放平台+本地化运营=？

    在一次又一次的规划会、立项会、评审会、讨论会等等会议上基本上所有的人都会以“专家”的口吻发问：怎样解决初期没有用户的困境？怎样解决初期没有优质内容？怎样解决初期用户关系链没有导入的问题？怎样让产品对用户有粘性？等等。其实那些“砖家们”大多都明白标准化的答案是什么，但怎样运用好这些标准化的理念他们也无答案。

    于是那些悲催的产品经理们不停地从产品创新、产品设计细节、产品运营、产品营销等角度来阐述及辩解怎样激励用户创造内容/导入好友/增强互动等等。

    在经过一轮轮的立项会/评审会后，一些产品因为无法圆满回答用户与内容鸡生蛋蛋生鸡的问题都被PASS掉了。

    而那些经过枪林弹雨生存下来的项目终于上线运营了，又面临缺资金、缺资源的困局：要资源先快速证明自己产品对用户有吸引力，而要让用户快速感知产品又必须投入资源。

    按照各种常规/非常规的互联网营销手段、运营手段运营一段时间后，用户数还是没上来，于是各种质疑及事后诸葛亮的断言都随之而来，那些产品经理及项目团队成员们最终也对自己当初的决策产生了怀疑，最为明智且直截了当的选择莫过于放弃，大家继续去需求下一个杀手级的应用。而但竞争对手成功后，大家只能留下一地鸡毛的遗憾。

   其实看看那些成功的互联网产品，在初期也都面临鸡生蛋蛋生鸡的问题，除了那些以创新或以营销等手段一鸣惊人的产品外，大部分的产品其实都经历了很长一段时间的蛰伏。

    刚做产品时候，总觉得产品的不成功是因为产品不够创新、产品运营手段不够丰富等等。现在回头看看曾经经历过的和正在发生的，如果要让我回答互联网产品成功最大的秘诀是什么，我宁愿选择：坚持、坚持、再坚持。

    很多业务模式和市场机会都有一个临界点的问题，例如用户数/商户数到一定数量、市场份额到一定额度、品牌知名度等。过此临界点后，有利因素之间会形成正循环，各种市场机会不断涌现，业务模式也会更加清晰。这不单纯只是规模效应问题，很多东西都需要实践去积累和沉淀。

    而且很多所谓的机会其实必须在团队能力/视野/行业理解等到达一定的层次后才可见，在每一个层次上我们都只能看见自己当前所处层次上的机会，而到达下一个层次的手段之一就是对所从事事情持续的努力投入。

    退一万步来说，即便产品在功能上并没有太多的创新，在资源上没有太多的优势。但如果产品对用户还有价值，能够帮助用户解决一些痛点，那这样的产品就有存在的价值。所谓存在即是合理的，对用户有价值的产品，不管用户的多寡，都有存在的价值。而只要有用户，只要我们持续努力，用户终究会积少成多，而过了一定的临界点后，产品的影响力就会指数级增长。

   对那些愿意对初期毫无希望的产品持续投入热情去坚持完善的人，其热情终会被用户感知的。而在产品设计及产品运营过程中，让用户感知我们的诚意对产品的成功至关重要。用户所有的抱怨都很正常：骂我们的产品很烂，骂我们的能力很差，骂与竞争对手毫无优势等等。但如果能让该用户在产品体验及运营细节感受到我们为解决其需求付出的不懈努力，用户也会感动的。没有人讨厌为理想而持续奋斗的人。

   我们最大的失败经常是因为眼光不够长远，指望一鸣惊人，在短期利益的驱使下我们经常过早放弃自己曾经的选择和理想。

   如果你是以3年为周期进行考虑的话，你将与很多人一起竞争。但如果你将时间周期延长到7年，你会发现你只在和其中一部分人在竞争，因为很少的企业愿意去进行长期战略的思考。只需要通过延长战略周期，你就可以努力追求曾经无法想象的结果。在亚马逊，我们希望做未来5年到7年的事情，通过培育种子项目，让它们逐渐成长——这方面我们非常执着。–Amazon CEO Jeff Bezos

    Slideshare Downloader是一个shell脚本，能自动下载slideshare上不提供下载功能的ppt并保存为pdf格式的文档。只不过在本机的Redhat Enterprise Server 5.3上试了一下，发现脚本有些问题。

    1、Slideshare Downloader用于解码swf文件的swfdec包在Redhat Enterprise Server上安装很麻烦，依赖一大堆包，捣腾了半天都未搞定，于是放弃掉使用swfdec。

        swfdec项目似乎从08年依赖就未更新过了，其官方wiki http://swfdec.freedesktop.org  也许久未维护了，登录进去全是灌水的广告帖子，刚开始还以为走错地方了。

       swfdec的安装指南

       swfdec的代码下载地址

   2、Slideshare Downloader直接用imagemagick的convert命令将多个png文件转化为一个pdf文件，测试了一下似乎不行。按照imagemagick 官方帮助的说明，多个png格式的文件不能直接使用convert命令合并成一个pdf文件     

    However, some formats, such as JPEG and PNG, do not support more than one image per file, and in that case ImageMagick is forced to write each image as a separate file.  imagemagick adjoin帮助

   3、Slideshare Downloader脚本应该是在Ubuntu等Debian系列的环境上测试的，在Redhat 下一些命令的语法似乎有问题

      在处理BASH_REMATCH 时候， RedHat 要加“”

    if [[ "$DOCID" =~ "([a-z0-9-]+)$"  ]]
    then
        DOCID=${BASH_REMATCH[0]}
    else
        echo $DOCID
        exit 1
    fi

       在Redhat下sort命令无-V参数

     基于以上几个原因，为方便自己使用,对Slideshare Downloader脚本进行了调整，测试了几个文档，应该还行。需要安装swftools、pdftk、imagemagick 包

    大致的方法：

    1、使用wget -q –O 获得指定url地址文档的所有swf文件的实际地址并下载

    2、使用swftools的swfrender命令将swf文件转为png格式的文件

    3、使用imagemagick的convert  +adjoin 将png格式的每个文件都转化为对应的单个pdf文件。

    4、使用pdftk将多个pdf文件合并成一个pdf文件

     在合并多个pdf文件为一个pdf文件时候，由于需要按照页面顺序合并，因此使用了sort -k1.3

      PDFS=`ls *.pdf | sort -k1.3 `

   调整过的代码（只在Redhat 上做了测试，且对代码未做优化）：

#!/bin/bash

# Author: Andrea Lazzarotto

# http://andrealazzarotto.com

# andrea.lazzarotto@gmail.com

# Slideshare Downloader

# This script takes a slideshare presentation URL as an argument and

# carves all the slides in flash format, then they are converted to

# and finally merged as a PDF

# License:

# Copyright 2010-2011 Andrea Lazzarotto

# This script is licensed under the Gnu General Public License v3.0.

# You can obtain a copy of this license here: http://www.gnu.org/licenses/gpl.html

# Usage:

# slideshare-downloader.sh URL [SIZE]

#———————————————–

# Modify 7/08/2011 by giudinvx

# Email  giudinvx[at]gmail[dot]com

#———————————————–

validate_input() {

    # Performs a very basic check to see if the url is in the correct form

    URL=`echo "$1" | cut -d "#" -f 1 | cut -d "/" -f 1-5`

    DOMAIN=`echo "$URL" | cut -d "/" -f 3`

    CORRECT=’www.slideshare.net’

    if [[ "$DOMAIN" != "$CORRECT" ]];

        then

            echo "Provided URL is not valid."

            exit 1

    fi

    if echo -n "$2" | grep "^[0-9]*$">/dev/null

        then SIZE=$2

        else

            SIZE=2000

            echo "Size not defined or invalid… defaulting to 2000."

    fi

}

check_dependencies() {

    # Verifies if all binaries are present

    DEP="wget sed seq  convert"

    ERROR="0"

    for i in $DEP; do

        WHICH="`which $i`"

        if [[ "x$WHICH" == "x" ]];

            then

                echo "Error: $i not found."

                ERROR="1"

        fi

    done

    if [ "$ERROR" -eq "1" ];

        then

            echo "You need to install some packages."

            echo "Remember: this script requires Imagemagick and Swfdec."

            exit 1

    fi

}

build_params() {

    # Gathers required information

    DOCSHORT=`echo "$1" | cut -d "/" -f 5`

    echo "Download of $DOCSHORT started."

    echo "Fetching information…"

    INFOPAGE=`wget -q -O – "$1"`

    DOCID=`echo "$INFOPAGE" | grep "doc=" | cut -d "=" -f 3 | cut -d "&" -f 1`

    if [[ "$DOCID" =~ "([a-z0-9-]+)$" ]]

    then

        DOCID=${BASH_REMATCH[0]}

    else

        echo $DOCID

        exit 1

    fi

    SLIDES=`echo "$INFOPAGE" | grep "totalSlides" | head -n 1 | sed -s "s/.*totalSlides//g" | cut -d ":" -f 2 | cut -d "," -f 1`

    echo "Slides: $SLIDES"

    echo "Size: $SIZE"

}

create_env() {

    # Finds a suitable name for the destination directory and creates it

    DIR=$DOCSHORT

    if [ -e "$DIR" ];

        then

            I="-1"

            OLD=$DIR

            while [ -e "$DIR" ]

            do

                I=$(( $I + 1 ))

                DIR="$OLD.$I"

            done

    fi

    mkdir "$DIR"

}

fetch_slides() {

    for i in $( seq 1 $SLIDES ); do

        echo "Downloading slide $i"

        wget "http://cdn.slidesharecdn.com/`echo $DOCID`-slide-`echo $i`.swf" -q -O "$DIR/slide-`echo $i`.swf"

    done

    echo "All slides downloaded."

}

convert_slides() {

    for i in $( seq 1 $SLIDES ); do

        echo "Converting slide $i"

#        swfdec-thumbnailer -s $SIZE $DIR/slide-$i.swf $DIR/slide-$i.png 2>/dev/null

        swfrender $DIR/slide-$i.swf -o $DIR/$i.png 2>/dev/null

    done

    echo "All slides converted."

}

build_pdf() {

    cd $DIR

    IMAGES=`ls *.png | sort -k1.3 `

    echo "Generating PDF…"

    convert $IMAGES +adjoin %d.pdf

    PDFS=`ls *.pdf | sort -k1.3 `

    pdftk $PDFS cat output $DOCSHORT.pdf

    cd ..

    echo "The PDF has been generated."

    echo "Find your presentation in: \"`pwd`/$DIR/$DOCSHORT.pdf\""

}

clean() {

    rm -rf $DIR/*.swf

    rm -rf $DIR/*.png

}

validate_input $1 $2

check_dependencies

build_params $URL

create_env

fetch_slides

convert_slides

build_pdf

clean

    脚本下载请猛击

    同样的程序逻辑其实可以适用于百度文库、豆丁这样的在线文库。像百度文库、豆丁之类的在线文库许多资料需要积分下载，但可免费在线浏览，这些文库都使用Flash作为播放器，这就为免积分下载器提供了条件。当然在windows上有冰点文库下载器、易读文库下载器这样的图形化工具可用。只不过原理应该也是类似的，看一下冰点文库下载器目录下的SWFToImage.DLL、pdflib.dll两个动态库大致可以知道。

    其实谁有兴趣和精力可以将此类下载功能做成一个单独的在线服务，由此还可以延伸出其他产品功能来，应该还是挺有市场的。

    在这些渠道中，掌握话语权的角色基本上都为专业从事电子商务的商家，个人在整个交易过程中基本就扮演买家的角色而已。也曾有一些商业模式希望将个人用户转变为个体分销商/代理商的角色，建立由上百万个由普通个人节点组成的交易网络，最为典型的例子应该是以安利、特百惠、雅芳公司为代表的直销模式。尽管在国内大部分都认为：直销模式==传销模式，但直销模式在老美成百年的历史足足可以看出直销模式的生命力。直销和传销的区别不是我们讨论的重点，《直销管理条例》中对此有所说明。直销模式的一些启示：

• 任何交易行为，如果参与交易的节点足够多并形成网络，这样的交易网络足可以颠覆传统巨头所建立的商业模式
• 在中国，任何有影响力的网络都是极度危险的，必须让网络可控且局限在政策圈定的范围内
• 参与交易者建立网络的成本要足够低。直销人员的网络就是身边的亲朋好友，不需要再重新建立产生交易所必须的网络
• 买方有实际需求是直销网络赖以存在下去的基石。尽管会有因基于朋友间的面子问题而购买所推销商品的现象，但一个良性的网络要长期存在，买方必须对此网络所兜售的商品有所需求，肯定不单纯只靠朋友间的友谊 
• 只要产品品质不错，交易门槛不高，大部分人并不反对成为个人分销商，通过口碑传播产生交易是可行的

    在互联网上，鲜有普通个人作为分销商/代理商的成功案例，大部分都为少数的意见领袖的例子。以曾经被寄予期望的个人博客为例子说说

    在个人博客兴起的时候，大家曾经将个人博客的盈利模式寄期望于Google Adsense为基础的联盟营销和付费评论（Paid Reviews），但最终效果并不显著，原因有很多，但从电子商务交易角度来看，我觉得有如下原因：

    1、除个别发烧级的博主外，大部分人的生活并不是完全依赖虚拟化的网络。要在真实的关系链重构一个基于虚拟关系链的网络并在这个发挥影响力，对大部分人而言很难。

    2、交易的门槛太高，交易过程太繁琐：要保持一定的更新频率和话题热度才能够吸引足够多的粉丝，这样才可能将流量转化为交易，这对于大部分博主而言基本为不可能的任务。即便对那些资深的博主而言，总可以见到抱怨：通过google adsense赚的钱必须积累到一定的额度才能兑现，且兑现过程极其麻烦

    3、对订阅博客的人来说，通过博客产生交易的需求及动力并不足

    4、博客的媒体属性，让其很难成为一个产生交易的分销渠道：付费评论并不是每个博主愿意做的，尤其是对那些有影响力的博主，更不屑于做这样的事情；

    传统线下分销模式和互联网分销模式下参与游戏的基本上只能为有一定实力的商家，这与其商业形态有关。而在移动互联网时代，始终联网的移动终端+具有普遍性需求的产品或服务+快捷的支付方式+基于熟人间的准实名身份+关系网等几种因素的结合，可以让每一个普通用户轻松变成产品或服务的代理商或分销商。夸张地说，在移动互联网时代，“人人都可以是分销商”。

    在移动互联网时代，渠道为王的理念依然管用，个人仍然可以成为交易环节的渠道提供者，主要受如下一些要素的影响：

    1、用户始终在线，让随时随地交易成为可能。而传统线下或传统互联网很难做到这一点

    2、线下线上的边界逐渐模糊，尤其是随着移动互联网的普及，诸如移动支付、移动电子商务的基础设施的成熟后

    3、线上与线下关系链的融合

    4、微博等与移动互联网结合紧密的社会化媒体的兴起，让口碑传播迅速

    5、相对便捷的支付方式的出现（例如快捷支付），让交易更加便捷

    6、准实名。例如手机号，基于熟人的网络等

    7、适合分销且具有普遍需求的产品或服务

   以具有普遍性需求的手机充值业务来说，传统线下渠道要成为手机充值代理必须受如下限制：

    1、必须具备一定的代理资质

    2、充值终端只能依赖于具体运营商，只能服务于某个运营商，不能跨运营商服务

    3、必须预存一大笔钱到运营商账户中，即便采用银行代扣模式也极其麻烦

    4、服务的对象只能局限于某个区域的线下客户，线上渠道基本没有

    5、基本上无太多的营销手段可用

    6、手机充值利润很薄，只能作为一种吸引流量的业务

    在互联网模式下，虽然手机充值的服务提供商大多是第三方服务提供商，但要成为手机充值代理，仍然存在一定的限制：

    1、必须具备一定的资质

    2、必须预存一大笔前到服务提供商账户

    3、服务对象基本局限在线上客户

    4、手机充值利润很薄，只能作为一种吸引流量的业务

     以上因素基本限定了个人用户很难成为线下代理或互联网代理。

    而在移动互联网时代，个人只需要有一个智能终端和一张能够实时扣费的银行卡（例如支持快捷支付），就可以成为一个合格的手机充值代理，可以随时随地提供为身边的亲朋好友提供手机充值服务及其他的各种服务。尽管手机充值业务本身也不一定能够带来多少服务，但如果身边有一个朋友能够随时帮助提供各种生活化的服务，那我们是不是会选择其服务呢？

   对服务提供商而言，普通个人代理的核心价值不一定是为服务提供商带来多少收入和毛利，而在于围绕普通个人代理那张现实的关系网及渠道，而这张关系网对一个产品的口碑传播通路恰恰是一个移动电子商务产品或服务引爆流行的核心所在。另外一个产品或服务如果能够让普通用户参与到产品运营与营销中来并从中分享利益，这是对用户最好的激励。

   口碑传播是产品进行营销最理想的的手段。一般情况下我们都依靠好的产品或服务来获得用户由衷的支持并主动在关系圈中义务对产品进行传播。如果好的产品+恰当的激励机制，那对于口碑传播应该有更好的促进作用，同时对提高用户对产品的粘性无疑有积极意义。

   个人代理的模式并不一定适合所有的行业，但对于一些初创型的移动互联网公司而言，发挥每一个个人的影响力及资源，让每一个用户都成为自己的渠道，那么在此基础上，足可以诞生出新的业务模式，颠覆那些传统巨头们长久以来所建立的模式。

    从开放平台的服务对象来看，本质上仍然分为两大类：

• 为C端的用户提供服务：典型代表为Facebook
• 为B的用户（商家）提供服务：典型代表为Salesforce

    在互联网时代，不管是为C端用户还是B端用户提供服务，从技术角度而言，互联网时代开放平台的的所有应用都在开放平台服务提供商的服务器端运行（按照时髦的叫法应该称为：“云端”、“云计算”），用户只需要通过标准的浏览器访问即可。而对B端用户，即便有开发工作，由于Web端的开放人员相对容易找到，因此也不是大的问题。

   毋庸置疑的是，由于移动设备移动化、个性化、隐私性、具备地理位置信息等特征，导致移动互联网与传统互联网存在较大的差异。对各种线上线下的企业而言，各种“SoLoMo”、“O2O”、“移动支付”、“移动电子商务”等时尚术语描绘的前景无不说明其中所蕴含的机会，但也蕴含着众多的挑战。

    在移动互联网时代，对于Facebook这样为C端用户提供服务的开放平台，由于其应用主要都为云端应用，因此只需要按照自己的移动互联网战略规划，推出自己相应的app应用或HTML5应用即可。

    对大部分商家而言，不是不想赶移动互联网的热潮，而是目前移动互联网门槛太高：企业没人懂移动互联网，无法形成适合企业实际需要的移动互联网战略；移动互联网人员成本高，企业养不起自己的产品开发人员；即便拥有自己的客户端，也没有太多的应用可粘住用户，以及怎样运营客户端等等。

    这些问题解决的核心在于：怎样帮助企业降低移动互联网门槛呢？对于这些问题，是否可以采用互联网开放平台的思路来解决呢，尤其是在一些基础性的领域，例如移动支付、移动电子商务等等？

• B端商家的移动互联网战略是什么？

         问题：大部分商家都意识到了移动互联网的机会，但对怎样推出真正适合自己企业需要的移动互联网战略毫无概念。是否需要推出单独的移动互联网战略，还是继续沿用互联网的战略？

         机遇：开放平台提供商可以发挥自己熟悉移动互联网的优势，深入垂直行业，帮助各垂直行业的企业找到适合企业发展需要的移动互联网战略，并推出对应的移动互联网解决方案。

• B端商家是否具有移动互联网的专业人才，包括产品人员、技术人员、运营人员等，是否有能力研发自己单独的应用？

         问题：当下移动互联网处于虚热状态，相关的专业人才极度匮乏，人力成本也极高，对一般的商家而言（例如大量的中小B2C、个人站长），很难养活这些专业的移动互联网人才。

         机会：如果能够通过开放平台等模式降低商家使用移动互联网的成本，那无疑可以获得大量商家的欢迎。

• B端商家如果推出自己的客户端后，怎样提供有粘性的应用，让用户愿意持续使用；还包括商家怎样推广自己的客户端、运营客户等

         问题：关于移动互联网的误区之一在于似乎只要推出自己的客户端，将已有的Web应用迁移到客户端上即可。但对于移动客户端而言，如果没有太多有粘性的应用，用户即便安装后，可能会永远不使用或直接卸载掉；但对于大部分商家而言，要自己提供有粘性的应用，有很大的难度；在开发出来后，怎样推广自己的客户端，游说用户安装自己的客户端；怎样运营自己的客户端用户等等。

         机会：如果能够通过开放平台形式，打包一些有粘性的行业应用以插件形式提供给商家客户端；或是针对某个垂直行业做客户端，以免费形式或freemium形式提供给商家；针对诸如app store、android market及互联网营销手段帮助商家推广客户端、做客户运营等。

    以上问题只是当下传统商家转向移动互联网时候面临的一些典型问题。尽管移动互联网时代的开放平台仍可以用互联网的开放平台的理论来解读，但由于移动互联网本身区隔于传统互联网的各种特征，以上问题为移动互联网时代新的开放平台的诞生提供了机遇，也为在传统互联网不具备优势的服务提供商提供了巨大的机会。

    当然正如互联网的开放平台最核心的问题不是技术的开放，而是心态的开放，移动互联网时代的开放平台也如此。很多提供移动互联网服务的公司其实都看见了开放平台所能带来的价值，但关键是能否有勇气去否定自己成熟的业务模式去面对全新但尚不确定的未来。

    其实对于大部分从事移动互联网的企业而言，尽管在传统互联网领域上彼此存在较大的竞争关系，但在移动互联网领域，在当下尚未有成熟的商业模式可供山寨的情况下，各自最大的竞争对手可能不是其他的竞争对手而是移动互联网的基础设施、用户习惯等等，尤其是像移动支付这样全新的领域，从培育产业链、用户使用习惯等角度而言，彼此间的合作关系的意义可能更大于竞争关系。

    为何一些原本简单易用的产品在经过几轮升级后，会变得如此垃圾呢？为何那么多的产品中，经过升级后能够越来越好的产品或服务极其缺少呢？

    一个产品之所以能够称其为好产品首先决定于产品的愿景目标，其次是产品设计的核心设计理念，最后才是产品的设计和实现的方法。

    在某个阶段做一个好产品相对容易，只需要产品提供的核心功能能够满足用户的需求就可以了，但要在一次一次的版本更新中，持续不断是做出与时俱进的好产品就很难，尤其是面临各种变化和诱惑：产品战略的变化、产品团队的变化、用户的变化、竞争态势的变化等等，以及在变化过程中的各种诱惑。这些变化和诱惑都可能导致产品升级过程中产品愿景目标、核心设计理念、细节设计的变化，最终导致产品升级的失败。

产品战略的变化：

    公司整体产品战略的变化，可能导致某个产品在公司地位的变化，从而影响产品的战略、定位、策略等，而这种变化对某个产品的影响可能是致命性。以Google Reader为例，Google近期的社会化的战略重点是Google+，因此Google Reader、Gmail等所有的产品都必须围绕与Google+整合进行调整。这样导致在 Reader的改版中，对社会化分享进行了较大调整。为了产品间所谓的协同效应，毁掉了多少产品的美好未来。

产品团队的变化：

    原有负责产品的人离职或不再负责，所谓“不破不立”，新人总有否定并推倒原有产品设计的冲动，这样方能体现自己工作的价值，而且新人对产品的愿景、设计理念大都有自己的一整套方法论，因此在做新一版本的产品设计时候会采用自己的方法论去重构产品，因此尽管只是老版本的升级版本，但产品团队、设计理念都早已变化。

    与产品团队相关的还包括新人能力、对产品的感情、热情等方面的原因。

目标用户的变化：

    随着用户数的快速增加，用户群也随之裂变，各类用户提出了貌似合理的形形色色需求。为了满足不同用户群的需求，产品不断新增功能，产品越来越臃肿。同时由于市场的成熟及竞争态势的变化，目标用户群的选择不再单一，用户对产品的期望值也有所变化。原有衡量优秀产品的标准可能也已变化，在此情况下，所有产品升级都面临如此的挑战：变还是不变，怎样变？怎样与时俱进？怎样均衡不同用户的需求和期望值？

竞争态势的变化：

    由于竞争对手的杀入，尤其是竞争对手推出了颇具竞争力的类似产品，为了保持自己的竞争力，产品的重点不再是关注怎样更好满足用户的需求，不再是保持自己的节奏和独有风格继续发展，而是在关注竞争对手在做什么然后相互山寨，匆忙之下推出一个又一个与竞争对手大同小异的新版本，最终产品变成了没有生命力和灵魂的垃圾。

成功的副作用：

    即便是同样的产品团队，在老版本大获成功后，新版本与老版本在品质上可能也是相去甚远。原因有很多，一个典型的情况是：在老版本时候，由于资源相对有限，不允许团队有太多想法，因此必须抵御住各种诱惑，专注于最重要的核心功能；另外由于团队成员都对成功有极度的饥饿感，大家还持有对产品的热情及共同目标。

    成功后，资源不再是最大问题，因资源、时间、资金等因素压抑许久的各种“伟大思想”呼之欲出，顿觉所有的方向都是机会，都是为竞争对手筑起的竞争壁垒。专一、简洁成了保守者的代名词，平台化、多元化、一站式成了新的团队术语。

    以前版本的大获成功，在我们这个成王败寇为唯一标准的国度，成功掩盖了团队所有的问题，公司资源无限倾斜，领导者的欲望也急剧膨胀，而团队目标不再单一，成功的欲望及热情不再象以前那样强烈。团队拥有和被赋予更多的期望、更多的资源、更多的承诺、更多的内耗、更多的混乱，最终果实是更烂的产品。此类现象我们可以称之为“成功的副作用”。

无答案的问答

    怎样避免产品升级后越来越垃圾的陷阱呢，其实并没有什么标准答案。 以上问题其实很多时候并无绝对的对错之分，只是度的把控问题，同样的道理在不同的场景下讲对错就不一样。

    因此最核心的问题实际上在于怎样在产品目标、团队能力、团队欲望、节奏之间要找到一个合适的平衡点，与时俱进，这样方能应对变化万千的世界。一个团队从一个成功走向另一个更大成功更需要对目标无比的专注、对团队能力清醒的认识、对欲望的有效把控以及合理的节奏感。

    从Solr 1.3开始，Solr提供DataImportHandler工具完成对mysql数据库数据的操作。因此极大方便了Solr与Mysql的集成，因此可以借助DataImportHandler来完成Solr与Mysql的集成，基本思路如下：

      1、使用mysql的触发器trigger获取数据库表数据的增删改操作

      2、触发器通过mysql的用户自定义函数user-defined function (UDF) 包mysql-udf-http 调用Solr DataImportHandler对应的命令

      3、由Solr DataImportHandler完成增删改数据的索引操作。

    此种方案的优点在于将索引逻辑完全与应用的业务逻辑处理完全隔离，尤其是对批量导入、增量导入有其优势。

    下面简单介绍Solr与Mysql集成的方案。关于solr的配置及使用说明可参考《企业级搜索引擎Solr使用入门指南》及《企业级搜索引擎Solr交流》 ，这里主要说明与DataImportHandler相关的安装使用。

    测试环境说明：  

   操作系统：CentOS 5

   数据库：Mysql 5 ，直接使用了rpm安装的，mysql的lib库安装在/usr/lib/mysql

  Tomcat 6：tomcat安装在/opt/tomcat

  JDK 6

一、Solr安装配置

1）、Solr的安装

wget http://www.apache.org/dist//lucene/solr/3.4.0/apache-solr-3.4.0.tgz

tar zxvf apache-solr-3.4.0.tgz

cd apache-solr-3.4.0

cp -r example/webapps/solr.war /opt/tomcat/webapps/

cp -r example/solr/ /opt/solr-tomcat

cp -r dist/  /opt/solr-tomcat/

注dist目录下中有使用dataimport所必须的jar包apache-solr-dataimporthandler

将mysql的JDBC Driver mysql-connector-java-5.1.17-bin.jar拷贝到/opt/solr-tomcat/lib/下

 设定solr.solr.home

  在当前用户的环境变量中（.bash_profile）或在/opt/tomcat/catalina.sh中添加如下环境变量

export JAVA_OPTS="$JAVA_OPTS -Dsolr.solr.home=/opt/solr-tomcat/solr"

或

  mkdir –p /opt/tomcat/conf/Catalina/localhost

    vi  /opt/tomcat/conf/Catalina/localhost/solr.xml ，内容如下:

      <Context docBase="/opt/tomcat/webapps/solr.war" debug="0" crossContext="true" >

                 <Environment name="solr/home" type="java.lang.String" value="/opt/solr-tomcat" override="true" />

    </Context>

注：

   为了避免在Solr管理界面测试时候出现中文乱码问题，需要做如下设置：

   /opt/tomcat/conf/server.xml 中设定URIEncoding: 

          <Connector port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443"  URIEncoding="UTF-8" />

   /opt/tomcat/webapps/solr/WEB-INF/web.xml 设定过滤器

<filter>
    <filter-name>Set Character Encoding</filter-name>
    <filter-class>org.apache.catalina.filters.SetCharacterEncodingFilter</filter-class>
    <init-param>
        <param-name>encoding</param-name>
        <param-value>UTF-8</param-value>
    </init-param>
    <init-param>
        <param-name>ignore</param-name>
        <param-value>true</param-value>
    </init-param>
</filter>

<filter-mapping>
    <filter-name>Set Character Encoding</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

在xml请求数据中增加编码说明：

<?xml version=’1.0′ encoding=’utf-8′?>

<add>

<doc>

  <field name="id">123</field>

  <field name="name">Solr企业级搜索</field>

  <field name="manu">Apache Software Foundation</field>

  <field name="liangchuan">liangchuan’s solr "hello,world" test</field>

  <field name="url">http://www.google.com</field>

</doc>

</add>

3）、配置solr

cd /opt/solr-tomcat/

vi solrconfig.xml ,增加如下内容

<requestHandler name="/dataimport" class="org.apache.solr.handler.dataimport.DataImportHandler">
  <lst name="defaults">
    <str name="config">/opt/solr-tomcat/conf/data-config.xml</str>
    <lst name="datasource">
       <str name="driver">com.mysql.jdbc.Driver</str>
       <str name="url">

         jdbc:mysql://localhost/test?useUnicode=true&amp;characterEncoding=utf-8

       </str>
       <str name="user">user</str>
       <str name="password">password</str>
    </lst>
  </lst>
</requestHandler>

<lib dir="/opt/solr-tomcat/lib" />
<lib dir="/opt/solr-tomcat/dist" />

这里的data-config.xml就是DataImportHand
ler的配置文件

vi  /opt/solr-tomcat/conf/data-config.xml，内容如下：

<dataConfig>
  <document name="documents1">
        <entity name="documents"

          query="select id,title,content,date_added from documents"
          deltaImportQuery="select  id,title,content,date_added  from documents where ID=’${dataimporter.delta.id}’"
          deltaQuery="select id  from documents where date_added &gt; ‘${dataimporter.last_index_time}’"
        >
            <field column="id" name="id" />
            <field column="title" name="title" />
            <field column="content" name="content" />
            <field column="date_added" name="date_added" />
        </entity>
    </document>
</dataConfig>

关于DataImportHandler的详细使用请参考：http://wiki.apache.org/solr/DataImportHandler

这里就常用的用法简单说明：

query语句是用于批量导入（Full Import）中获取符合条件的全部数据的SQL。

deltaQuery语句是用于增量导入（Delta Import）中获取符合增量导入标准的数据的主键的SQL，供deltaImportQuery查询使用。

deltaImportQuery语句增量导入（Delta Import）中获取需要增量索引数据(document)的字段(field)

DataImportHandler的常见命令：

    批量导入（full-import）：

        http://<host>:<port>/solr/dataimport?command=full-import&commit=y
    增量导入（delta-import）：

        http://<host>:<port>/solr/dataimport?command=delta-import&commit=y
    导入状态查询（status）：

        http://<host>:<port>/solr/dataimport
    重新装载配置文件（reload-config）：

        http://<host>:<port>/solr/dataimport?command=reload-config
    终止导入（abort）：

        http://<host>:<port>/solr/dataimport?command=abort

Solr执行增量导入的大致原理：

    1、Solr 读取conf/dataimport.properties 文件，得到solr最后一次执行索引操作的时间戳last_index_time，以及单个实体最后一次执行索引的时间戳：entity_name.last_index_time

    2、Solr对指定的实体使用deltaImportQuery SQL查询得到insert或update时间戳大于${dataimporter.last_index_time}需要增量索引的字段，然后调用deltaQuery对符合条件需要执行增量索引的文档的字段进行索引，并更新dataimport.properties 的时间戳

数据库的测试表结构如下：

DROP TABLE IF EXISTS `documents`;
CREATE TABLE `documents` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `date_added` datetime NOT NULL,
  `title` varchar(255) NOT NULL,
  `content` text NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

4）、测试Solr配置

  在数据库中documents表中插入几条数据，然后

执行批量导入操作：

:/solr/dataimport?command=full-import&commit=y">:/solr/dataimport?command=full-import&commit=y">http://<host>:<port>/solr/dataimport?command=full-import&commit=y

执行增量导入操作：
:/solr/dataimport?command=delta-import&commit=y">:/solr/dataimport?command=delta-import&commit=y">http://<host>:<port>/solr/dataimport?command=delta-import&commit=y

在:/solr/admin">:/solr/admin">http://<host>:<port>/solr/admin执行查询操作，测试配置是否正确

二、mysql-udf-http 安装配置

wget http://mysql-udf-http.googlecode.com/files/mysql-udf-http-1.0.tar.gz

tar zxvf mysql-udf-http-1.0.tar.gz

cd mysql-udf-http-1.0/

./configure –prefix=/usr –with-mysql=/usr/bin/mysql_config

make && make install

echo "/usr/lib/mysql/plugin" >> /etc/ld.so.conf.d/mysql-i386.conf

/sbin/ldconfig

/sbin/ldconfig -v|grep mysql

  如果没有类似如下的输出

   /usr/lib/mysql/plugin:
        mysql-udf-http.so.0 -> mysql-udf-http.so
   则建立mysql-udf-http.so 的软连接（当然也可以通过修改编译Makefile脚本）

ln -s /usr/lib/mysql/plugin/mysql-udf-http.so /usr/lib/mysql/plugin/libmysql-udf-http.so

  建立软连接后再执ldconfig 命令，使用/sbin/ldconfig -v|grep mysql是否有如下内容：

/usr/lib/mysql/plugin:
        mysql-udf-http.so.0 -> libmysql-udf-http.so
原因是mysql-udf-http的Makefile中指定了动态链接库的SONAME为mysql-udf-http.so.0 ，而ldconfig缺省只处理以lib开头的动态链接库（例如libmysqlclient.so.15），因此执行ldconfig命令时候忽略了mysql-udf-http.so 。

创建mysql的用户自定义函数：

mysql >

create function http_get returns string soname ‘libmysql-udf-http.so’;
create function http_post returns string soname ‘libmysql-udf-http.so’;
create function http_put returns string soname ‘libmysql-udf-http.so’;
create function http_delete returns string soname ‘libmysql-udf-http.so’;

三、创建调用mysql-udf-http的触发器

/* INSERT插入操作的触发器 */
DELIMITER |
DROP TRIGGER IF EXISTS documents_insert;
CREATE TRIGGER documents_insert
AFTER INSERT ON documents
FOR EACH ROW BEGIN
     SET @result = (SELECT http_get(‘http://www.yeeach.com/solr/dataimport?command=delta-import&commit=yes’));
END |
DELIMITER ;

/* UPDATE更新操作的触发器 */
DELIMITER |
DROP TRIGGER IF EXISTS documents_update;
CREATE TRIGGER documents_update
AFTER UPDATE ON documents
FOR EACH ROW BEGIN


60;    SET @result = (SELECT http_get("http://www.yeeach.com/solr/dataimport?command=delta-import&commit=yes"));
END |
DELIMITER ;

/* DELETE删除操作的触发器 */
DELIMITER |
DROP TRIGGER IF EXISTS documents_delete;
CREATE TRIGGER documents_delete
AFTER DELETE ON documents
FOR EACH ROW BEGIN
        SET @result = (SELECT http_get(CONCAT(‘http://www.yeeach.com/solr/update/?stream.body=<delete><id>’,OLD.id,’</id></delete>&stream.contentType=text/xml;charset=utf-8&commit=true’)));
END |
DELIMITER ;

四、测试

  在数据库执行增删改操作，然后在Solr的管理界面执行查询操作，测试触发器调用mysql-udf-http是否正常。

五、参考资料

DataImportHandler文档：http://wiki.apache.org/solr/DataImportHandler

Mysql UDF的大本营：http://www.mysqludf.org/

mysql-udf-http：http://code.google.com/p/mysql-udf-http/

    这里所指的移动问答服务并不是类似opinionaided、localmind这样相对宽泛的问答服务，而是类似于Ask a Nomad这样针对垂直领域的问答服务。这就意味着：目标用户群更为明确，但对用户的专业技能要求更高。 而且移动问答服务是垂直领域增强用户粘性的产品服务之一，而非独立服务。

    对一个全新的移动问答服务而言，问答内容和用户始终是鸡生蛋、蛋生鸡的问题：在初期用户数较少的情况下，怎样保证问题的质量及回答的及时性。在内容较少的情况下，怎样保留住那些种子期的用户并激发他们持续贡献内容的热情。

   要解决这问题，内容运营策略至关重要。

1、问答内容运营的挑战

  问答的实时性

  问答的质量

  运营初期冷启动问题

  引爆点问题

2、内容运营重点

  问答平台内部各种内容运营

  微博、SNS社区等外部平台用户关系、专家导入

  问答平台与微博、SNS社区等外部平台间信息的互动

  怎样找到问答最佳的传播路径，将问题传递给最合适的人来回答

  怎样保持用户对问答服务持久的热情，尤其是那些对引爆点至关重要的角色：联系人、内行、推销员

    类似的同步功能其实并不复杂，只需要同步到的服务提供方提供的对应API接口。即使服务方没有提供API，也可以同步抓取报文模拟类似请求的方式完成（例如早期新浪微博接口不完善时候各种同步服务都这么干的）

    从接口来说，服务提供方一般提供：认证授权API、信息同步API

    从流程来说，一般涉及：账号认证授权阶段、信息同步阶段

    1）、账号认证授权阶段：

    服务提供方提供认证授权接口，然后由用户在同步方网站/客户端想服务提供方的网站发起授权请求，完成认证授权后，同步方获得了访问用户信息的权限。一般采用Basic认证、oAuth认证或xAuth。

    2）、信息同步阶段：

    尽管开放平台的概念大行其道，但对于国内的各种服务提供商而言，大都不希望信息在自己平台和其他平台间双向流动起来。用户或是直接在自己平台创造内容或是从其他平台导入各种内容，但不鼓励用户将内容从自己平台导出。因此一般对外提供的同步接口功能大都比较全面，但对于信息导出的功能都比较弱。

     对于以上两个阶段，对于外部的第三方应用而言，似乎可做的事情并不多，各种服务提供方的限制基本上决定了可以做的内容相对有限。

    一直也在思考怎样让信息双向流动起来的问题。一个典型的场景就是：如果我通过第三方的LBS客户端发布信息，LBS客户端同时将信息同步到了新浪微博，我在新浪微博上的好友在微博上对我的信息进行了点评，对于第三方的LBS客户端而言，最理想的情况是：朋友在新浪微博上的互动信息理应反向同步到LBS客户端上。

   其实类似的例子很多：怎样将信息从Twitter从新浪微博同步到Twitter，怎样将twitter信息同步为MSN状态等。一堆人都围绕此类功能提供了一堆hack的方法及工具。只不过此类工具的出路在那儿呢？似乎很难演变成一种业务模式，个人感觉在同步功能上并没有太多可做的文章了，想来那些提供了同步功能的客户端们也是抱有类似的想法。大家觉得同步功能无法成其为一种模式，只能沦落为工具而已，于是同步功能成了所有产品必备的功能，但又是最乏陈可味的功能。

    ifttt.com的出现，让人有眼前一亮的感觉，不由自主地感叹：ifttt的产品设计太天才了。其实从技术角度来说ifttt本身并不难，所以才会有国内一些公司在ifttt出来几天后就快速山寨出了类似服务。但恰恰是如此，才体现了ifttt产品设计的伟大之处：将我们认为无事可做的信息同步功能处理得如此优雅和cool。将一个复杂的事情以简洁方式展现出来是一种能力，能够将一件乏陈可味的事情以如此优雅的方式处理更是一种能力。

    ifttt的一些启示：

    1、好的产品必然有其内在的设计哲学、文化、气质及品位，而非各种功能的堆叠。对于ifttt这样的产品，我不相信只是其产品经理灵光一现的产物。这样优雅的设计，必然有其内在文化的沉淀。其实对于大部分公司的产品人员而言，做产品其实挺简单的：不就是通过各种渠道了解需求后（大部分都为山寨、山寨、再山寨），把这些功能做出来，然后持续完善罢了（美其名曰为微创新）。但这些一个个由功能堆叠起来的产品，最终只能为一个个平庸化的产品，并最终被遗忘掉。每一个好的产品背后必然有一个有思想、有品位的产品经理，优雅的产品必然是产品经理设计哲学的产物。因此要做出伟大的产品，首先培养我们自己关于产品的感觉、品位，形成自己的设计哲学。

    2、任何时代、任何市场都有机会，制约我们的不是机会本身的稀缺，而是我们的实力。对于同步这样的功能，我们认为没有机会了。自己也曾试图从信息双向同步角度去发现机会，但最终无功而返，最后抱怨平台不够开放等客观原因。所谓“市场已经饱和，没有机会了”的说法其实是一个伪命题，问题的关键是：我们能力有几何。

     3、玩透竞争对手的产品：使用ifttt时候，最大的体会之一是：ifttt对各种服务的功能太熟悉了，一直在使用twitter等服务，平常也从产品角度研究其设计，但对于这些产品的了解相对于ifttt太初级了。平常对竞争对手的了解基本就是浮光绿影、浅尝辄止，从战略、战术上都鄙视竞争对手，总是认为对于竞争对手我们已经有足够的了解了。一个很好的互联网产品销售负责人告诉我：他会每周都会去刷竞争对手的网站看新的产品、方案、招聘信息等，改进自己的营销策略、产品方案。想来也惭愧，我上一次仔细研究竞争对手的产品是什么时候呢，我是否真正做到了：从战略上蔑视竞争对手，从战术上重视竞争对手？

     4、我们低估了信息流动及信息挖掘的价值。ifttt只是对信息流动进行了简单处理，就引出了如此有趣的应用场景。如果能够对各种数据更深层次地挖掘、处理，促进数据在各种平台间的流动，那必将诞生各种有趣的应用和商业模式。

    5、能够用户带来价值就会有机会成为模式，就值得我们去做。受到那些靠平台化成就辉煌的故事的影响，我们不屑于那些工具性的产品，觉得工具性的产品用户粘性低，很难成其为商业模式，只有那些能够平台化的产品才有价值。商业模式成为我们是否做决定性的因素，其实原本应该是能否为用户带来价值才应该是决定性的因素。只要能够为用户带来价值，那这样的产品就有机会演变成为一种模式。

    其实很多业务模式和市场机会都有一个临界点的问题，例如用户数/商户数到一定数量、市场份额到一定额度、品牌知名度等。过此临界点后，有利因素之间会形成正循环，各种市场机会不断涌现，业务模式也会更加清晰。这不单纯只是规模效应问题，很多东西都需要实践去积累和沉淀。模式是运营出来的而非规划出来的。

    在中国特色的制度下，除了技术因素外，值得注意的是由于地图牌照发放问题带来的政策上的不确定性对架构实现的冲击和挑战。

    地图服务架构设计原则：

    1、高性能：由于目前的移动互联网带宽仍是较大的制约因素，在客户端用户的等待耐心有限，因此地图服务必须将性能作为首要设计要素。而且像google map之类的免费服务由于防火墙原因经常不稳定或异常缓慢，需要在架构设计时候重点考虑。

    2、低成本：尽管一些收费的地图服务已经提供了一些比较完整的地图数据、POI数据，但对于初创型的公司而言，资金有限，因此在技术能力许可的情况下，与其购买昂贵的服务，还不如采用低成本的DIY方案。

    3、架构灵活：能够适应客户端、服务器端服务的变化，能够应对政策因素等问题带来的冲击。可以在不同地图服务及本地服务间切换，不能因政策因素导致服务的不可用。

   4、持续积累：对于移动互联网公司而言，针对垂直领域POI数据及地图数据的积累也是产品的核心竞争力，因此架构必须有助于相关数据的积累。

客户端使用SDK访问地图服务 VS.  客户端访问自己服务器端代理

    a、如果由客户端直接访问google map之类的地图服务，则如果地图服务需要调整（例如需要从google map切换到其他地图服务、地图展示内容需要调整时候），都需要客户端升级；如果由服务器端代理完成，只需要服务器升级即可。

    b、服务器端可以缓存客户端频繁访问的地图访问请求（例如搜索周边、根据经纬度定位地图、根据地址定位地图等），可以极大提高性能

    c、服务器端可以在地图服务商的结果上，增加自己的一些操作及数据，例如服务器端可以聚合自己POI数据及其他服务提供商的数据，然后添加到google map结果集上

    d、客户端并不是很适合做一些复杂的计算，例如对于POI及其他内容数据的聚合、图层操作，服务器端来完成更合适

    当然采用服务器端代理的方式也有一些问题，例如google map对每天api调用次数可能有限制、采用客户端现成的SDK方式开发相对简单等。具体需要根据自己业务实际需要采用合适的架构。