数据库连接从15000个到100个以下

新员工讲述的故事是DigitalOcean迄今为止最大规模的技术重建。全公司上下为其奋斗持续了多年，从中也学到不少。笔者希望这个故事将对处在棘手的技术债务难题的其他开发人员有所帮助。

一切从哪里开始

从一开始，DigitalOcean就痴迷于简洁。这是其核心价值观之一：力求简单而优雅的解决方案。这不仅适用于我们的产品，也适用于我们的技术决策。在最初的系统设计中，这一点再明显不过了。

像GitHub、Shopify和Airbnb一样，DigitalOcean在2011年开始作为Rails应用程序。Rails应用程序(内部称为Cloud)管理UI和公共API中的所有用户交互。帮助Rails的是两个Perl服务：Scheduler和DOBE(DigitalOcean后端)。

Scheduler计划并分配Droplet给管理程序，而DOBE负责创建实际的Droplet虚拟机。当Cloud和Scheduler作为独立服务运行时，DOBE在机队的每台服务器上运行。

Cloud、Scheduler和DOBE都不能直接交流。他们通过MySQL数据库进行通信。这个数据库有两个作用：存储数据和安排通信。这三个服务都使用一个数据库表作为消息队列来传递信息。

每当用户创建一个新的Droplet时，Cloud就会向队列中插入一个新的事件记录。Scheduler每秒连续调查数据库以查找新的Droplet事件，并计划在可用的管理程序上创建这些事件。

最后，每个DOBE事件将等待新的计划Droplet被创建并完成任务。为了使这些服务器可以检测到所有新改动，它们都需要调查数据库以查找表中的新记录。增长的用户群。

四年来，数据库消息队列构成了DigitalOcean技术栈的主干。在此期间，我们采用了一种微服务体系结构，用gRPC替换了HTTPS作为内部通信量，用Golang代替Perl作为后端服务。然而，所有的路仍然通向那个MySQL数据库。

重要的是，不能仅仅因为某些东西是陈旧的，就认为它就是不正常的，应该被取代的。Bloomberg和IBM拥有用Fortran和COBOL编写的遗留服务，它们所产生的收入比整个公司多得多。另一方面，每个系统都有一个比例限制。我们需要面对。

从2012年到2016年，DigitalOcean的用户流量增长超过10000%。我们在产品目录中增加了更多的产品，在基础设施中增加了更多的服务。这增加了数据库消息队列上事件的进入量。

（编辑：开发网_开封站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!