这是一个创建于 1099 天前的主题，其中的信息可能已经有所发展或是发生改变。
其实我自个做产品已经经历了两个阶段，前两个阶段有什么坑有什么好处自己都基本明白。
现在算是第三个阶段。
又开始纠结了……
先说下我业余做东西的心路历程：
阶段一
我要上业界最前沿的技术！
然后就是用上了各种压根没啥人用的新框架，架构就是分布式微服务（细粒度拆分，觉得自己代码写的是真他吗优雅，可维护性可拓展性拉满了）、搞个前后端分离、然后缓存搜索消息各种中间件全部 balabala 怼上去……
结果是那个产品没运转起来，周期太长导致我踏马一个人维护不动开发不动了……
倒不是技术不行，其实我还是可以 cover 的，新技术新框架查查官方文档、debug 看下源码，都能解决。
就是坑太鸡儿多了，尤其是 WebFlex 和 SpringSecurityOAuth2 有几个坑我都要看源码看的很深才能解决，真实折腾。
服务又多，窗口 /屏幕切来切去麻烦的我要死。
产品 demo 都没出来，就先在“基础设施”这一块折腾了三个多月。
后面直接放弃。
反思：
《黑客与画家》说的是对的，圣母玛利亚式开发没有好结果。
大而全没什么卵用， 直接做个最小功能集上线然后慢慢加东西就挺好。
适合小团队 /单人的还就真是快速迭代这个搞法。
阶段二
吸收了阶段一的经验。
决定采用巨石架构，搞的就是单体服务，直接一个 SpringBoot 怼上去就完事了。
中间件选型就一个 Postgres 直接把 SQL 、NoSQL 、时序、图、搜索 balabala 全部 cover ，是真的完美。
然后把之前那个死掉的项目的尸体拿过来消化了一下，基础设施复制复制改改还能用。
然后就是一周上线，实际投入生产环境。
好家伙，这项目一做就是一年多，慢慢的也就开始有收益了。
反思：
巨石架构是真的好用，你哪有那么多用户、那么多功能、那么多人手来整微服务那套东西。
开发方便快速就不说了，部署也是简单的很。
说白了就算是一般公司那几十百把万用户甚至都没必要上微服务。作为个人开发者的体量就更不用谈了。
还有一个很关键的点就是：就算你最初版功能再怎么少也好，有没有上线 /有没有用户，对于一个独立开发者的心态而言真的是完全不一样的。
现在
现在想要开发一个新的东西……
那问题就来了，诸如 [用户系统] [认证鉴权] [主题 /文章 /帖子等 UGC 模块] [回复中心 /消息中心] [用户动态] [第三方服务对接] [图片存储 /处理] ……等等等等“基础服务”实际上是属于你无论开啥 APP 都可以用上、有机会用上的。
我要是新的产品也保持巨石架构，那就不得不全部一股脑复制过去。
但又由于业务肯定不同，要针对性修改也感觉怪麻烦的。
后期的话随着迭代的加深，我各个产品线的基础服务甚至都可能会变得不太一样，到时候同时维护多个产品估摸着也会有些消耗心智。
所以我又想着捡起微服务了…… 给自己做一套 SAAS 是不是挺不错的？
-
先用 RBAC 做一套统一的 Auth 服务。
-
然后把基础设施抽取出来，不进行更细粒度的拆分直接把常用的基础服务打包到一起。
-
然后考虑拆一个专门的对接服务用来和第三方打交道。
-
底层数据模型就类似多租户的模式，做 APP 隔离。
-
中间件准备在加一个，在 Postgres 外添加个 Redis ，够了。
那么在这几个服务的支持下， 我在开新的软件、新产品 就快速方便很多了。
至于多个服务用一套基础服务的性能问题，我是完全不考虑的。 现在我那个单体项目的 DB 配置也就 1c1g ，还天天 CPU 10%。
差不多就这样了……
不知道我的考虑是否正常，想法是否正确？
上面就权当抛砖引玉， 看看各位老哥有没有啥经验，还请多多指导我。
 |
1
libook 2021-12-15 14:48:14 +08:00  4
循序渐进的思路是对的，做原型就什么顺手用什么就好，项目隔一段时间重构一次是正常的，每段时期都会有新的需求局态，根据需求再确定是否要变更选型就好，新技术可以上手做做实验，验证是否符合当下的需求，不符合也没必要硬上，对于还在炒作期的技术还是谨慎些吧，玩玩可以。
微服务其实是拿管理维护成本来换开发运营成本，所以虽然开发运营会比较爽，但还需要考虑服务治理问题，使用服务治理中间件和混沌工程来解决各种微服务特有的问题。 公司里有个微服务拆分的评判标准，就是如果一个微服务尚不具备复用的需要，就不拆，但代码上确保随时可拆，项目服务可以以单服务运行，各个功能模块可以作为逻辑上的微服务工作，像微服务 API 之类的走微服务的实施标准，这样也可以享受一些微服务的好处，又不至于过早面临服务治理问题。 |
 |
2
xuanbg 2021-12-15 15:38:50 +08:00
一个巨石和相同功能的七八个微服务开发周期有区别？至少对我而言根本没区别。在软件开发上，真正能造成浪费的一般都是错误的功能设计。
|
 |
3
wujiezero 2021-12-15 17:14:44 +08:00
做微服务可以，个人项目不拆那么细就可以了，哪怕你微服务里只有一个工程，先一步一步来。
|
 |
4
rophie123 2021-12-15 17:21:31 +08:00
别想太多，我就是复制复制，无所谓了，最后一个没成
|
 |
5
zliea 2021-12-15 17:24:51 +08:00
如果一个人，可以考虑多个 module ，然后方便拆分。
|
 |
6
makelove 2021-12-15 18:36:08 +08:00
@xuanbg 除非你有别的项目可以共享服务，否则分很多还是有很大管理成本的，我就分了二个出去就觉得麻烦了（对个人开发者来说
|
|
7
xuanbg 2021-12-16 07:23:00 +08:00
@makelove 服务本来就应该是共享的呀，一些基础的功能做成微服务，只要在那里，就一直都可以用。具体你可以点头像看我的 github 。
|
 |
8
litchinn 2021-12-16 09:14:07 +08:00
认证中心推荐下 keycloak ，用起来还挺方便的，就是数据方面的集成前期要花点时间
|
 |
9
SmiteChow 2021-12-16 09:34:46 +08:00
微服务的提出本来就不是为了项目考虑，而是为了大规模协作，直白点就是大厂人多每个部门都要立山头。
|
 |
10
agagega 2021-12-16 14:12:58 +08:00 via iPhone
|
 |
11
ggbond2233 2021-12-16 18:04:19 +08:00
从 19 年开始.当时是想着一边用新技术,一边学习的想法,
第一版 A 应用 admin 管理后台 X 应用定时任务 N 应用业务数据 W 应用微信业务 引入 redis, mysql 后来维护起来要崩溃了.当时还是自建服务器.每次家里停电再重启 好多应用要恢复, 20 年改版 去除 redis ,部分应用上云,mysql 还在家里. 结果断断续续 解析不稳定,数据库网络不通,好多业务全跪 于是再 N 应用中去掉 mysql 引入 H2. 21 年继续改 买了云上 mysql ,数据库全部迁移,应用里 springboot S 应用安排, 删除 X 应用, 一个 @scheduled 搞定 A 管理后台 集成 W 微信业务.删除之前的 W 应用,但是 A 会有内存泄露.安排定时重启.也不去定位了 后面都准备废弃掉,迁移入 S 应用. 自己的业务就不要给自己找麻烦了. |
|
12
ggbond2233 2021-12-16 18:05:41 +08:00
诸如 [用户系统] [认证鉴权] [主题 /文章 /帖子等 UGC 模块] [回复中心 /消息中心] [用户动态] [第三方服务对接] [图片存储 /处理] ……等等等等“基础服务”实际上是属于你无论开啥 APP 都可以用上、有机会用上的。
关于这个基础我是建议 admin 管理后台引入一个开源的单独管理 ruoyi 之类的都有,业务系统单独自己开项目 |
 |
13
sorakylin OP @ggbond2233 用 ruoyi 的话是不是就是直接用 ruoyi 起一个服务， 我自己开新东西就直接去对接他暴露的 API 这样子？
|
|
14
ggbond2233 2021-12-17 09:11:14 +08:00
@sorakylin 是的,若依有很多版本,我用的是类似的 cms, 插入文章 都是通过 api,也可能在业务系统直接使用 ruoyi 同一数据库插入
|
Select Language