互联网技术和架构_H5之家 - 中国HTML5教程资源分享第一站

虽然用文本格式来通信比较昂贵，但是如今这方面的费用越来越便宜。应该在游戏这样数据量很大的应用中使用二进制数据进行通信，而在普通 WEB 应用中使用文本格式的数据来通信。在架构中应该尽量使用 JSON 而不是 XML 作为通信协议。

用 JSON 作为文本通信格式有很多好处：

JSON 就是 Javascript 中的一个对象，很容易把一个 JS 对象转换成 JSON 格式的数据

在JS 中进行对象和 JSON 的转换：

var myJSONText = JSON.stringify(myObject, replacer); var myObject = eval('(' + myJSONtext + ')');

在 jQuery中进行对象和 JSON 的转换：

var obj = jQuery.parseJSON('{"name":"John"}'); alert( obj.name === "John" );

用 JSON-RPC 替代 XML-RPC 通常会把数据减小到 30% 左右

JSON-RPC 请求的例子

Client: { "method": "echo", "params": ["blog.eood.cn", "Hello JSON-RPC"], "id": 1} Server: { "result": "Hello JSON-RPC", "error": null, "id": 1}

nodeJS 中对 JSON-RPC 做了支持

见 https://github.com/ericflo/node-jsonrpc

在 nodeJS 中创建 JSON-RPC 的服务端

var rpc = require('jsonrpc'); function add(first, second) { return first + second; } rpc.expose('add', add); rpc.listen(8000, 'localhost');

在 nodeJS 中创建 JSON-RPC 的客户端

var rpc = require('jsonrpc'); var sys = require('sys'); var client = rpc.getClient(8000, 'localhost'); client.call('add', [1, 2], function(result) { sys.puts('1 + 2 = ' + result); });

PHP 中也有支持 JSON-RPC 的类库

见 ?page=example&lang=en

关于 JSONP

JSONP 是跨域 AJAX 通信的方式

jQuery 做 JSONP 请求和普通 AJAX 请求几乎一致

$.ajax({ url: "http://blog.eood.cn/jsonp.json", dataType: 'jsonp', success: function(results){ ... } });

订阅这个博客：关注我的微博：关注我的推特：

互联网产品设计的主线和功能开关

Posted Sep.21, 2015 under 产品推广 by Bruce Dou

最近在做 Strace 。谈一下几点关于产品设计的感悟。

大型产品的架构和大型软件的架构思路非常相似。需要不断反复斟酌功能的取舍，并且保证有效功能能够不断扩张。从一种角度来说，需要保证产品的可扩展性。

避免推到重来

推到从来就类似于软件的重构，耗时耗力，而收益非常少。想想那些中途而废的创业公司和创业项目。假如能够不断给那些项目增加有价值的功能，积累到今天应该至少能给小部分人带来价值。

做到可扩张

要做到产品的可扩张，而不是不断推到重来。总结了下，需要注意几点：

选择好产品的主线

每个产品都有很多不同的侧面。从不同的侧面看会看到很多不同的价值取向和功能点。经常跟不同的人聊对互联网产品的看法。发现对同一个产品，不同的人看到的通常是不同的侧面。比如：你怎么看搜索引擎这个产品？大部分普通人的价值取向是获取问题的答案；营销人员的价值取向则是获取有价值客户；搜索引擎公司的价值取向则是通过广告盈利。这才是几个最容易想到的侧面而已。

人人都是产品经理？从人人都可以提出自己角度的产品需求这个角度，我是同意的。但是能够分析到或者设计管理产品的所有侧面，并且做到功能的取舍和平衡，这绝对不是非专业的人可以做好的。还可以从另一个角度证明不是每个用户可以做好产品：无论哪个产品，都有人在批判。

按照大部分公司做产品的先需求采集和后功能设计的流程，很容易陷入堆积功能、不断推倒从来的境地。所以需要在早期就制定好产品框架和架构。定好产品的主线。也可以叫做“切入点”。

1. 产品主线的特点：

1.1 简单

KISS 的方法论也可以用在这里。只有简单的东西才容易扩张。只有简单的东西才有更多的受众。只有简单东西才容易叠加价值。

1.2 不可变

定好产品主线后，最好不要再变换。其他功能完全围绕产品主线进行。有功能假如会削弱产品主线功能，则抛弃之。做产品的痛点不是没有功能可做，而是选择太多，迷失方向。现在很多创业公司都有很充足的资金和资源，问题不是产品功能不能做出来，而是能做的太多。所以坚定一个主线非常重要。

1.3 现实生活中在大规模使用

主线或者切入点最好是常见的功能，或者已经烂大街的功能或者价值取向。这样，你不会在一定阶段难以扩张用户群。当然有很多满足小部分人用户需求的利基产品，能够做得小而美也非常不错。

1.4 可以附加价值

这个主线的周边可以扩张和放大，有很多附属功能可以增加。滚雪球式的进行产品演变。

2. 持续增加有价值功能

2.1 测试论和功能的生命周期

某一项功能是否真的有用？某一个修改是否真正让产品走向好的方向？没人能够很好的做这样的预测。

2.2 数据导向和测量

相信很多产品经理已经不再靠拍脑袋来做产品决策了。多少都会依据一些数据，正所谓数据导向。但是方便的进行功能效果测试并不是那么简单，需要很多工具和基础设施的配合。而这些做产品决策的测量功能最好不要和业务代码进行耦合。功能的效果测量或者测量模式对于不同的公司或者产品又是非常相似的。这也是 Strace 想解决的一方面的问题，因为好的产品和功能才是做产品增长的基础。

2.3 功能开关

可能大部分创业公司或者互联网产品还没有太注重针对产品迭代或者测量相关的基础设施建设。这里，推荐做一个“功能开关”的基础设施。可以将非“主线”功能通过功能开关进行控制。功能开关可以灰度启用某些功能，也可以全量关闭或者打开某些功能。通过测量这些功能带来的目标收益而决定功能的取舍和是否继续细化迭代。功能开关也可以用在产品功能降级上，并且可以和产品线划分相融合。

2.4 功能 A/B 测试和灰度测试

有了功能开关的基础设施，既可以方便的在功能级别对功能进行 A/B 测试和优化。通过查看各项指标的变化做更好的数据化决策。

如果你对这些都很感兴趣，可以关注增长黑客工具箱： https://strace.co/neice (Strace 是一个关注产品和用户增长、推广测量的基础设施工具。)

Tags: 产品, 功能开关

亚马逊云平台的迁移过程

Posted Oct.12, 2014 under 架构研究 by Bruce Dou