🔥 热搜 🔥
上海习近平新疆鄂州父女瓜乌鲁木齐疫情H工口小学生赛高习明泽芊川一笑图包印尼排华
分类
社会娱乐国际人权科技经济其它
🔥 热搜 🔥
百度今日热点微信公众平台贴吧opggdnf私服百度贴吧知乎dnf公益服百度傻逼
分类
社会娱乐国际人权科技经济其它
查看原文
其他

Bytebase 0.1.0 开源版发布

BB仔 Bytebase 2022-05-27
收录于合集
#开源 7 个
#产品发布 19 个
#设计思考 4 个
经过半年多时间紧张的开发，2000多次的提交，Bytebase的开源0.1.0版本终于在今天和大家见面了。代码仓库在https://github.com/bytebase/bytebase，使用的是Apache 2.0协议。


Bytebase是什么

Bytebase是一款聚焦在Database schema change and version control的工具。它主打的是在应用研发过程中变更数据库数据结构(Schema)的这个场景，主要面向的人群是研发工程师和DBA。


数据库变更和代码变更一样，都是在开发应用时绕不开的场景。虽然数据库的变更没有代码变更那么频繁，但是却要危险的多。因为数据是有状态的，所以不像代码出问题后可以快速回滚，数据库的回滚通常要复杂的多。除了这两种变更类型外，网络配置变更也是通常能够造成大规模服务故障的，但网络配置通常也是无状态的，所以回滚恢复起来也比较快，所以说数据库变更其实是最有可能造成长时间大规模故障的操作，严重的话甚至可以让公司立刻倒闭。相信每一位经验丰富的DBA和研发工程师都有一段和数据库变更操作相关的有趣故事。而#删库跑路#的梗就来自于数据库变更。


既然这个操作那么重要，想必已经有不少工具在解决这个问题了吧。有是有，但是现实情况是，虽然数据库行业已经有40多年的历史，DevOps，Database CI甚至是Database-as-Code也都喊了好些年，但仍然没有出现一个业界标杆的工具能做好这块的事情。怎么样叫业界标杆呢，比如说代码托管，大家就能想到GitLab。又比如说服务监控，大家就能想到Prometheus。


为什么要做Bytebase


其实就是回答上面的问题:

我们希望把Bytebase做成在数据库Schema变更管理这块的业界标杆工具。

前面也说到这块的工具其实还是有不少的，大致分这么几类：

  1. 长期耕耘这块的工具产品，目前的业界标杆，比如Flyway，Liquibase。许多团队也都使用他们的开源版本，他们的优势是长期积累，已经经过了时间的考验，在schema change core这层很扎实。但相应的劣势则是因为都是10多年的老产品了，所使用的技术栈都比较老。比如Flyway, Liquibase都是基于Java的，像数据库变更通常会作为CI场景中的一步，这一步现在往往会放在单独的容器里操作，为了跑一下Flyway的一条命令，还要先下载个JVM，或者用带JVM的镜像。再比如说他们在Web端都比较弱，要么完全没有，要么是非常基础的功能，远远达不到应对现在协同研发，持续集成的场景。当然还有一个问题，就是他们是什么都支持，数据库商业的和开源的，格式XML, SQL的都支持，经年累月，积累了不少技术债。
  2. 团队内部自研，通常当研发团队规模到了50人左右时，就必须组建DBA团队, 再更具规模的公司DBA和研发的比例是1:150 ～ 1:400。为了提高DBA的接客能力，就不得不依赖工具，从最基本的SQL工单开始，往往一开始DBA们就会自己攒个工具，比如拿起熟练的Python + Django，再高级点的用AntD美化一下。这些工具往往是随着需求一点点搭起来的，先是工单，再来个巡检，加个监控，做个备份，接个审批流这样，最后就做成了经典的公司内部系统，就像这样:
  1. 有一些更有心的同学，会把公司内部做的工具开源出去，有几个其实在社区是蛮受欢迎的，小几千的GitHub Star。我也了解到国内也有体量不小的公司在用这样的开源产品，这个价值还是很大的，至少DBA们不用重复造轮子了，还是造他们不擅长的轮子。但是坦率来讲，这些开源方案的产品化程度仍然远远不够，是很难成为业界的标杆方案。


所以我们的结论还是市面上确实是没有太好的工具，但是这个需求都存在了那么久，而且又是一个刚性需求，许多人都做过，有些都做了10+年，既然都没有做好，凭什么你们就能做好呢？这确实是个好问题，我们当然也思考过，只能说一个猜想，因为DBA虽然也是属于R&D工种，但是需要的技能栈和一般的应用研发工程师是完全不一样的，不像GitLab就是做研发工程师的工具。而数据库又是在日常应用研发能接触的技术栈里离用户最远的技术组件，所以也就缺少产品化的土壤（反向的例子就是Figma，因为就是做界面设计交互的工具，产品化就做的很好）。和数据库类似的其实还有网络工具，大家有听说过业界标杆的带界面的网络配置管理工具么？


所幸的是，我们正好是研发工程师出身，做过数据库内核，还当过DBA，甚至还做过协同产品。当然这其中还是和数据库打交道的时间最多，自己经历过痛苦，看到周围的人也经历过痛苦，然后又看着其他工种的小伙伴们有了Prometheus，有了Figma，真是咬牙切齿呀。所以想想还是就来搞一下吧！


那回到一开始说的，我们是想把Bytebase做成一款业界标杆级别的工具，而标杆工具必备的就是产品化的能力。自然Bytebase从最初构建就是往着产品化的目标走的。

Bytebase是如何构建的


许多细节之后再单独开专题细说，先挑几个说说吧


业务建模

业务建模永远是软件里最核心的模块，而且一旦发布后，后续很难做大调整，是决定产品上限的最核心因素。即使是作为数据库研发领域的老司机，Bytebase在建模上其实也是折腾了很久。下图是当下v1版本的建模，也是整个Bytebase最精华的所在


但这其实是第三版的建模，每一次重新建模都是大规模的代码重构。具体设计细节暂且不表，先说一个例子，右上一大部分是关于Pipeline的建模，Bytebase是认真调研了所有主流Pipeline引擎的设计，然后设计了一个方案:


思考过程大家有兴趣可以去阅读https://github.com/bytebase/bytebase/tree/main/frontend/src/types/pipeline#readme


界面设计和交互


我们不是设计交互出身，更多也是后端背景，所以这块不是Bytebase的强项。但所幸的是作为工具类产品，面向的又是相对对于美观度不是那么苛求的后端研发工程师和DBA们，Bytebase也不需要做到像Figma, Notion这样级别的设计水准（当然有是最好，只是团队技能点确实不足)，Bytebase力求守住的底线是好用不丑。前面提到像Flyway, Liquibase有很扎实的内核，但缺失的很大一块其实就是一副好皮囊，就像赛车引擎装在了拖拉机上。我们给Bytebase画的架构图是长这样的:


虽然后端部分的组件很多，也很核心，但是上面特意画了一个大大的浏览器，其实就是Bytebase的界面Console，事实上，在整个研发过程中，在前端上花的时间是占到了2/3 ～ 3/4。而这其中最多的心思则放在了研发和DBA协同时最高频使用的Issue详情页。


Issue详情页



这里面的数字标示出的就是它的组件构成，我们再来看同一张图的另一种展示


框框标出的是所有会产生交互事件的区域，Issue作为信息的中枢，连接着和Issue相关的各种信息，所以我们在尽可能的地方都做了链接的跳转，这样可以让用户可以顺着自己的思路，一步步地探究下去，找到最终的答案。截图里也可以看到，这其中不少链接采用的字体颜色也都不尽相同，这也是做过一些思考，当然如果有更专业的设计师来参谋的话，效果还是会更好些。


页面URL中slug的设计


既然说到了链接，那我们就来说说URL里slug的设计


这个截图是点了Issue详情页上Stage进度条，然后又点击了第二条评论后的样子，整个slug是分为了4个部分:

  1. add-createdat-column-to-userpostcomment-table-for-dev-environment，这个是issue的名字
  2. 13008: 这个是issue的ID，其实是真正识别issue的关键
  1. ?stage=dev-1：这个是用url query parameter，来定位到具体的stage，一个issue上能包含不同的stage，不同的stage展示的内容也会不同。
  2. #activity14029: 这个是用anchor定位到具体的评论位置。


这样做的好处是什么呢，通常issue详情页的URL会出现在文档，聊天记录中，这样的一个slug用户其实不需要点开链接其实就提供了很多上下文，比如名字，stage。而当点击这个链接的话，也能定位到当初这条链接生成者确切的上下文位置。而Bytebase所有的页面都尽量做了类似的处理。这里ID的设计（13008）其实也是做了一番权衡的，Bytebase目前所有资源都是采用了自增ID而不是随机ID，这个会之后单独开一篇来写。

开发者体验


Bytebase选择开源首先是因为业务领域的关系，因为要去连用户的数据库，就必须要获取数据库密码的信息，而只有把所有的代码公开，才能让用户放心Bytebase里没有植入后门。当然既然选择了开源，Bytebase也希望能让大家很容易地把玩Bytebase，所以Bytebase在一开始就立下的一个设计目标就是可以:

0配置，一条命令行触发，10秒内完成启动。

Bytebase是怎么做到这些的呢:

  1. 后端选用Golang，Golang静态执行文件自包含，所以不需要像Java那样，还要先装一个JVM
  2. 利用Go 1.16之后引入的embedding功能把前端文件打包
  1. 采用了SQLite而不是一般会采用的MySQL, PostgreSQL（这个之后也会单独讲一篇）

所以最后达成的效果就是，二进制文件编译好之后，只要执行 ./bytebase 就能把整个前后端Bytebase都跑起来了，其实也用不了10秒，基本是1秒内启动完的。


花式Banner


用户成功启动后，还会看到console上打印出Bytebase的ASCII花式


首先这个是有从品牌宣传角度的考虑，更多地向用户传达Bytebase这个Logo。不过还有一个很重要的原因是让用户能快速识别Bytebase的启动状态。同样的如果Bytebase是正常关闭的话，也会打印出BYE。


那么大的Banner是为了让用户在可能如海的打印日志里，能够快速识别到Bytebase的启动和结束时刻。

让产品自己说话


洋气的说法叫做Product Led Growth (PLG)。Bytebase也是做了一些特别的工作，它能通过--demo和--readonly开启演示和只读模式，事实上demo.bytebase.com就是用主干的代码同时开启了这两个模式运行的。Bytebase作为一款专业级，有自己设计观点的软件，即使对于经常和数据库打交道的同学来说，上手门槛还是有的。演示模式的好处是已经准备好了一批样本数据，可以帮助用户登陆后，能直接跨过数据冷启动阶段，快速进入边用边学的状态。


而只读模式起初是为了demo.bytebase.com做的，因为我们想demo站始终有一份干净的数据，给每一个访客呈现我们最想呈现的demo状态，要做到这点就需要保证运行一个只读的版本，不能让前面的访客把数据搞乱了。同时我们因为保障了只读，就能在帮助手册docs.bytebase.com上直接引用demo.bytebase.com的页面（这里又和前面提到的页面锚点联系起来），提高帮助文档的信息质量。当然后续Bytebase还能利用只读模式开发出Maintenance window, deployment freeze这些企业级功能，也是后话了。


Bytebase可以做到多大呢


这个问题在和不少人的交流中也会提起。事实上有不少的同学，许多还是数据库领域的同行都觉得这并不是一个很大的命题，我们还被不止一个人"夸过" 大材小用😄。相反倒是不做数据库，但是是做开发工具领域的同行反而觉得这个方向很不错，碰到这些同学的时候，我们彼此会心一笑，有默契了。是不是也是因为做数据库的同学们一直觉得这个场景不大（尤其是相较于数据库引擎来说），所以没有去把这个方向的产品好好做出来的原因呢？当然Bytebase自己还是很相信这是一个足够大的场景，只是还没有出现一个好的工具去挖掘这个空间。


这是我们设想中现代产研链路上的工具生态链。从关系上来讲，Bytebase介于研发和部署之间，所处的位置和HashiCorp下的旗舰产品Terraform会比较接近，都会与诸如GitLab这样的VCS做集成，Terraform管的是IaaS层的部署，也就是所谓的Infrastructure-as-Code，而Bytebase做的则是数据库部署完后，在上面加上数据库结构的事情，也就是所谓的Database-as-Code。至于HashiCorp的估值就不说了，大家自己去查新闻吧。上图里画的都是国外的产品，因为Bytebase既然想成为业界的标杆产品，所以一开始瞄准的就是全球市场，所以也是和全球市场上的标杆产品做对比。而Bytebase的代码库里除了某人TODO的Github用户名拼音外，应该也是看不到任何一行中文的。


当然这个逻辑也有很多可以被合理挑战的地方，坦率地来说，TAM，估值呀，能不能做大呀这些并不是Bytebase最先关注的东西。一开始选择做Bytebase的原因，还是因为我们看到业界缺了这么一款工具，而我们又自信地觉得在整个业界我们是最能够做好这个工具的人。


所以本质上我们更笃定的是能把这个事情做到业界最好，而不是能把这个事情做大。

至于说能做到多大❓❓❓ HashiCorp的大，Atlassian的大，还是Salesforce的大，还是说too big to fail的大🤔


Tool not Platform (yet)


在临近发布，最后过一遍Bytebase代码的时候，又给Bytebase做了这样的一个修改 - Tool not Platform (yet)


Bytebase的第一步迈出来确实是很关键，但后面的路还很长，开源社区的运营，国外市场的推广，当前的技术选型以及建模是否有致命的设计缺陷，这些也都需要慢慢摸索，和经历时间的检验。所以当下还是扎扎实实地做好工具的事情，其实接下来打算安排的功能点已经排了好长的列表了，然后可能还会有各种bug报告在路上，毕竟也是10+万行的代码量了🤔


好了，如果阁下能坚持到这里，说明你对Bytebase还是有些兴趣的😉 。如果你又恰巧有GitHub账号的话，那就不妨再多花一分钟访问一下https://github.com/bytebase/bytebase，点击一下右上角的Star按钮😄。当然如果你正好也是一名DBA或者研发工程师，在寻找一款数据库schema变更管理工具的话，也希望你能去尝试一下Bytebase，也欢迎把反馈发给我们。


最后也再埋个彩蛋，几周后会发布Bytebase体系里的第二款产品：）

雄关漫道真如铁，而今迈步从头越 。

Bytebase 开源 v0.1.0 🚀🚀🚀

您可能也对以下帖子感兴趣

文章有问题？点此查看未经处理的缓存