V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
sorakylin
V2EX  ›  程序员

单人开发产品,你们觉得是否应该上微服务? 先说下我个人的独立开发历程

  •  
  •   sorakylin · 156 天前 · 2060 次点击
    这是一个创建于 156 天前的主题,其中的信息可能已经有所发展或是发生改变。

    其实我自个做产品已经经历了两个阶段,前两个阶段有什么坑有什么好处自己都基本明白。

    现在算是第三个阶段。

    又开始纠结了……


    先说下我业余做东西的心路历程:

    阶段一

    我要上业界最前沿的技术!

    然后就是用上了各种压根没啥人用的新框架,架构就是分布式微服务(细粒度拆分,觉得自己代码写的是真他吗优雅,可维护性可拓展性拉满了)、搞个前后端分离、然后缓存搜索消息各种中间件全部 balabala 怼上去……


    结果是那个产品没运转起来,周期太长导致我踏马一个人维护不动开发不动了……

    倒不是技术不行,其实我还是可以 cover 的,新技术新框架查查官方文档、debug 看下源码,都能解决。

    就是坑太鸡儿多了,尤其是 WebFlex 和 SpringSecurityOAuth2 有几个坑我都要看源码看的很深才能解决,真实折腾。

    服务又多,窗口 /屏幕切来切去麻烦的我要死。

    产品 demo 都没出来,就先在“基础设施”这一块折腾了三个多月。

    后面直接放弃。


    反思:

    《黑客与画家》说的是对的,圣母玛利亚式开发没有好结果。

    大而全没什么卵用, 直接做个最小功能集上线然后慢慢加东西就挺好。

    适合小团队 /单人的还就真是快速迭代这个搞法。


    阶段二

    吸收了阶段一的经验。

    决定采用巨石架构,搞的就是单体服务,直接一个 SpringBoot 怼上去就完事了。

    中间件选型就一个 Postgres 直接把 SQL 、NoSQL 、时序、图、搜索 balabala 全部 cover ,是真的完美。

    然后把之前那个死掉的项目的尸体拿过来消化了一下,基础设施复制复制改改还能用。

    然后就是一周上线,实际投入生产环境。

    好家伙,这项目一做就是一年多,慢慢的也就开始有收益了。


    反思:

    巨石架构是真的好用,你哪有那么多用户、那么多功能、那么多人手来整微服务那套东西。

    开发方便快速就不说了,部署也是简单的很。

    说白了就算是一般公司那几十百把万用户甚至都没必要上微服务。作为个人开发者的体量就更不用谈了。

    还有一个很关键的点就是:就算你最初版功能再怎么少也好,有没有上线 /有没有用户,对于一个独立开发者的心态而言真的是完全不一样的。


    现在

    现在想要开发一个新的东西……

    那问题就来了,诸如 [用户系统] [认证鉴权] [主题 /文章 /帖子等 UGC 模块] [回复中心 /消息中心] [用户动态] [第三方服务对接] [图片存储 /处理] ……等等等等“基础服务”实际上是属于你无论开啥 APP 都可以用上、有机会用上的。

    我要是新的产品也保持巨石架构,那就不得不全部一股脑复制过去。

    但又由于业务肯定不同,要针对性修改也感觉怪麻烦的。

    后期的话随着迭代的加深,我各个产品线的基础服务甚至都可能会变得不太一样,到时候同时维护多个产品估摸着也会有些消耗心智。

    所以我又想着捡起微服务了…… 给自己做一套 SAAS 是不是挺不错的?

    • 先用 RBAC 做一套统一的 Auth 服务。

    • 然后把基础设施抽取出来,不进行更细粒度的拆分直接把常用的基础服务打包到一起。

    • 然后考虑拆一个专门的对接服务用来和第三方打交道。

    • 底层数据模型就类似多租户的模式,做 APP 隔离。

    • 中间件准备在加一个,在 Postgres 外添加个 Redis ,够了。

    那么在这几个服务的支持下, 我在开新的软件、新产品 就快速方便很多了。

    至于多个服务用一套基础服务的性能问题,我是完全不考虑的。 现在我那个单体项目的 DB 配置也就 1c1g ,还天天 CPU 10%。



    差不多就这样了……

    不知道我的考虑是否正常,想法是否正确?

    上面就权当抛砖引玉, 看看各位老哥有没有啥经验,还请多多指导我。




    14 条回复    2021-12-17 09:11:14 +08:00
    libook
        1
    libook  
       156 天前   ❤️ 4
    循序渐进的思路是对的,做原型就什么顺手用什么就好,项目隔一段时间重构一次是正常的,每段时期都会有新的需求局态,根据需求再确定是否要变更选型就好,新技术可以上手做做实验,验证是否符合当下的需求,不符合也没必要硬上,对于还在炒作期的技术还是谨慎些吧,玩玩可以。

    微服务其实是拿管理维护成本来换开发运营成本,所以虽然开发运营会比较爽,但还需要考虑服务治理问题,使用服务治理中间件和混沌工程来解决各种微服务特有的问题。

    公司里有个微服务拆分的评判标准,就是如果一个微服务尚不具备复用的需要,就不拆,但代码上确保随时可拆,项目服务可以以单服务运行,各个功能模块可以作为逻辑上的微服务工作,像微服务 API 之类的走微服务的实施标准,这样也可以享受一些微服务的好处,又不至于过早面临服务治理问题。
    xuanbg
        2
    xuanbg  
       156 天前
    一个巨石和相同功能的七八个微服务开发周期有区别?至少对我而言根本没区别。在软件开发上,真正能造成浪费的一般都是错误的功能设计。
    wujiezero
        3
    wujiezero  
       156 天前
    做微服务可以,个人项目不拆那么细就可以了,哪怕你微服务里只有一个工程,先一步一步来。
    rophie123
        4
    rophie123  
       156 天前
    别想太多,我就是复制复制,无所谓了,最后一个没成
    zliea
        5
    zliea  
       156 天前
    如果一个人,可以考虑多个 module ,然后方便拆分。
    makelove
        6
    makelove  
       156 天前
    @xuanbg 除非你有别的项目可以共享服务,否则分很多还是有很大管理成本的,我就分了二个出去就觉得麻烦了(对个人开发者来说
    xuanbg
        7
    xuanbg  
       155 天前
    @makelove 服务本来就应该是共享的呀,一些基础的功能做成微服务,只要在那里,就一直都可以用。具体你可以点头像看我的 github 。
    litchinn
        8
    litchinn  
       155 天前
    认证中心推荐下 keycloak ,用起来还挺方便的,就是数据方面的集成前期要花点时间
    SmiteChow
        9
    SmiteChow  
       155 天前
    微服务的提出本来就不是为了项目考虑,而是为了大规模协作,直白点就是大厂人多每个部门都要立山头。
    agagega
        10
    agagega  
       155 天前 via iPhone
    所以为什么要分服务?是名下有成吨的项目,还是千万用户遇到了性能瓶颈?

    能干活的技术就是最好的技术: https://ruby-china.org/topics/39735
    ggbond2233
        11
    ggbond2233  
       155 天前
    从 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 应用.

    自己的业务就不要给自己找麻烦了.
    ggbond2233
        12
    ggbond2233  
       155 天前
    诸如 [用户系统] [认证鉴权] [主题 /文章 /帖子等 UGC 模块] [回复中心 /消息中心] [用户动态] [第三方服务对接] [图片存储 /处理] ……等等等等“基础服务”实际上是属于你无论开啥 APP 都可以用上、有机会用上的。

    关于这个基础我是建议 admin 管理后台引入一个开源的单独管理 ruoyi 之类的都有,业务系统单独自己开项目
    sorakylin
        13
    sorakylin  
    OP
       154 天前
    @ggbond2233 用 ruoyi 的话是不是就是直接用 ruoyi 起一个服务, 我自己开新东西就直接去对接他暴露的 API 这样子?
    ggbond2233
        14
    ggbond2233  
       154 天前
    @sorakylin 是的,若依有很多版本,我用的是类似的 cms, 插入文章 都是通过 api,也可能在业务系统直接使用 ruoyi 同一数据库插入
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2447 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 33ms · UTC 11:39 · PVG 19:39 · LAX 04:39 · JFK 07:39
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.