如何评价映兔科技 CTO 陈辉的文章《谈谈创业公司的技术选型》？ 第1页

没看出槽点在哪。

里面大部分技术都已经十分成熟，像 Phabricator, Jenkins, Grafana，Git等。少部分是高速发展的方向中数一数二的方案像 Kubernetes，etcd 等。只有 gRPC 是偏新的东西，但不简见得没有各公司自己撸出来的东西成熟。

有争议的可能集中在选择 Go 语言、对造轮子的态度和弹性架构的时机上。

选 Go 可能确实相对不好招人。但映兔这类产品是纯 App，业务并不复杂，并不需要庞大的团队，这是其一；其二是 Go 学习并不复杂，从其他语言转成本并不高，只要初始团队不是 Go 的二把刀，能够把握住新人学习方向，人才就不会成为短板。

对于造轮子的态度可以看出，作者其实比大多数质疑者经验丰富。作者的观点是，创业者不能把所有稍稍复杂的东西都交给第三方，而要随时有当第三方达不到要求是自己补位的觉悟。以个人经验，很多第三方服务其实技术并不复杂，品质也参差不齐，潜在的故障造成的损失、问题定位周期和反复沟通成本，不一定有自己造轮子实现更快捷，可靠。

Kubernetes 和 SkyDNS 的选择，以及混合云的架构。说明这个产品在早期就考虑的弹性扩容。在一些面向蓝海的创业产品中，可能弹性扩容并不是一开始需要考虑的问题，因为流量增长缓慢，有一定的手工扩容空间。但如果考虑直播类产品的特点——靠热点事件实现爆发式增长，市场竞争激烈，这意味着要产品有能力承受一波巨大的突发流量，才有机会谈后面的发展——就不难理解为什么要在早期考虑弹性和混合云的架构了。因此，映兔的选择不像其他人说的「照抄 Google」，「不顾产品上高大上的架构」，恰恰是符合这个方向市场大环境的。

感觉都是一些很好的技术选择啊，技术都算是比较成熟的技术了，而且很多方面都是纯粹的工程考虑。架构方面充分考虑了风险，对持续集成，配置部署，弹性扩容都做了相应的准备。

说这样成本太高的人，你们没有考虑过风险成本吧，也没有考虑一个好的架构对业务支持的重要性吧。我觉得这样的决策在刚刚开始搭系统的时候会提高一定的成本，但是带来的好处也是非常多的。

唯一有点质疑的是刚刚开始就使用微服务可能有点过分了。。。。其实感觉没有太大的必要，完全可以先从比较集中式的大架构开始快速搭系统然后快速上线，通过对集中式架构里做编程规范的模块化，后面再慢慢把负载高的部分抽出来做微服务，这样过渡可能会更平滑一些，因为在刚开始的时候业务流程可能并不是非常清晰，微服务的设计可能并不能跟需求完全匹配。

不过这种选择可能也跟对编程语言的选择有关联，因为Go语言的生态还是有点薄弱，没有比较完整成熟的技术框架可以快速重用上线。为了使用Go语言的工程优势而牺牲一部分的生态优势，到底是好是坏就见仁见智了。

但是这种技术选择其实对广大创业人员的借鉴意义还是有限的，关键是这里对架构师的要求比较高，对核心技术人员的要求太高了，普通创业团队在刚开始吸引不到高水准的技术人员。有能力驾驭这种程度的架构和技术的，你说一个A轮之前的创业公司用多少代价才能吸引过来呢？对创业公司来说可能还是先撑到融资拿到钱了之后再考虑请人来重架构现实一点吧。

对高技术水平的创业公司，天使轮之前就已经有核心架构师来说，还是蛮有借鉴意义的。