V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
qce7
V2EX  ›  程序员

新系统的 API 后端开发语言选型

  •  
  •   qce7 · 2019-08-01 17:48:10 +08:00 · 9071 次点击
    这是一个创建于 1968 天前的主题,其中的信息可能已经有所发展或是发生改变。

    是公司新的战略项目,预计有 2,3 个月的开发时间,后边会一直持续迭代。业务比较复杂,各种的业务逻辑,不过用户量短时间不会暴增 新项目后端前后端分离,只写 Api,考虑 PHP 写 Web Api 优势并不明显,并且目标是微服务化,考虑是否换语言 目前的 Option 有

    • 继续用 php 只是换到最新版( 49 国军?)搭配 swoole
    • SpringBoot
    • Go 的一个 Web 框架(具体还没想好)

    开发团队都是 3 年以上的 PHPer,Java 也都懂点,Go 大家没深入了解不过名声在外。

    请教下大佬们的意见,如果是你们这种情况你们怎么选?

    72 条回复    2020-01-11 18:05:04 +08:00
    dongisking
        1
    dongisking  
       2019-08-01 17:50:13 +08:00
    首选 1,备选 2

    要是同事里面 go 没深入就用了,产品出不来就锅大了
    darkweb
        2
    darkweb  
       2019-08-01 17:55:30 +08:00
    首选 2,备选 3
    kuaner
        3
    kuaner  
       2019-08-01 17:56:47 +08:00
    考虑到 2-3 月的开发周期,建议从拿手的语言选
    xpresslink
        4
    xpresslink  
       2019-08-01 18:00:10 +08:00
    本来建议选 2,企业级开发 java 的生态资源比较全面丰富,各种现成的中间件拿来就用。
    但是你们的技术栈是屁还是屁又只有 2/3 个月时间,那就没有可想的了,只能 1 了。
    xsir2020
        5
    xsir2020  
       2019-08-01 18:00:13 +08:00
    首选 1 备选 1 其次还是 1

    设计的时候,记得参考下微软的 restful 标准指南 :)
    还没搞完
    http://note.youdao.com/noteshare?id=2796e930e0847fa4a08f66e1da709a50
    rockyou12
        6
    rockyou12  
       2019-08-01 18:00:49 +08:00
    不用 go 就行了,go 要自己搭很多架子的,php 和 java 起码轮子多
    luozic
        7
    luozic  
       2019-08-01 18:34:13 +08:00 via iPhone
    go 轮子要造不少,现在开源的完整 solution 太少
    janxin
        8
    janxin  
       2019-08-01 18:44:06 +08:00
    首选 1 啊,多好
    Rorysky
        9
    Rorysky  
       2019-08-01 18:45:41 +08:00 via iPhone
    用最熟悉的,谁还不是图灵完备?
    PDX
        10
    PDX  
       2019-08-01 18:56:22 +08:00
    vert.x
    Leigg
        11
    Leigg  
       2019-08-01 19:34:56 +08:00 via Android
    你是小 leader 吗? 如果要选择 go,还得说服团队上级吧?而且建议至少有一个人对 go 是熟悉的,不然从方案选择上来看不够稳。
    crayygy
        12
    crayygy  
       2019-08-01 19:41:18 +08:00 via Android   ❤️ 1
    选 2,然后用 Kotlin
    iPhoneXI
        13
    iPhoneXI  
       2019-08-01 19:45:01 +08:00
    1,2 差不多吧
    3 最后选项
    janus77
        14
    janus77  
       2019-08-01 19:54:23 +08:00
    .NET 来一波?
    geekc3t
        15
    geekc3t  
       2019-08-01 19:59:17 +08:00
    elixir?
    yejinmo
        16
    yejinmo  
       2019-08-01 20:00:01 +08:00
    .Net Core 吧
    silverfox
        17
    silverfox  
       2019-08-01 20:01:25 +08:00   ❤️ 3
    选择大家都熟悉的技术。

    个人认为,相比于各种编程语言,合理定义各个服务的业务边界,为之后留下扩展或者重构的空间更重要。

    微服务架构下编程语言的重要性并没有那么高,先要满足度量、日志、调用链的标准化要求。在此基础上如果有更丰富的功能当然更好。

    值得注意的是,API 定义不要暴露出语言或者某种框架的特性。那么在 API Gateway 的支持下,把一部分功能以更合适的语言重构成单独的服务并不是一件很难的事情。
    falcon05
        18
    falcon05  
       2019-08-01 20:02:07 +08:00 via iPhone
    1/2/3,选 3 就天天加班吧
    yiyi11
        19
    yiyi11  
       2019-08-01 20:04:32 +08:00
    根据你的目标的话,2 是最理想的选择。
    但是根据你的工期,1 是最现实的选择。
    springboot+springcloud+生态,提供了大量的开箱即用的功能,但是提供了很多,封装的东西就更多。什么都是“约定大于配置”前提是使用者知道这些“约定”--也就是说需要接触过 sprng 的生态。所以这是需要一定时间调研的。
    当然好处就是,如果最终目标是微服务化,那么以后需要的东西,官方都提供了开箱即用的解决方案。
    ben1024
        20
    ben1024  
       2019-08-01 20:05:08 +08:00
    能选就选 PHP,节省下来的时间用来怎么摸鱼充电都行,
    除非公司整体转型强制要求
    zaul
        21
    zaul  
       2019-08-01 20:07:04 +08:00
    php 是世界上最好的语言
    yiyi11
        22
    yiyi11  
       2019-08-01 20:10:13 +08:00
    微服务是现在也是未来=微服务还有很多的坑=或许你并不需要微服务。站在老板的立场,稳定是最好的。但是站在技术人的角度,挖坑才有产出。
    mcfog
        23
    mcfog  
       2019-08-01 20:15:23 +08:00 via Android
    grpc 现在支持直接以 http 协议暴露,微服务用 go,前面 php 写胶水层,or 你们前端团队够骚让他们用 node 做胶水
    version
        24
    version  
       2019-08-01 20:17:31 +08:00 via iPhone
    php 一套撸就可以了,也别微服务那么标准了,3 年都是 crud 的多,他们对微服务理解不了,不好赶工,
    拆分项目出来就好,例如订单模块,优惠券模块,库存模块,等 http 通信,也别 php 一套运行就好
    zachlhb
        25
    zachlhb  
       2019-08-01 20:20:53 +08:00 via Android
    用 python 吧
    akira
        26
    akira  
       2019-08-01 20:25:41 +08:00
    开发团队都是 3 年以上的 PHPer,Java 也都懂点,Go 大家没深入了解不过名声在外。
    ------------------
    先选团队熟悉的语言,然后才是选框架. 首选 1
    amanbolatbalabek
        27
    amanbolatbalabek  
       2019-08-01 20:36:46 +08:00 via iPhone
    要快的话用 postgREST,用 sql 写逻辑然后直接接个 SPA。逻辑在复杂也没问题。
    a1274598858
        28
    a1274598858  
       2019-08-01 22:49:54 +08:00   ❤️ 1
    别问。。问就是 Java
    cabing
        29
    cabing  
       2019-08-01 22:59:30 +08:00
    不管用啥语言,业务模块拆分成各种服务,提供 grpc 调用,不要耦合,不要单体。

    可以先用 php 撸一套,快速开发,也不用加班啥的,别 996,后续量起来了,核心服务方便迁移都是产出,美滋滋。


    首选 1 备选 2
    Takamine
        30
    Takamine  
       2019-08-01 23:50:16 +08:00 via Android
    选 1 吧。
    如果对 Java 只是懂点,那涉及到最初选型和设计架构等到后面转微服务感觉会挺坑的。
    另外都拆微服务了,每一个子系统彼此独立,语言不怎么受局限了。
    zgqq
        31
    zgqq  
       2019-08-02 00:40:02 +08:00
    spring boot 好点,问题好解决, 生态丰富
    MonoLogueChi
        32
    MonoLogueChi  
       2019-08-02 01:44:36 +08:00 via Android
    推荐选熟悉的语言,如果确定压力比较大,建议直接上 Java,据我了解,一些公司是先 PHP 快速开发,让服务以最快的速度上线,业务量快上升到 PHP 瓶颈的时候,再用 Java 重构。

    我个人还是推荐一下 .net core,性能不错,API 写起来很爽。大项目上表现怎么样我不清楚,我没写过大项目。如果不熟悉这个东西的话,就当我没说
    xuanbg
        33
    xuanbg  
       2019-08-02 07:41:52 +08:00
    都要上微服务了,还纠结个 P,用最熟悉的 PHP 先撸出来再说了。后面新项目换技术栈也是随便换的事情,根本就不会影响到已有的项目。
    jorneyr
        34
    jorneyr  
       2019-08-02 08:09:13 +08:00
    使用不熟悉的,2 个月都不够你们学习的,除非你们敢把 Hello World 用到项目上。
    ytlm
        35
    ytlm  
       2019-08-02 08:45:48 +08:00
    openresty?
    a852695
        36
    a852695  
       2019-08-02 09:03:31 +08:00
    用 python ?
    一周就开始上手搞
    darknoll
        37
    darknoll  
       2019-08-02 09:09:03 +08:00
    选 2 和 3,你们行吗?
    jingxyy
        38
    jingxyy  
       2019-08-02 09:10:42 +08:00
    别问 问就是 golang 用到就爽到
    kiwier
        39
    kiwier  
       2019-08-02 09:13:19 +08:00
    go+etcd 啊
    zhang77555
        40
    zhang77555  
       2019-08-02 09:14:30 +08:00
    看你们愿不愿意加班咯, 选不熟悉的技术体系,一定会遇到坑.
    liuxey
        41
    liuxey  
       2019-08-02 09:14:53 +08:00
    如果“目标是微服务化”,那么这三个选项中只有 2 有成熟的生态体系,不要想自己搞,出不来的

    再看时间 2~3 个月,看你们的业务量,如果你们 PHP 熟手都觉的有点赶,那么还是选 1 吧

    选 3 等着爆炸
    toma77
        42
    toma77  
       2019-08-02 09:16:55 +08:00   ❤️ 1
    go+gin
    spotfg
        43
    spotfg  
       2019-08-02 09:26:07 +08:00
    选熟悉的搞,开发速度最快,因为每个语言都有坑,可以有效避免
    lowman
        44
    lowman  
       2019-08-02 09:33:07 +08:00   ❤️ 1
    现在不埋坑, 后续怎么有理由去重构, 不重构, 怎么立项目, 没项目, 怎么来就业岗位, 没岗位, 怎么养活自己, 怎么出业绩, 怎么保证自己在公司的存在感, 水还是有的, 看要流多少, 坑还是有的, 看要挖多深.......................
    php01
        45
    php01  
       2019-08-02 09:36:16 +08:00
    目标是不是错了?你说目标是微服务化,这只能说是手段,而真正的目的应该是项目模块解耦,解耦的前提是,项目确保能用且少出问题。
    hoyixi
        46
    hoyixi  
       2019-08-02 09:37:12 +08:00
    怎么舒服怎么来,都是 PHP 老手,轻松搞出来,维护也舒服,bug 也少,剩下时间深研一下 PHP 前沿,或者喝喝咖啡听听音乐不好吗,为啥要为了 go 而 go
    qdl
        47
    qdl  
       2019-08-02 09:40:49 +08:00
    .net core 了解下😀
    nnnToTnnn
        48
    nnnToTnnn  
       2019-08-02 09:45:52 +08:00
    Java 上 spring 全家
    PHP 不知道,感觉不合适,根据 PHP 的特性
    Go 更加简单,拿 bilibili 用就可以了
    shynome
        49
    shynome  
       2019-08-02 09:46:02 +08:00 via Android
    Golang echo 框架,开箱即用,感觉和 php 差不多简单了
    urmyfaith
        50
    urmyfaith  
       2019-08-02 10:21:20 +08:00
    方案考虑点
    0) 结合项目时间,交付方要求,后期维护考虑.
    1) 首要,选最熟悉擅长的
    2) 其次,选择生态好的,有成熟解决方案的,(java/php)
    fyxtc
        51
    fyxtc  
       2019-08-02 14:04:20 +08:00
    总觉得你来这里问意义不大。。。
    shanYueFengCheng
        52
    shanYueFengCheng  
       2019-08-02 14:12:49 +08:00
    首选 2,后期微服务化升级基础,java 技术体系成熟,方案多。备选 3,看你们同事水平,都是渣渣一路踩坑会延期严重
    Evilk
        53
    Evilk  
       2019-08-02 15:06:15 +08:00
    @php01 赞同,微服务的目的是为了解耦,但要达到解耦,不一定非要上微服务
    vmskipper
        54
    vmskipper  
       2019-08-02 15:15:09 +08:00
    根据团队的整体技术水平和项目工期定 肯定排除 3 go 需要写很多通用组件
    lonelygo
        55
    lonelygo  
       2019-08-02 15:23:12 +08:00
    技术路线选择,首位要考虑的就是项目时间。
    2 ~ 3 个月,考虑到设计、架构、测试、填坑、微服务发布,乱七八糟的一堆事情。
    建议选 1 ;
    上线跑起来了,趁着用不量不大,而且大家确实“技痒”,也对未来一段时间的挖坑、填坑有心里准备,也互相信任不会甩的锅满天飞,以:“因对未来可遇见的大并发”以及“业务需求可遇见的增加与变化”,需要“引入”“ DDD ”设计模式,通过“微服务”逐步实现“中台战略”,所以要“重构”为 SpringBoot,最终实现 K8S 的分布式架构。

    切记:
    技术选型千万不能为了技术而技术。
    yy77
        56
    yy77  
       2019-08-02 15:26:49 +08:00
    只写个 rest 接口不能叫微服务。时间短就用自己最熟悉的了。

    要上微服务国产的 dubbo 之类的比较好吧。
    myyou
        57
    myyou  
       2019-08-02 15:37:47 +08:00
    既然有 php 的人力优势,还是选 1 吧,php7 性能还是不错的。
    jayin
        58
    jayin  
       2019-08-02 15:44:52 +08:00
    选 3,有挑战
    PerpetualHeng
        59
    PerpetualHeng  
       2019-08-02 15:49:08 +08:00
    java 吧,不然等着后悔吧
    37miao
        60
    37miao  
       2019-08-02 15:58:09 +08:00
    .net core 了解下
    Cbdy
        61
    Cbdy  
       2019-08-02 16:05:55 +08:00
    熟悉什么用什么,即使用 Java 也要有对 Java 熟悉的人
    yl666
        62
    yl666  
       2019-08-02 16:18:59 +08:00
    可以先用 1,后续慢慢磨用 sc 的 sidecar 把服务逐渐迁移到 2 上来😄
    T3RRY
        63
    T3RRY  
       2019-08-02 16:23:39 +08:00
    go gin
    Raymon111111
        64
    Raymon111111  
       2019-08-02 16:25:45 +08:00
    java

    用别的最后还是换成 java
    ittianyu
        65
    ittianyu  
       2019-08-02 16:33:33 +08:00
    直接上 serverless 吧,方法为粒度的微服务(手动滑稽)
    golden0125
        66
    golden0125  
       2019-08-02 16:44:07 +08:00
    如果 PHP7.3 + SWOOLE 也无法满足你们你们需求的话,有什么底气选择半路出家的 JAVA 和 GO?
    Felldeadbird
        67
    Felldeadbird  
       2019-08-02 16:45:09 +08:00
    请选择成熟的。轻易尝试新技术,做好后期重构的成本。
    rwecho
        68
    rwecho  
       2019-08-02 16:57:00 +08:00
    哇, 竟然有这么多推荐.net core 的

    .net core + 1.
    useben
        69
    useben  
       2019-08-02 22:50:03 +08:00
    go+gin,秒杀一切
    jss
        70
    jss  
       2019-08-03 06:58:58 +08:00 via iPhone   ❤️ 1
    真实案例告诉你,go+gin 秒杀你说的其他所有语言,示例:PHP 一万条数据做无限级操作大概需要 5~7 秒,GO 毫秒级完成
    liuhan907
        71
    liuhan907  
       2019-08-10 14:08:18 +08:00 via Android
    如果你们考虑.net core 可以尝试 service-fabric,体会一下只管业务逻辑其它全都不用操心的全套服务。
    charlie21
        72
    charlie21  
       2020-01-11 18:05:04 +08:00
    @rockyou12 @liuxey 微服务 要什么复杂生态? RESTful 或者 rpc 嘛
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2931 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 30ms · UTC 08:26 · PVG 16:26 · LAX 00:26 · JFK 03:26
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.