我们经历过浩浩大大的单体应用微服务化, 来应对互联网应用规模的极速扩大. 这种规模一方面是服务用户的规模普遍过亿, 另一方面是参与开发的人员普遍过千.

但面向服务的架构SOA 并不是银弹, SOA 一方面极大的减少了互相之间的耦合, 避免了沟通成本的指数增长; 另一方面实现了生产环境的隔离, 约束了问题的扩散.

从我最近几年在创业公司的体验来说, 在早期, 无脑的微服务化是对开发效率和资源的浪费.

MonoRepo

应该有不少同学听过 Google MonoRepo 的故事, 这应该是 monorepo 少有的正面案例, 建立在 Google 复杂而强大的基建上. 除此以外的 monorepo 案例大部分都出现在吐槽中, 比如这个 I work on a massive monolith that has about 800 contributors and its just as complex to add something as simple as a user’s birthday.

但 monorepo 在创业早期可能真的是一个更好的选择, 核心的论点在于两点:

  • 加快功能开发 一方面是照猫画虎总是比自己从零开始搭建一个项目要快的. 另一方面 monorepo 可以让我们直接的复用大量代码.

  • 强制协作带来的项目质量提高和知识传播 对, 相比独立的代码仓库和隔离的工作, monorepo 会促进开发之间更多的交流和讨论. 你可以选择对自己不参与的仓库视而不见, 但是如果大家修改的是同一个文件, 各扫门前雪就很难了.

这种交流确实有成本, 还可能有冲突. 但它会带来知识的传播和标准的提高.

有限度的拆分部署

一方面, 在创业公司很容易出现 QPS 近乎为 0 的应用, 但是我们依然需要为它分配 2 个 POD, 占用不少 CPU 和内存. 导致整个集群的实际使用率低的令人发指. 另一方面, 时代走到今天, 我们非常确定单体应用的可用性很差, 问题无法被隔离在一定范围之内.

所以我们应该选择有限度的拆分部署, 这要求一个前提条件. 框架或者基建可以为业务开发屏蔽调用细节, 即业务方并不需要感知某个调用是应用内的函数调用还是服务之间的 RPC 调用. 在这个基础上, 我们可以根据实际的流量和业务重要性灵活的调整部署.

使用并且大胆的使用云上数据库

时代的一个改变是云服务的快速发展, 阿里云提供的 RDS 可用性已经非常高了. 应该尽量使用云服务提供的 MySQL, 否则你就要花费大量的成本去构建未经考验的备份恢复机制.

同时大胆的使用云上数据库:

  • 一方面, 慢 SQL 打满 CPU/IO 这类问题的处理方案已经成熟;
  • 另一方面, 在一定范围内允许大表的出现(1亿行以上), 无需过早的考虑 sharding 之类的方案.