Accidental CTO

无论从哪个技术指标看，我们新的技术架构都表现非凡。系统运行流畅稳定且能够服务10万用户。以系统工程视角来说，这确实是赢得了一场架构升级之战。

问题已足够清晰。我们的图书馆只有一个通道，海量的读者洪流在仅有通道的中排起了长队，导致作家们无法及时完成新书的注册登记工作。解决方案是新开设一个专用通道。

作为创业公司，当用户数从几千达到10万级别的时候，业务重心会发生显著变化。早期主要关注的是冷启动获客以及确保刚上线的服务能正常工作。出现的问题也多半是显而易见的，比如服务器宕机，网站应用崩溃了。

前面讨论的理论已经很完备。我们制定了一个构建服务器集群的计划，还需要一个负载均衡服务来分配流量。现在该撸起袖子把这些理论变成现实了。 大

水平拓展的决策是我们创业路上一个重要的转折点。我们将从单服务器转向集群模式。但是如果没有能有效调动军队的指挥官和指令系统，那再大的集群也没用。

第1节： 崩溃的厨房 在创业旅程中解决第一次重大危机之后的一段时间通常比较暗流涌动，往往预示潜在的危险。 数据库分离之后，我们的系统运行良好，忙碌而有序。

如前所述，我们成功实施了数据库与应用服务器的分离。PostgreSQL数据库现在拥有专属的强大服务器，不再与应用代码逻辑挤在一起。这对于关系型数据库而言是一个经典的拓展升级。

完成上述数据库迁移后，我们赢得了过去数周内第一次喘息之机。 数据库分离获得了成功。网站现在运行地很稳定，响应也很快，不再需要依赖每隔几小时的服务器重启就能搞定当前常规的新用户请求。

迁移数据库的决定已经做出。接下来就要付诸行动了。此刻感觉就像是站在悬崖边，但不得不往下跳。现在的问题是能不能在跳下去之前弄个降落伞。

第1节 上线次日 Dukaan就这样稀里糊涂的上线了。周末过后，我们在几个小企业主的WhatsApp聊天群里分享了指向我们刚发布的MVP的网址链接。我们其实并不知道会发生什么。

理论部分的讨论随着我们技术栈的选型敲定可以暂告一段落。现在该花点时间去实作了。我们需要为代码在互联网运行找一个落脚点，也就是说我们需要一台服务器。

两天的时间不能浪费一分一秒。MVP已经定义了我们将要做的“事情”, 也就是我们的数字版滑板。现在还需要找到“如何”完成它的工具，我们有哪些选择呢？ 在软件行业，你选择的一系列工具被称作“技术栈”。

第1节 主意和滑板 每家创业公司都是解决某个问题而诞生。我们的公司（Dukkan）起步则源自一个粗糙的PDF文档以及全国（印度）因疫情封禁导致的混乱。

​​如果说服务器就像厨房, 那如何描述我们大厨（CPU）正在使用的菜谱（代码）呢? 在软件行业的术语里，我们称之为服务架构。我们采用的架构非常经典, 是那种几乎每一个初创公司早期都会采用的架构。 ​

让我们先把这场半夜3点的惊慌无措搁在一边。在我们解决问题之前，得先理解问题。所以问题来了：“服务器”到底是啥？ ​ 请暂时忽略过于技术的解释。忘记在冰冷机房闪烁的指示灯。

第一节: 服务器崩了 我的手机突然响了起来，但不是那种普通的来电铃声，而是一种类似尖叫的声音。 那声音伴随着一种特定的手机振动（通常被手机厂商用于提示最高等级的恐慌情绪）