创业公司的架子
设想一下,如果几个人搞创业,起初有少许的启动资金,该怎么样将产品原型落地?
答案基本是先以最小的成本,将产品跑起来,毕竟用户量起初也是非常小的。
此时可能没有复杂的负载均衡接入,没有服务器集群,但也没有大厂拥有的任何自建设施,看似架子简单,但假如没有开源世界的帮助,所有的事情不得不从零搞起来,刀耕火种、茹毛饮血,想想都头大。
起初的基本配置大概是这样:
即便如此简单,各个模块也需要依赖众多开源世界的帮助,比如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实现的一套相对简单的定时任务系统,根据库表配置多项定时任务实现整体业务的完整性。
破茧成蝶
随着公司更进一步的发展,此时面临着上市,技术层面也需要营造自己的影响力。
结合自身业务的高并发大流量的场景,以及长期的特性迭代与技术沉淀,大家对之前使用的开源技术有了更加深刻的理解,也在细节上有了独特的认识。更重要的是,此时人才济济,我们有能力有精力也有驱动力来重构这一套技术体系,形成更加完善的解决方案。
至此,诞生了更具稳定性更先进的技术框架,最终会回馈到开源社区,良性循环。
总结
前人栽树后人乘凉,乘凉后感谢前人的同时,希望大家能一起保护好这片林子。