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

資深大佬 : dream4ever 6

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

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

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

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

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

大佬有話說 (39)

主資深大佬 : 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 方式引入。主要还是要考虑你们的业务形态是怎样，是全部都自己维护？还是会部署到客户机房？

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

提醒下，小业务别瞎捷豹折腾微服务。
主資深大佬 : dream4ever

@rockyou12 我们是部署到自己的阿里云服务器，服务器的运维也是我来负责的。
資深大佬 : xuanbg

这不是中台的初衷吗？把分散的、重复、通用的能力抽象出来，重新组织成各种中台。
資深大佬 : opengps

你要的这个功能，就是阿里正在提倡的大中台思路
資深大佬 : johnsona

用微服务就等着加班吧
資深大佬 : johnsona

写一个包不就好了，搞好面向对象，用继承，公共部分父类、自己实现子类，可以看看 django 的做法，内置用户模块，扩展的话一对一表扩展，authentication，覆写 auth 函数
資深大佬 : janxin

super graph
資深大佬 : sujin190

然后配置文件越来越复杂，就变成了一门新语言，这不就是 php 的发展过程么，所以别想太多了，功能复制性和编码简洁性不可兼得，啥事不干就能支持各种业务的事情就是意淫
主資深大佬 : dream4ever

@sujin190 哈哈，“啥事不干”不至于，主要是想把那些变化的部分和稳定的部分分离开来，主要还是架构设计的能力。
資深大佬 : taowen

把样板代码提取成代码生成器，用 JSON 文件配置给代码生成器做参数。如果参数太多了，就果断回退回纯手写。不要试图写过分通用的生成器，在你有限的几个项目里能够复用得到收益就好了。
資深大佬 : sujin190

@dream4ever #29 如果想这样的话，良好的微服务抽象是最好的，想要啥部署啥就是了，就算想着分支定制维护成本也不高，不行就取其次就是框架封装和模块封装，通过配置文件这种真的是极其不靠谱，现实就是有可能所有需求百分之九十九都是相同的，但是就那个百分之一不同就有可能取消全部重做，配置文件啥的在这种事情上的处理能力极其弱
資深大佬 : felixin

@janxin 这个看起来挺不错的，有什么坑吗，准备下个项目试试
資深大佬 : lishen226

多个项目有通用功能？用户注册？复制粘贴不就行了？还用搞这么麻烦？
你说的应该是不同项目的需求都是相似的增删改查吧，这样的可以做成动态配置的，前提是项目需求都比较简单，数据量小。我自己造过类似的轮子，很简单，一个业务表，一个配置表，业务表预留好足够多的字段，然后再配置表里根据不同的业务配置不同的字段信息。
資深大佬 : xuanbg

@johnsona 我司上了微服务后就基本不加班了。。。写几行 crud 的八股代码，至于要加班么
資深大佬 : janxin

@xuanbg 那贵司之前为什么加班的…
資深大佬 : xuanbg

@janxin 屎山代码，到处都是耦合的逻辑，改一个 bug 会产生 n 个 bug……
主資深大佬 : dream4ever

@sujin190 开发维护完全都是我一个人，而且前后端都要做，感觉微服务对目前的我来说有些重，我先做好封装吧，多谢指点 ^_^
資深大佬 : night98

可以参考下很多大厂的统一身份认证服务，就是你接入他们的 sdk 之后，账户体系和权限都在他们那边定义好就能直接用了，你如果想这样设计整个系统的花，可以参考他们的设计方式。各个应用以接入的形式加入系统
資深大佬 : charlie21

请问你说的前后端分离是哪种前后端分离？
参考 http://www.woshipm.com/pmd/3342034.html
前后端分离是指前端可以直接调用 WEB API 完成网站功能么？那么作为从零开发的网站，应该先完成前端部分 or 先完成后端（ WEB API ）部分，还是按照功能比如功能 1 的前端+后端，再完成功能 2 的前端+后端