创业公司的架子

设想一下，如果几个人搞创业，起初有少许的启动资金，该怎么样将产品原型落地？

答案基本是先以最小的成本，将产品跑起来，毕竟用户量起初也是非常小的。

此时可能没有复杂的负载均衡接入，没有服务器集群，但也没有大厂拥有的任何自建设施，看似架子简单，但假如没有开源世界的帮助，所有的事情不得不从零搞起来，刀耕火种、茹毛饮血，想想都头大。

起初的基本配置大概是这样：

即便如此简单，各个模块也需要依赖众多开源世界的帮助，比如APP模块需要引入各个端的开发框架、通讯框架等甚至跨端框架，逻辑服务需要引入服务框架、访问存储的驱动层框架等，存储更是需要完全引入开源的MySQL等。

更何况，上述配置属于demo阶段，演示给投资人看看还行，如果产品上线运营，至少需要满足下面的配置：

任何一个模块的从零开发，都会耗费巨大，而创业公司更是希望就耗费集中在自身的产品创意的落地上，好钢用在刀刃上。

这里要感谢开源社区所有无私奉献的贡献者，以及为大家提供开源社区平台的Linus，向大家致敬。

通过github，使得创业公司可以借助相关的开源系统和框架顺利搭建公司框架，并专注在自己的业务核心上。

高可用架构

随着业务的发展，公司往往会面临用户的爆发式增长，生产系统故障频频。公司层面下重手处罚，责令上线需选择在业务低峰期进行，一线同学战战兢兢如履薄冰四处救火疲于奔命。究其根本原因在于基础设施、系统架构需要升级。

这是一项庞大的工程，这里只针生产系统的高可用架构展开。

计算机系统服务对外提供服务集中在网络、计算、存储三个层面，所谓的服务器千万网卡、万兆网卡指的就是网络层面单台服务能达到的吞吐上限，所谓的8核、16核CPU指的就是服务器的计算能力，所谓的服务器dd命令里的200M/s指的是存储维度磁盘的读写能力上限。

当QPS（每秒的请求量）达到一定量时，系统的瓶颈可能出现在三个层面的任何一处，好消息是设计良好的架构一般通过水平扩容（即额外增加些服务器）就可以解决网络、计算的瓶颈问题。然而由于存储的中心化体系，使得最后的系统瓶颈往往都出现在存储层面。

通过将生产服务设计成无状态的、幂等的，或者再往上一层将一批服务打包成功能模块无状态、幂等的，就可以实现业务水平扩展的能力，业界叫法不一，有的说是set化、有的说是单元化，总之意思差不多。

存储层面的高可用相对困难一些，因为存储涉及到读和写，涉及到数据一致性，有些金融场景要求更为严格。对此，近期国内的互联网巨头腾讯、阿里分别开源了PhxSQL和OceanBase，非常方便。

如果觉得PhxSQL和OceanBase类产品比较重，难以切入掌控，比如要针对自身业务特点定制一些特性，则需要更轻量更灵活的方案。

MySQL主从同步原理：

阿里有个有意思的开源方案是otter + canal，其中canal伪装成Slave接收来自所属主库的Binary log，otter做数据的逻辑处理，从而实现数据的单双向同步。

整体方案单向数据流原理图：

可视化界面大致如下：

如何做定时任务

做完存储层的高可用，建立多数据中心，接下来需要定时检测多中心的数据一致性。对于熟悉Linux的同学可能首先想到crontab，然而crontab存在局限性，比如单点问题、执行粒度问题等。

github里有很多开源的定时任务系统，如Java语言实现的quartz、Go语言的gocron等，当时我们选用quartz实现的一套相对简单的定时任务系统，根据库表配置多项定时任务实现整体业务的完整性。

破茧成蝶

随着公司更进一步的发展，此时面临着上市，技术层面也需要营造自己的影响力。

结合自身业务的高并发大流量的场景，以及长期的特性迭代与技术沉淀，大家对之前使用的开源技术有了更加深刻的理解，也在细节上有了独特的认识。更重要的是，此时人才济济，我们有能力有精力也有驱动力来重构这一套技术体系，形成更加完善的解决方案。

至此，诞生了更具稳定性更先进的技术框架，最终会回馈到开源社区，良性循环。

总结

前人栽树后人乘凉，乘凉后感谢前人的同时，希望大家能一起保护好这片林子。