如何设计一个大后台给所有业务提供后端服务？

[dream4ever]

我目前在传统企业做 Web 开发，但干活的人少，所以我其实是“全干工程师”，前后端项目的技术选型我有完全的自主权。

目前我负责的几项业务，都是完全的前后端分离，后端部分用的 Express + MongoDB 提供服务。业务代码写多了，就会发现有不少通用的部分，比如好几个网站都有账号+密码注册功能，不同的只是各网站需要提交哪些字段、各字段是否必需、字段格式要求等等。

所以我现在就在想，是否可以把这类普遍的需求通用化？比如说通过配置文件或者其他方式，来定义各个业务的用户注册功能有哪些字段，各字段是否必需，字段的格式要求等等之类的需求。不同网站的用户注册请求从前端发送过来之后，后端调用对应网站的配置文件进行检查，通过各项检查的，再调用同一个更底层的用户注册功能，将用户信息写入数据库。

这里只是以用户功能中的注册子功能举例，其他各项功能也希望实现同样的需求。对于这类偏实战的需求，有什么好的轮子值得借鉴？虽然也经常刷 GitHub，但在上面看到的各种后端框架，普遍都是 Express 、Koa 这种提供业务无关的功能的框架。而如何结合实际业务来开发各种通用的功能模块，满足上面所说的需求，可能是我查找资料的方向不对，目前还没找到这方面的资料。不过这种需求应该很普遍，可能很早就有人做出来了，只是我不知道而已，欢迎大家指点。

PS：技术栈不需要局限于 Node.js ，Java 、Go 也完全 OK 。

[dream4ever]

话说 V2EX 提供了“前端开发”这个节点，但是为什么没有“后端开发”这个节点 @_@ 小小地吐槽一下，哈哈。

[pushback]

这不就是微服务吗，做个中台，汇总下用户服务和其他通用服务就行了啊

[dream4ever]

@pushback 公司的业务目前运行在一台服务器上，之前也看过微服务相关的文章，感觉业务量没那么大，手底下的几块业务又是我一个人负责，引入微服务的话，可能会引入太多的复杂度。

也可能是我对微服务的了解还不够全面，欢迎指点。

[angryfish]

所有业务写在一个项目。别想太多

[lhx2008]

账号这一块看看是不是要打通，打通就抽出来做单点登录，不打通改的意义不大

[dream4ever]

@lhx2008 不同业务是使用各自的账号的，不需要打通。

[shew5689]

springboot Alibaba 解千愁 nacos(配置中心+服务发现)+getway(网关)+openfeign( http 调用)+各服务

[dream4ever]

@shew5689 这样的解决方案是否会太重？还是说熟悉了之后其实很省心，平时只需要写业务相关的逻辑代码就行？

[szuwl]

微服务不难，看几个文档就完事了

[letking]

可以考虑 mono repo 。所有项目放在同一个代码仓库，方便共享代码，部署还是各项目独立部署。

[loading]

微服务化，就是把没依赖关系的东西分开，然后前台 nginx 帮你把 url 分发就行，这样代码比较好掌控，也就是伸缩性更强。

[dream4ever]

@letking 预估了未来几年的业务发展，倒不至于用 mono repo，因为业务体量不会太大，主要就是希望把目前和未来业务中相同或相似的部分做重构，不变的部分和变化的部分相分离，做好架构层面的设计。

[loading]

《互联网创业核心技术:构建可伸缩的 web 应用》，这本书你可以看看，写得很好的。

[loading]

你这个问题不是具体语言解决的，是架构问题。

[dream4ever]

@loading 是的，就是想了解如何根据这个需求设计一个合理的架构。多谢推荐图书，这就去看看。

[letking]

@dream4ever mono repo 又不是非得业务体量大才能用吧，有什么“不至于”的呢？就算你俩项目，只要有能共用的代码逻辑也能用啊。

[charlie21]

Controller -> Service -> DAO 一杆子捅到底，这是 JAVA WEB 常见做法
https://www.v2ex.com/t/735661?p=1#r_9929398

[dream4ever]

@letking sorry，可能是我对 mono repo 没有实际的了解，所以想当然了，我去看一下相关的资料。

[MrTLJH]

我就是大后台通用，表用前缀区分业务模块，通用的表用 type 字段，公用业务逻辑代码中用全局变量。语言框架的无所谓，用自己觉得方便的，目前上万人使用没有问题

[rockyou12]

其实不一定是微服务来，也可以是通用的模块通用 sdk 方式引入。主要还是要考虑你们的业务形态是怎样，是全部都自己维护？还是会部署到客户机房？

微服务其实运维的压力不小的，没想清楚就搞很容易过度设计。