关于 替代：我们的 darwin 项目用 go 实现了一个 iOS/Android 的预发环境的集成测试服务并和 jenkins/fastlane 无缝对接，只要 github 有推送就会自动重新打包，上传到 darwin 并在 bearychat 通知大家下载。
我们最开始用的 leancloud 的 IM 功能，发现非常不稳定经常丢失消息，后来用我们自己写的 go IM 服务器 + iOS/Android SDK 替换了。之后再也没有出现大的问题，而且因为所有的消息传输环节对我们都是透明的，相比于市场上其他的 IM 服务，这允许我们在消息传输过程中做各种融合和分析。事实上，基于人工智能的 IM 是我们规划的一部分，这部分只能自己完全掌握。
回复 ( 10 )
没看出槽点在哪。
里面大部分技术都已经十分成熟，像 Phabricator, Jenkins, Grafana，Git等。少部分是高速发展的方向中数一数二的方案像 Kubernetes，etcd 等。只有 gRPC 是偏新的东西，但不简见得没有各公司自己撸出来的东西成熟。
有争议的可能集中在选择 Go 语言、对造轮子的态度和弹性架构的时机上。
选 Go 可能确实相对不好招人。但映兔这类产品是纯 App，业务并不复杂，并不需要庞大的团队，这是其一；其二是 Go 学习并不复杂，从其他语言转成本并不高，只要初始团队不是 Go 的二把刀，能够把握住新人学习方向，人才就不会成为短板。
对于造轮子的态度可以看出，作者其实比大多数质疑者经验丰富。作者的观点是，创业者不能把所有稍稍复杂的东西都交给第三方，而要随时有当第三方达不到要求是自己补位的觉悟。以个人经验，很多第三方服务其实技术并不复杂，品质也参差不齐，潜在的故障造成的损失、问题定位周期和反复沟通成本，不一定有自己造轮子实现更快捷，可靠。
Kubernetes 和 SkyDNS 的选择，以及混合云的架构。说明这个产品在早期就考虑的弹性扩容。在一些面向蓝海的创业产品中，可能弹性扩容并不是一开始需要考虑的问题，因为流量增长缓慢，有一定的手工扩容空间。但如果考虑直播类产品的特点——靠热点事件实现爆发式增长，市场竞争激烈，这意味着要产品有能力承受一波巨大的突发流量，才有机会谈后面的发展——就不难理解为什么要在早期考虑弹性和混合云的架构了。因此，映兔的选择不像其他人说的「照抄 Google」，「不顾产品上高大上的架构」，恰恰是符合这个方向市场大环境的。
文章很好能从中学到不少。就是标题太大了，我觉得如果要符合这个标题，应该要把各种技术选型方案的人工成本，运营成本，时间成本计算一下，创业公司经常不是缺人就是缺钱或缺时间，技术选型就变成不能只往高处看，得评估性价比。刚创业的技术人员最容易在这方面吃亏，个人技术能力越强的越容易钻进技术里出不来。所以标题这样定，但文章只讲高新技术应用，容易误导创业新人。建议分享一些具体的技术选型和公司经营方面的整体思考和经验。
每个 exGoogler 出来创业都会先把 Google 那套 infra 和开发环境山寨一遍，都是这风格。现在开源出来的东西多了山寨成本更低了。
这种风格没有好与不好，脱离产品业务和团队组成谈技术架构没什么意义。
感谢大家对我们的的关注，回答一下大家的疑问
1、关于两周“重写” ES
严格来说不是重写，我们也没有打算实现 ES 所有的功能，而是要实现比 ES 更好的（我们需要的）功能。
我们基于 wukong 搜索引擎做的分布式搜索系统，wukong 是我之前写的一个搜索核心库：GitHub – huichen/wukong: 高度可定制的全文搜索引擎
这个系统从性能和易用性上完全不输于 elasticsearch，而且无缝融合进了我们的 kubernetes 分布式体系；另外，因为每一行代码都是我们自己写的，所以可扩展性极高。
搜索引擎并没有想象那么难写。
2、两周重写 ，leancloud
相比搜索引擎，这些都是小儿科了。
关于 替代：我们的 darwin 项目用 go 实现了一个 iOS/Android 的预发环境的集成测试服务并和 jenkins/fastlane 无缝对接，只要 github 有推送就会自动重新打包，上传到 darwin 并在 bearychat 通知大家下载。
我们最开始用的 leancloud 的 IM 功能，发现非常不稳定经常丢失消息，后来用我们自己写的 go IM 服务器 + iOS/Android SDK 替换了。之后再也没有出现大的问题，而且因为所有的消息传输环节对我们都是透明的，相比于市场上其他的 IM 服务，这允许我们在消息传输过程中做各种融合和分析。事实上，基于人工智能的 IM 是我们规划的一部分，这部分只能自己完全掌握。
3、关于造轮子
开始的时候我们是被迫自己造轮子，后来体会到造轮子的好处，发现造轮子才是最省时间的。
相比于花无用功琢磨怎么更有效对接一个看不到源码的服务，或是提一些几个星期之后才能解决的工单，我们发现自己重写对长期来说更节省人力维护成本，这有点儿类似“写个脚本”的意思，写个脚本短期来看是浪费时间的，但长期效率更高。同时大家花了两个星期重写了一个关键服务后，发现其实收费的服务还不如我们写的，极大增强了自信，也锻炼了团队能力。
但我不是鼓励所有轮子都自己造，比如数据库和消息队列，因为他们还没出过什么问题。
4、选择什么编程语言
这个基本和公司刚刚建立时的技术 leader 有很大关系，有一个笑话我觉得很中肯：
“如何在你的公司推广 XXX 语言：首先，成为你公司的 CTO；然后行政命令让所有人用 XXX”
从我用过的语言来看，Go 是我现在“如果要写一个项目那一定要这个语言吧”的选择，而且在我们的创业团队环境经受了考验，如果你一样也是一个团队的 leader，那么非常推荐你了解一下 Go。
无意挑起编程语言的圣战，就写这些吧。
5、“除了那种门槛特别高的start up，不都是游击队写第一版，做大了砸钱找专家.”
用外包的心态建技术团队，只能得到外包的产品质量。作为一个有追求的技术人，不幸进到这种公司，赶紧闪人吧。
6、“精英化小团队技术选型确实能更多尝试新技术，但是团队快速发展时技术选型太过小众，如何快速招到合适的人加入团队快速上手工作会成为一个头痛问题”
创业团队如何招人确实是个大问题，我有时间专门开一篇讨论这个问题。
我想说的是，不应该以静态的眼光看人才，你招到一个人不是让他只会用他以前习惯用的技术就可以了，相反要特别留心哪些只会选择大众技术的工程师，这些人的能力已经捆绑在了一类工具上，对团队长期的发展是不利的。
我们在《谈谈创业公司的技术选型》文中选择的多数技术并不特别小众，有些在创业圈已经非常流行，而且这些技术栈的设计多数很自然，有一定学习能力的工程师可以很快上手。
另外，从动态的人才成长的角度，好的团队往往是自我驱动能力强的团队，而使用新技术对这种能力是非常好的锻炼。要看到对人才长期的培养，而不只是仅限满足于眼下的业务需求。
相比很多国内互联网公司的 KPI 考核体系，我们使用 OKR 做项目管理，有时间开文章谈谈。
7、“日志用fluentd抽出来放到哪里索引了？grafana中展示的时间序列是存放在influxdb吗？”
我们的数据分析有两类，离线和在线。
离线数据主要是fluentd从log中提取出来后直接发送到阿里云的 ODPS，然后写定时调度生成表格分析。另外，数据库数据也通过 datax 发到 ODPS，可以和 log joining 处理。
在线数据走 /metrics 然后 prometheus 爬取，grafana 中展示分析，没走 influxdb。
我们这套离线数据体系适合每日报表或者即席查询，在线数据体系适合服务报警、调试等日常任务。
技术选型，要适合业务。
绝大部分公司的规模根本达不到Google的百分之一甚至万分之一，照着Google选型就是死路一条
选语言，市场前10，剩下的小众语言，自己玩可以，不要轻易上公司业务
首选Java，招人容易，用好Spring，轻易不造轮子，绝对稳定支撑业务到C轮
创业是为了挣钱，不是秀技术
java缺乏原生的线程支持？这显然是错的。在语言级别上，java从最朴素的thread到高级的concurrent package，我怀疑没有哪种语言能做的更好。
有点本末倒置的感觉，优秀的轮子都是在实践中脱颖而出的，而这篇文章中明显更看中轮子，忽略了真正的业务。互联网产品唯快不破，用轮子也是为了快速迭代，但不要把劲儿用错了地方。有些产品完全自己开发已经够用且效率最高，就没必要非得去迁就着轮子为了用而用。
语言、技术、库、框架都是一样的道理，研发前期捡自己最熟悉的、最高效的用就行了。后期为了提升产品性能和体验再考虑优化的事。技术只是服务于产品，整个团队的重心如果都放在技术细节上了，尤其对于创业公司，后果可想而知。
P(tu)一下S(cao)，「以 Google 的技术标准要求团队，鼓励使用新技术、鼓励重新造轮子」，你们投资人真是善人，真是不差钱，还缺人吗？
CTO也会站队
Java缺乏原生的多线程支持？两周写一个es？
好吧，或许两周可以写一个es，但Java缺乏原生线程却是错的。
从中或许可以得出一个结论：有些cto在选型的时候，其实对某些技术的判断是错误的，尽管他看上去言之确凿，目光锐利。。。
谢邀
－－－－－－－－
抱歉，现在创业的鸡汤太多，作秀的也太多，真正的创业者在成功前基本会保持低调