ZooKeeper 典型应用场景一览

数据发布与订阅(配置中心)

发布与订阅模型,即所谓的配置中心,顾名思义就是发布者将数据发布到ZK节点上,供订阅者动态获取数据,实现配置信息的集中式管理和动态更新。例如全局的配置信息,服务式服务框架的服务地址列表等就非常适合使用。

1. 应用中用到的一些配置信息放到ZK上进行集中管理。这类场景通常是这样:应用在启动的时候会主动来获取一次配置,同时,在节点上注册一个Watcher,这样一来,以后每次配置有更新的时候,都会实时通知到订阅的客户端,从来达到获取最新配置信息的目的。

2. 分布式搜索服务中,索引的元信息和服务器集群机器的节点状态存放在ZK的一些指定节点,供各个客户端订阅使用。

3. 分布式日志收集系统。这个系统的核心工作是收集分布在不同机器的日志。收集器通常是按照应用来分配收集任务单元,因此需要在ZK上创建一个以应用名作为path的节点P,并将这个应用的所有机器ip,以子节点的形式注册到节点P上,这样一来就能够实现机器变动的时候,能够实时通知到收集器调整任务分配。

4. 系统中有些信息需要动态获取,并且还会存在人工手动去修改这个信息的发问。通常是暴露出接口,例如JMX接口,来获取一些运行时的信息。引入ZK之后,就不用自己实现一套方案了,只要将这些信息存放到指定的ZK节点上即可。

注意:在上面提到的应用场景中,有个默认前提是:数据量很小,但是数据更新可能会比较快的场景。 Continue reading “ZooKeeper 典型应用场景一览”

FastTpl – 轻量级模板解析引擎

〇、前言

在PHP开发者当中,流行的Smarty模板引擎已是无人不知,它的功能丰富强大,出现的时机也恰到好处。

但是为什么我还需要开发这么一个模板引擎呢,初衷有三:

1、我不需要太复杂的模板设计,需要的是简单易学,团队成员能够快速入手,并且易于维护的模板引擎;

2、Smarty虽然功能丰富,但过于臃肿,执行效率低,我需要轻量级的模板引擎,它需要执行起来特别高效;

3、我需要前端和后端的技术都能够使用,因此它既需要有自己的模板标签,同时也支持原生的PHP文件作为模板; Continue reading “FastTpl – 轻量级模板解析引擎”

面向服务(SOA)与微服务(MAS)架构

微服务架构强调的第一个重点就是业务系统需要彻底的组件化和服务化,原有的单个业务系统会拆分为多个可以独立开发,设计,运行和运维的小应用。这些小应用之间通过服务完成交互和集成。每个小应用从前端web ui,到控制层,逻辑层,数据库访问,数据库都完全是独立的一套。在这里我们不用组件而用小应用这个词更加合适,每个小应用除了完成自身本身的业务功能外,重点就是还需要消费外部其它应用暴露的服务,同时自身也将自身的能力朝外部发布为服务。

Continue reading “面向服务(SOA)与微服务(MAS)架构”

Google镜像站点

来源:http://coderschool.cn/1853.html

原版页面:

https://gufen.ga/ (无广告,原guso.ml,ggso.ga,guge.ga)

https://www.aiguso.ml/ (无广告,体验良好)

https://g.qqmmgj.com/ (无广告,体验良好)

https://google.gg-g.org/ (无广告,体验良好)

https://www.xichuan.pub/ (无广告,体验良好)

https://nginx-google.arukascloud.io/ (无广告,体验良好)

https://ggso.me/    (有广告,体验良好)

https://gugeabc.xyz/ (无广告,体验良好)

https://a.ggkai.men/(有广告,体验良好)

http://google.suanfazu.com/ (整合搜索,非原版)

https://g.caisan.ml (无广告,体验良好)

https://kuaiguge.info (无广告,体验良好)

https://g.zmirrordemo.com/ (第一次访问需验证)

https://google.tse.moe/ (部分地区被qiang)

https://zh.bywiki.com (维基百科 部分地区被qiang)

http://gg2.firstguo.com/ (有弹窗广告,体验一般)

Continue reading “Google镜像站点”

Vue.js介绍

Vue.js是当下很火的一个JavaScript MVVM库,它是以数据驱动和组件化的思想构建的。相比于Angular.js,Vue.js提供了更加简洁、更易于理解的API,使得我们能够快速地上手并使用Vue.js。

如果你之前已经习惯了用jQuery操作DOM,学习Vue.js时请先抛开手动操作DOM的思维,因为Vue.js是数据驱动的,你无需手动操作DOM。它通过一些特殊的HTML语法,将DOM和数据绑定起来。一旦你创建了绑定,DOM将和数据保持同步,每当变更了数据,DOM也会相应地更新。

当然了,在使用Vue.js时,你也可以结合其他库一起使用,比如jQuery。

本文的Demo和源代码已放到GitHub,如果您觉得本篇内容不错,请点个赞,或在GitHub上加个星星!

v-for Demo v-bind Demo Page Demo GitHub Source

Continue reading “Vue.js介绍”

开源软件中的License

什么是License

许多混乱就始于你不知道License到底是什么,到底有什么含义。当你对你的产品使用License时,并不意味着你放弃了任何权利,你依然对其拥有原著作权。License只是授予他们于特定权利来使用你的产品。

License只是把你的作品释放到公有领域,或者给各个拷贝赋予权限。也意味着你放弃了版权收入,别人也没有义务把你列为原作者或贡献者。

开放源代码许可协议更容易为他人作出贡献,而不必寻求特别的许可。它也可以保护你作为原创者的权利,至少确认了你的贡献。它还可以保证你的工作不为别人所剽窃。

Continue reading “开源软件中的License”

p3p header在单点登录的cookie跨域中的应用

场景一:

A网站全站均为UTF-8编码,B网站全站为GB2312编码。

A网站提供一段JS代码供B网站调用,该代码会动态生成一个FORM表单,以收集提交上来的数据。

B网站此时开始提交数据,但提交上来的中文均为乱码 。

现象的产生是由于二个网站编码不一致而导致的,一般情况下使二个网站的编码一致即可。

如果无法统一编码该怎么办?

FORM有一个accept-charset属性

<form method=”post” action=”…” accept-charset=”utf-8″> 
…  
</form>   

测试成功,但在IE下不成功,需要一个HACK来解决:
在form的onsubmit事件触发时动态改变document的编码,即:

onsubmit=”document.charset=\’utf-8\’;”

场景二:

A网站提供一个页面供其它网站进行Iframe调用,该页面使用了SESSION,并进行了SESSION判断。

现象:

B网站IFRAME了A网站的页面,总显示SESSION过期,但直接在浏览器中打开该页面却又是正常的。

这是由于浏览器的安全性所致,SESSION依赖于COOKIE,A与B是二个完全不同的域,A网站没法去读取B网站下的COOKIE,所以 SESSION也就失效了。

解决办法:

A网站的页面在输出头上附加一个P3P属性,值为CP=CAO PSA OUR即可。
如:

Response.AddHeader(“P3P”, “CP=CAO PSA OUR”);  
if (Session[SESSIONKEY] == null)  
{  
   //TODO:其它操作  
}  

在IE中,页面通过FRAME,JS,IMG等引用其他域名页面的时候,P3P协议会阻止引用也的cookie。

举例说明:

在 B.COM中,

  1. <iframe width = 300 height = 300 src = ”http://www.a.com/test.php” mce_src = ”http://www.a.com/test.php”>

此时,test.php中产生的cookie将会被阻止,而不会记录下来
这种情况下,我们引入P3P header ,情况就改变喽~
P3P header允许跨域访问隐私数据,从而可以跨域set-cookie成功
在 www.a.com/test.php中这样写:

  1. header(\’P3P: CP=”CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR”\’);

cookie就可以跨域了~

这种方法
在单点登陆中被别广泛应用~

DoxyGen常用标记

Doxygen可以为C++, C, Java, IDL (Corba and Microsoft flavors) PHP和C#生成文档 


大致用途有三:
1. 可以生成一个在线html文档或者一个离线的LATEX格式文档也支持RTF(MS-Word) PostScript, hyperlinked PDF, compressed HTML, 和Unix man pages多种格式生成。文档直接由源码生成,这使得保持文档和代码一致性更加轻松。 


2. 可以配置doxygen从无文档的源码中提取代码结构。这就便于在大型源码中迅速上路。也可以将这些不同元素间的关系使用图形表达出来,包括依赖图,继承图和collaboration图,这些都是自动生成的。 


3. 甚至可以使用它来生成平常的文档,例如手册

标记以“\”开头,或是一个“@”(使用JavaDoc风格),后面是命令名和一或多个参数。

这些标记都是写在注释块中的,详见随邮件的例子(_common\obj.h)。

说明类型:
分为摘要说明和详细说明
   \brief 后紧跟摘要说明,也可以直接使用“//!”开始注释。
  
详细说明:在摘要说明后,间隔一行书写,见实例。
  
基本结构的说明标记:
\file [file name] 写文件的说明, 后跟此文件的文件名;另起一行书写此文件的说明文字。
\class [class name] 写类的说明,后跟类名;另起一行书写类的说明文字。


用于函数内部的说明标记:
这些标记会在函数的详细说明中使用不同的字体和格式,突出显示。
\param [param name] 写函数参数的说明,后跟参数名;紧跟参数的说明文字。
\return     写函数返回值得说明,后紧跟返回值得说明。
\warning    警告,后紧跟警告的内容。
\remarks    评论,后紧跟评论的内容。

可单独生成主题的说明标记:
\todo     被此标记说明的代码会在Todo列表中出现。
\bug     被此标记说明的代码会在Bug列表中出现。
\test     被此标记说明的代码会在Test列表中出现。
\deprecated    被此标记说明的代码会在deprecated列表中出现。

\defgroup [group name] [brief] 定义一个代码块,可对代码块写说明;注意group name必须是唯一的;
           另起一行写详细说明
   \{ 代码块开始
   \} 代码块技术


格式化说明标记:
– 主题
   -# 子标题1\n
    说明
   -# 子标题2\n
    说明
生成文档中可显示为编号的列表
注意:在注释中,可完全使用html格式化标记。

@author           作者
@brief              摘要
@version          版本号
@date              日期
@file                文件名,可以默认为空,DoxyGen会自己加
@class             类名
@param            函数参数
@return            函数返回值描述
@exception       函数抛异常描述
@warning         函数使用中需要注意的地方
@remarks        备注
@see               see also字段
@note             brief下空一行后的内容表示详细描述,但也可以不空行用note表示
@par               开始一个段落,段落名称描述由你自己指定,比如可以写一段示例代码
@code             引用代码段
@endcode       引用代码段结束
@pre                函数前置条件,比如对输入参数的要求
@post             函数后置条件,比如对系统状态的影响或返回参数的结果预期

不太常用的标记:

@defgroup       模块名
@name             分组名
@{                   模块开始
@}                   模块结束
@deprecated     今后可能将被废弃或已经有替代品的函数
@since             从哪个版本后开始有这个函数的
@todo              被标记的代码会在ToDo列表中出现
@bug               被标记的代码会在Bug列表中出现
@test               被标记的代码会在Test列表中出现
–                      一级项目符号
-#                   二级项目符号

2012,当我们谈论移动互联网创业时,我们在谈论些什么?

2012年的移动互联网市场可以用“冰火两重天”来形容。

根据Google官方数据,Android设备激活量在2012 年3-6月4个月内,由3亿部增长至4亿部,增长率为33%。据苹果官方数字,iOS设备激活量从2012年4-6月由3.6亿部增长至4.1亿部,增长 了12%。而对于中国市场,根据友盟的数据,2012年第二季度Android App启动次数增长159%;iOS活跃设备增长42%,iOS App启动次数增长112%。 这些数字都表明了移动互联网用户和终端量在2012年仍在高速增长。

但另一方面,移动互联网创业之路却愈发举步维艰:同质化竞争加剧,推广成本攀升,盈利模式迟迟未能清晰,投资者的钱也烧得差不多了……

但移动互联网始终是座巨大的宝藏,吸引着无数人甘愿冒险探寻。那么当前,如何度过寒冬,成功地求生是每个创业者、投资人都在思考的问题。本文中我将列举几个2012年移动互联网创业的关键点进行讨论,内容仅供引发思考,不做结论。


创业机会在哪里?

洗牌前期,巨头们开始以各种方式大肆进驻。一方面是以腾讯为代表的巨头正在进行全面的软件布局。目前腾讯已推出了几十款覆盖各个平台的App,涵盖了社交、 浏览、订阅、输入、同步、安全、音乐、游戏、阅读等领域,以强大的资金、渠道和人才优势与大批创业者直接竞争。另一方面,百度、阿里巴巴、奇虎360、盛 大等公司开始竞相推出搭载自己定制的操作系统的手机,抢占移动互联网的入口……

如果比拼渠道、资金和对人才的吸引,小公司毫好无胜算。因 此,在巨头驻足的通用领域,采取与巨头直接竞争的方式异常艰难。那么,在这种环境下创业者在创新方向选择时可能需要考虑“垂直化”和“行业化”,更多地去 挖掘那些还未被发现或者巨头没有兴趣去做的细分市场。在游戏、SoLoMo、O2O、移动电商、儿童教育等直接可以从消费者手上收钱的领域都有机会,在整 个行业的真实收入迅速攀升的基础上,移动广告、开发工具、各种外包等周边产业也会迎来相应的繁荣,与之相关的风险投资、孵化器、财务、法务、媒体、人力资 源等领域也会被拉动,各种企业的移动化也需要“行业化”应用的推动。在这些方向上,都尚未出现真正集大成、占据绝对优势的产品,如果能做出好产品加上合适 的分发渠道,创业者仍然有机会。

同时“硬件化”也是一个选择方向。随着中国二三线城市智能手机的普及,智能手机的细分市场也开始成型,针对 不同性别、层级、年龄段消费者的手机需要配套的软件和系统定制,因此这个层面上创业者与厂商间的软硬整合合作也存在一定的机会,当然,其中还包括平板、智 能电视等领域。

Native App还是Web App?

记得2011年时,Web App的概念大行其道,同时伴随着Adobe Flash Player的诸多不利消息,一时间HTML5被一些人捧上了制高点。但近期,Flash产品(首当其冲是游戏)开始全面爆发。依靠着Adobe AIR、Stage 3D等强大技术的布局,移动设备上开始涌现大量高品质的Flash游戏。而HTML5却从云端跌回残酷的现实:HTML5移动游戏领域的早期探索者 Moblyng倒闭,Mark Zuckerburg亲口承认Facebook的HTML5战略是个错误,Chrome Web Store里面力推的游戏表现都不甚理想……由于表现能力不足,自身标准一直未确定,并且缺少Web App分发和盈利的渠道,导致HTML5阵营中并未出现拿得出手的成功案例。也许就像一位开发者曾经说过那样:“HTML5是未来的趋势,但不是现在的优 势。”

毫无疑问,每种技术方案都各自有其优劣之处,必须要根据实际情况灵活选择。例如对于许多交互不多的传统内容型网站来说,HTML5已 基本可以覆盖全部需求。但在目前Web App受限于浏览器或前端技术未标准化的情况下,开发者可以考虑进行组合应用,对于侧重性能、体验、设备特性、本地数据管理等HTML5表现力达不到的部 分用Native来做,HTML5表现力能达到的部分就用HTML5来做。

总的来说,开发者应该掌握并提前布局多种技术,不能在一棵树上吊死。

最好的盈利模式?

无论怎样,成功不是一时半会儿的事,“活下去”是当前最重要的话题。由于投资锐减,创业者需要更多、更早地去考虑盈利问题。其实目前的移动互联网有一系列的盈利模式可供开发人员选择:

  • Pay-Per-Download。下载支付,为获得App使用权一次性支付费用。
  • In-App Purchasing。应用内购买,通常是一些应用的功能、提升游戏等级以及虚拟商品,目前是大陆最容易获得高收入的模式。
  • Subscriptions。订阅,一般是逐月为App付费,《程序员》杂志等阅读类App通常会采取这一模式。
  • Freemium。免费下载,提供增值付费服务,在Evernote等工具类应用中常见。
  • Commissioned Applications。提供外包服务。
  • In-App Advertising。App内展示广告模式和传统互联网的广告模式十分接近,被开发者大量使用,但效果渐减。
  • Product Placement。植入式广告,例如在游戏中的某一道具就是某品牌的饮料。
  • Purchase Intermediation。为从第三方App中带来的流量或其他资源拿到分成,但在大陆也常常演变为资源、流量互换。
  • Per-unit royalties。通常是与终端厂商和各大平台合作,例如厂商为手机上预装付费等。
  • Distribution Exclusivity Deals。针对独家应用商店发部应用,前段时间Rovio的《Amazing Alex》通过应用汇发布时似乎就采用了这种模式。

在 2012年6月VisionMobile对全球1500名创业者的调查中发现,Pay-Per-Download是当前最频繁使用的盈利模式。共有34% 的创业者选择了这种方式,较2011年相比略有下降。紧随其后的就是In-App Advertising,占33%。而从今年起,In-App Purchasing模式开始火热,已跻身高回报的收益模式之一。

但创业者需要明白,没有最好的模式,只有最适合的模式。而选择标准往往取 决于他们的产品模型、规模和目标市场。例如在大陆,游戏用户很难为一款未知的游戏下载付费,因此In-App Purchasing在今年大肆流行。而对于一些理财类工具,用户反而愿意付费来选择高品质的产品来保证自己的安全和隐私。同时,对于同一款产品,在不同 阶段“盈利模式”也可以转型,《Angry Birds》就是最好的例子,在长期霸占App收费榜前排位置之后,随着新产品的推出和游戏生命周期到来,小鸟们已从排行榜上跌落,却找到了更为稳健的盈 利模式:其周边产品和授权费为其带来了丰厚的回报,当然在大陆这种模式可能会被山寨得让人吐血。

生态系统困境

再好的产品也需要依靠良好的分发渠道和健全的市场,可2012年的中国移动互联网生态系统可谓满目疮痍,大部分开发者都多多少少面对迷局。对于中国开发者而言,山寨术依然是亘古不变的话题,而在这之外,新的问题接踵而来。

App Store一度帮助苹果打造了最优秀的移动生态系统。但2012年的种种迹象表明,这片生态系统似乎正在遭受侵蚀。刷榜问题日益严重,在2012年3月 时,App Store曾经采用技术更新的方式阻止刷榜,但也默认了对之前刷榜严重的公司不追究。果不其然,苹果的这种“不作为”态度让新算法仅见效2个多月,一股新 的刷榜风潮就开始愈演愈烈。有开发者认为苹果应该像Google Play那样摆出“令可错杀一千,不可放过一个”的态度,然假设如此,想必肯定会有无良对手花钱帮你“刷榜”,让你欲哭无泪。

同样,在 Android的第三方市场,刷榜也是同样泛滥。因此,有许多国内的开发者和媒体开始曝光和谴责这些产品。但从市场层面来看,这种影响并不会波及到消费 者,倘若刷榜风险和成本极小,加上一些投资人“有钱赚,怎么赚都是赚”的纵容态度,那么必定会有更多的人铤而走险。

除此之外,App Store审核周期常常是漫长且毫无规律可循;去对手产品下面刷差评;有程序员直接拿别人游戏安装包破解反编译加入自己的广告账号,放渠道上偷广告流 量……开发者不仅要注意暴风雨和暗礁,还需要迎战其他船只的攻击,移动互联网生态圈的困局还有多久才能解开?

不过在2012年9月17日,App Store出现7小时的“锁榜”现象(指整个榜单全部锁住,排名几乎不动,偶尔有一两名上下的波动只是因为某些限免App到期,从免费应用榜单下架所 致)。这个情况与2012年3月20日(上一轮排名算法完全改变的前2天)出现的7小时锁榜现象如出一辙。因此,有人预测排名算法即将再次大调整,希望会 带来一些积极有效的变革。

走向海外?

虽然有一些应用在中国也取得了不错的成绩,但暂时而言,大陆终归是付费意愿较低的市场,并且还有着前文提到的各种恶劣的竞争环境,在此状况下,走“国际化” 战略似乎是个不错的选择。实际上,如今中国移动互联网的很多明星团队已走向海外、专注海外甚至如《海豚浏览器》这样“来自海外”。

成功者固然令人艳羡,但成功的路却并非所见即所得。作为一个统称,海外市场实际上被细分成很多个不同的市场:欧美市场、日本市场、韩国市场、拉美市场、东南亚市 场……每个市场都依靠语言、文化、渠道特色、市场机制等地域特点建立了壁垒,倘若没有找对法门,可能不仅没有找到宝藏,反而撞得头破血流。简单地以日本市场为例,虽然其ARPU值非常高,但日本市场的用户口味与其他国家有很大区别,盈利主要来 自卡牌游戏,而且日本用户对于美术画风、各种细节的要求非常高(例如相比其他亚洲市场,欧美风格的产品可能更受欢迎)。

另外,也不是所有的产品都适合走向海外。很多产品一开始就拥有中国市场的基因,离开这个环节与其他本土产品竞争,很可能水土不服。在近期我采访的几位开发者中,他们在谈到海外市场时纷纷谈到中国团队的技术优势,看来这一点是每个想要异国求生的团队必须具备的素质。