[TOC]
说明
本文基于 Meteor 1.3.3 编写
优点
业务优点
- 使用H5 Nodejs 和mongodb 能适应 LBS CMS IM（一部分功能），本身就是用于解决大数据问题的，用户瓶颈，目前测试出是
一个用户5MB 内存，1W用户一个服务 （64G 云服务器）
能直接生成客户端，包括 Android IOS，也可以直接嵌入微信
技术优点
- 搭建环境非常简单，可以轻松建立开发环境，文档还算齐全。
- 前后端语言统一，前后端完全整合，后端与前端完全可以共享代码，比如，定义在一个文件中的常量，函数，在后端可以调用，你要是喜欢，在浏览器上也可以调用。最大限度地共享代码。减少工作量。
- 可以快速迭代，缩短开发周期和成本。
- 代码以同步方式运行，尽量避免回调（其实回调这东西，你要是习惯了，真觉得没啥，有很多库可以使做好这个事，可能有些人从其他语言转到nodejs刚开始不太习惯）。
- 浏览器里模拟了一个mini Mongo,你可以直接在客户端查询数据，感觉就像在服务器上查询一样。
- 反应式编程，很多地方你只要更新数据了，更新数据之后的其他操作，不需要程序员做。比如刷新视图。
- 采用DDP协议，以后可以扩展到其他语言，实事上已经有社区版本的，但官方只有js。
各种三方原生实现的ddp协议客户端
缺点
业务缺点
生成的客户端为Web型，用户体验差，某些功能需要原生开发支持
浏览器用户第一次加载慢，内容很多，加载完成后为SPA（单页面应用），响应差 30ms左右，手机浏览器响应差 100ms~200ms
技术缺点
- 现有人员，需要学习 Javascript H5 mongodb less 等等
- 框架基本都使用全局变量
meteor自己这么做就算了，而且程序员也必须这么做，这是由javascript的实现机制决定的，这对小项目还行，但稍大一点的工程， 谁也不知道别人定义了什么全局变量，更要命的是框架自己还有很多全局变量，这些有可能是你不知道的，但也无从可查，然后就是巨大的灾难
比如框架自己带underscore库，用了全局变量’_‘, 如果有谁不知道这个是被underscore使用的，覆盖了，后果很严重，更要命的是，整个框架都是这种模式，当然所有的javascript项目都有这个问题。
在你使用之前，你必须清楚框架或你使用的第三方包中已经使用了哪些全局变量，哪些变量不能用。
如果你想使用一个变量名，如果这个变量名已经被某个包使用，你就只能换。
所以从这一点上来讲，这个尤其不适合多人协作，大型项目的开发。
- 不能手动控制文件的加载顺序
在普通的nodejs工程中，你可以通过reqiure来加载一个文件，但在meteor中这个是不可用的。程序员不能去决定这个，框架完全按自己的方式去加载文件，官方提供的方法是改文件名，改成字母序，或放到一个子目录中，因为meteor是按文件名字母序和子目录优先加载。
为了省去程序 require 的步骤，做了这样一种自动加载。我觉得不可取，也很不方便，比如我在一个项目中就遇到这样一个总是，想加载 bootstrap.js 和bootstrap-switch.js ，而bootstrap.js必须在后面这个文件之前加载，但实际情况是bootstrap-switch.js加载到前面去了，结果会报错
解决方法要么把bootstrap.js重命名为a-bootstrap.js要么把bootstrap.js放到子目录
- Session问题
meteor里的session只能在浏览器里使用，服务端是没有session这个东西的，这个感觉很不方便，有时候需要在服务器上保存一些状态，只能保存在数据库中，每次自己去查询。
区分游客用户
在浏览器第一次访问的时候，生成 一个随机字符串，然后每次传给服务器，服务器存下来，用来区分是哪个用户
- 内存问题
meteor应用的内存占用比一般应用是要大很多的，可能跟他实现的实时特性有关系，因为它要维护每个客户端的连接和数据状态，一是客户端订阅的数据状态发生变化，服务器会主动通知客户端这些变化，所以内存消耗高。
- 没有完整的测试解决方案
官方虽然提供了一些测试方案，但感觉都是轻描淡写，而且官方的解决方案还在探索中，不适合大型产品的完整测试。
- 性能问题
meteor为了做到实时，在服务器上做了大量计算比较操作，还占用了大量内存，每个浏览器都用websockt与服务器建立了一个长连接，所以性能并不是多好，这一点在你开发的时候不容易感觉出来，但稍有点用户访问你的网站，你将会立即感觉到。
人员配置要求
每个人必须接触 git/github
必须一个真全栈，对测试人员要求高
测试要求用例管理， Python/Javascript
组员内，懂 js H5 mongodb
展望
任何技术都不是完美的，meteor站在巨人肩膀上的，还有很大的成长空间，目前版本的meteor 非常适合全栈开发工程师，做创业小项目，绝对不要用于大型项目的开发，至少现在还不能。
未来
Meteor应用管理架构-Mantra
页面 https://kadirahq.github.io/mantra/
仓库位置 https://github.com/kadirahq/mantra
Mantra是什么
- 规范Meteor开发流程
- 让开发过程变得可以控制
注意：
- Mantra本身不是一个应用框架，所以不会提供网络啊，构建等内容，它仍然依赖Meteor
- Mantra本身没有模板，需要使用者自己去定制
- Mantra本身不提供代码生成器，所以你的团队仍然需要IDE和某些插件的帮助
Mantra中包含
- 有一个基于React的UI组件层
- 有一个在app中定义业务逻辑的地方,称为actions
- Mantra本身不提供状态管理，但是它允许你使用一系列的状态管理工具，包括Meteor/Tracker，Redux，Rx.js响应式，Promises等
- 通过创建容器（containers）来使状态（states）和动作（actions）集成到UI组件中去
- 允许你进行依赖注入
- 帮助你单元测试UI，动作和容器集成
- 目录结构、文件命名和其他的规范
