msec_faq.md

##FAQ

Q1:毫秒有没有demo和文档可以参考？

A: 文档参见这里，按照文档部署后，可以先看msec是什么，照着例子把航班查询的demo做一下（两台机器就够了），然后可以对照对应语言的msec服务开发详解深入的做一些例子（1.0版本需要3台机器，2.0及以上版本需要2台机器）。

Q2:毫秒支持哪些平台和开发语言

A： 毫秒的编译和运行都只支持linux；1.0版本支持的开发语言有c/c++/java/php，2.0版本增加python支持，其他语言我们会看需求情况酌情添加，大家也可以参考php的支持方式自行开发支持喜欢的语言。

Q3:毫秒为什么要用docker？有没有非docker的安装方式？

**A：**毫秒是一个有点复杂的系统，不提供非docker的安装方式。为了方便快速部署，毫秒团队提供docker镜像方式安装，但实际上只有毫秒的管理系统需要一台装有docker(建议version>=1.8)的机器，其他业务运营机器不需要运行docker。相信我们：我们自己是深受某些系统安装麻烦之痛之后决意要让毫秒安装足够简单的。

Q4:我按照安装文档部署了docker镜像，docker容器也跑起来了，但是monitor服务（或者mysql服务）没有启动是什么原因？

A： 可以attach到docker容器后，用msec_ps命令看一下关键服务的启动情况；容器里/etc/rc.d/rc.local这个文件有关键服务的安装路径和启动命令，可以研究一下。另外：

1、如果你对docker不熟悉，请快速看一下docker入门很简单

2、如果你对mysql zookeepr或者linux常用的操作不熟悉，请google或者系统学习一下，讨论组里其他同学一般没有精力来答疑这些比较基础的问题

3、如果你的docker容器的内存小于4G，启动会有问题

Q5:毫秒的一个最小部署集群需要多少机器 ？###

**A：**至少需要两台linux服务器：

其中一台需要安装docker(建议version>=1.8)，作为集群管理console；如果部署了1.0版本的毫秒，机器至少需要4G内存，如果部署了2.0及以上版本的毫秒，则至少需要2G内存。

另外一台作为业务运营机部署业务代码；1.0版本的毫秒不支持一台机器上部署多个业务模块，2.0及以上版本支持同机部署多个业务模块。

Q6:我按照文档指引，在业务运营机上部署agent，启动报错且失败了

**A：**请注意是否因为在web console页面里没有正确配置monitor和log服务的IP导致的，需要在异构服务那里自行增加一级服务RESERVED，然后在RESERVED下增加二级服务monitor和log，并配置它们的IP（也就是web console服务器的内网IP），并通过扩缩容操作刷写到负载均衡系统里。

详细请参考msec安装与部署

Q7:为什么要做毫秒开源？

**A：**QQ后台团队开发运营多年，经历了多次技术更新，积累了一些经验和教训，我们内部沉淀了一些文档和课件，也偶尔对外分享，但是觉得分享的东西到很好的落地实施其实还有较大的距离。

基于这些经验和教训可能对行业同仁有帮助，所以我们将内部用了3年多的已经大规模部署的SPP+微线程组件开源， 对加上我们常用的监控、路由管理、发布系统等系统进行剥离、简化，打包成一个完整的开发运营框架，就是毫秒服务引擎。

当然，技术的世界非常宽广，毫秒只是我们团队一家之言，是否对你有帮助、帮助有多大都不一定。

Q8:毫秒适合什么样的后台服务？支持对客户端push吗

**A：**被动应答的、偏实时在线的、窄带化的信令请求处理；暂时不支持对客户端push；

我们自己应用的时候，是有一层专门的接入层负责外网调度、push、频率控制等功能，模型不太一样，毫秒主要用在逻辑层处理业务流程；后续看需求情况可能开源专门负责外网接入和push的接入层模块。

Q9:为什么叫毫秒？

A： 取 Mass Service Engine in Cluster的首字母msec，刚好是毫秒的英文缩写；另外也表达小而美的寓意。

Q10:有没有教学视频？

参见这里

Q11:路由和容错是怎么实现的?

**A：**以一个场景为例：标准服务A调用服务B（可以是标准服务或者异构服务），用户在web console页面上配置B服务的IP信息，这些IP信息会写入zookeeper服务(console容器里跑着)。安装在A的服务器上的nlb agent会拉取到服务B的IP列表。

当需要调用B的业务接口的时候，A模块会使用nlb的api根据服务名字（B）获得一个IP，并发送请求到这个IP，然后将本次调用是否成功、时延多少毫秒等信息写入nlb agent的mmap内存里。

nlb agent会定期根据上述成功率、时延等信息，来动态决定服务B各个IP的权重，成功率高的IP就会被更多的请求。从而达到容错的目的。

如果服务A不是msec里的标准服务, 不能直接使用rpc的方式调用B，那么需要配套的使用getroutebyname和updateroute这两个库函数，后者就是将本次调用是否成功和时延等信息写回mmap的。

更详细的实现，需要阅读nlb的代码。

还有一个流派是希望状态中心主动收集B的各个IP的状态信息，然后推送给A。而msec的实现是完全根据本地的调用情况来决策的。

实际上我们团队这两个方案都用过，最后觉得基于本地的方式更简单、更鲁棒，实际运营中效果不比另外一个方案差。

基于本地信息来容错的方案，对web console上面的zookeeper等服务没有高的依赖，web console短时间故障不会直接影响业务请求。只需要及时备份镜像里的/msec目录即可。