个人项目架构的思考

sorcererxw /

这两天改造了几个自己个人项目。有的是把前后端给合并到 node.js 里面形成一个单体应用,统一管理;也有的是把本来外部的数据库改成应用内嵌的数据库。大的来说,我做的事情就是把本来分离的系统给合并起来。在微服务和前后端分离流行的当下,为什么要这么做?简单地说就是为了方便开发与维护。

之前自己也一直强调前后端分离和SOA架构,即使是在个人项目里面,因为这样可以保证整体项目的可扩展性,不至于牵一发而动全身。为了做到这样,我把前后端给拆分,把数据库给拆分,简单的服务拆成各个小服务独立部署,简简单单的项目也都给划分成最小粒度的模块。我不能说我做的是不对的,在足够复杂的系统当中这么做确实能够让团队更加有效地合作,保证服务的可用性。

但是,事实上,对于我的个人项目来说,这么做反而给我带来了很多不必要的麻烦,我不得不同时监控多个服务的状态,无论是部署和开发的时候都需要花更多的时间。因为分离解决了团队分工难题,但是整体的工作量其实是上升的,而对于个人开发来说,本身就没有分工难题。

我有几个小项目,就是简简单单地通过外部接口,抓取数据,存到自己的数据库当中,然后在前端显示。前后端的工作量合起来不足1000行代码。但是我将它前后端分离,数据库单独部署。其实是没有必要的,对于这种没有什么访问压力的应用,如果数据库只是作为一个缓存,其实完全是没有必要使用外部数据库,毕竟并不需要在意数据的持久化。同样的,就个人项目,如果前端只是后端数据基础的CRUD展示,也没有必要进行分离,当然,如果后端直接渲染前端带来了其他麻烦,还是应该分离。一个单体应用还可以消除服务间通信的网络延迟。

将整个系统进行“压缩”之后,我没有因为为项目未来的扩展性而感到伤脑筋,反而感到一身轻松。我可以一条命令就将整个项目打包成 docker 镜像,或者直接就在 AppEngine 上线,不必再为后续的维护头疼。未来的扩展等到真正需要的时候再说,在开发的初期前要不要过度设计架构。