这是一个创建于 2354 天前的主题，其中的信息可能已经有所发展或是发生改变。
是公司新的战略项目，预计有 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
 | 1 dongisking 2019 年 8 月 1 日 首选 1，备选 2 要是同事里面 go 没深入就用了，产品出不来就锅大了 |
 | 2 darkweb 2019 年 8 月 1 日 首选 2，备选 3 |
 | 3 kuaner 2019 年 8 月 1 日 考虑到 2-3 月的开发周期，建议从拿手的语言选 |
 | 4 xpresslink 2019 年 8 月 1 日 本来建议选 2，企业级开发 java 的生态资源比较全面丰富，各种现成的中间件拿来就用。 但是你们的技术栈是屁还是屁又只有 2/3 个月时间，那就没有可想的了，只能 1 了。 |
 | 5 xsir2020 2019 年 8 月 1 日 首选 1 备选 1 其次还是 1 设计的时候，记得参考下微软的 restful 标准指南 ：） 还没搞完 http://note.youdao.com/noteshare?id=2796e930e0847fa4a08f66e1da709a50 |
 | 6 rockyou12 2019 年 8 月 1 日 不用 go 就行了，go 要自己搭很多架子的，php 和 java 起码轮子多 |
 | 7 luozic 2019 年 8 月 1 日 via iPhone go 轮子要造不少，现在开源的完整 solution 太少 |
 | 8 janxin 2019 年 8 月 1 日 首选 1 啊，多好 |
 | 9 Rorysky 2019 年 8 月 1 日 via iPhone 用最熟悉的，谁还不是图灵完备？ |
 | 10 PDX 2019 年 8 月 1 日 vert.x |
 | 11 Leigg 2019 年 8 月 1 日 via Android 你是小 leader 吗？ 如果要选择 go，还得说服团队上级吧？而且建议至少有一个人对 go 是熟悉的，不然从方案选择上来看不够稳。 |
 | 12 crayygy 2019 年 8 月 1 日 via Android  1 选 2，然后用 Kotlin |
 | 13 iPhoneXI 2019 年 8 月 1 日 1，2 差不多吧 3 最后选项 |
 | 14 rb6221 2019 年 8 月 1 日 .NET 来一波？ |
 | 15 geekc3t 2019 年 8 月 1 日 elixir? |
 | 16 yejinmo 2019 年 8 月 1 日 .Net Core 吧 |
 | 17 silverfox 2019 年 8 月 1 日 3 选择大家都熟悉的技术。 个人认为，相比于各种编程语言，合理定义各个服务的业务边界，为之后留下扩展或者重构的空间更重要。 微服务架构下编程语言的重要性并没有那么高，先要满足度量、日志、调用链的标准化要求。在此基础上如果有更丰富的功能当然更好。 值得注意的是，API 定义不要暴露出语言或者某种框架的特性。那么在 API Gateway 的支持下，把一部分功能以更合适的语言重构成单独的服务并不是一件很难的事情。 |
 | 18 GG668v26Fd55CP5W 2019 年 8 月 1 日 via iPhone 1/2/3，选 3 就天天加班吧 |
 | 19 yiyi11 2019 年 8 月 1 日 根据你的目标的话，2 是最理想的选择。 但是根据你的工期，1 是最现实的选择。 springboot+springcloud+生态，提供了大量的开箱即用的功能，但是提供了很多，封装的东西就更多。什么都是“约定大于配置”前提是使用者知道这些“约定”--也就是说需要接触过 sprng 的生态。所以这是需要一定时间调研的。 当然好处就是，如果最终目标是微服务化，那么以后需要的东西，官方都提供了开箱即用的解决方案。 |
 | 20 ben1024 2019 年 8 月 1 日 能选就选 PHP，节省下来的时间用来怎么摸鱼充电都行， 除非公司整体转型强制要求 |
 | 21 zaul 2019 年 8 月 1 日 php 是世界上最好的语言 |
| 22 yiyi11 2019 年 8 月 1 日 微服务是现在也是未来=微服务还有很多的坑=或许你并不需要微服务。站在老板的立场，稳定是最好的。但是站在技术人的角度，挖坑才有产出。 |
 | 23 mcfog 2019 年 8 月 1 日 via Android grpc 现在支持直接以 http 协议暴露，微服务用 go，前面 php 写胶水层，or 你们前端团队够骚让他们用 node 做胶水 |
 | 24 version 2019 年 8 月 1 日 via iPhone php 一套撸就可以了，也别微服务那么标准了，3 年都是 crud 的多，他们对微服务理解不了，不好赶工， 拆分项目出来就好，例如订单模块，优惠券模块，库存模块，等 http 通信，也别 php 一套运行就好 |
 | 25 zachlhb 2019 年 8 月 1 日 via Android 用 python 吧 |
 | 26 akira 2019 年 8 月 1 日 开发团队都是 3 年以上的 PHPer，Java 也都懂点，Go 大家没深入了解不过名声在外。 ------------------ 先选团队熟悉的语言，然后才是选框架. 首选 1 |
 | 27 amanbolatbalabek 2019 年 8 月 1 日 via iPhone 要快的话用 postgREST，用 sql 写逻辑然后直接接个 SPA。逻辑在复杂也没问题。 |
 | 28 a1274598858 2019 年 8 月 1 日 1 别问。。问就是 Java |
 | 29 cabing 2019 年 8 月 1 日 不管用啥语言，业务模块拆分成各种服务，提供 grpc 调用，不要耦合，不要单体。 可以先用 php 撸一套，快速开发，也不用加班啥的，别 996，后续量起来了，核心服务方便迁移都是产出，美滋滋。 首选 1 备选 2 |
 | 30 Takamine 2019 年 8 月 1 日 via Android 选 1 吧。 如果对 Java 只是懂点，那涉及到最初选型和设计架构等到后面转微服务感觉会挺坑的。 另外都拆微服务了，每一个子系统彼此独立，语言不怎么受局限了。 |
 | 31 zgqq 2019 年 8 月 2 日 spring boot 好点，问题好解决， 生态丰富 |
 | 32 MonoLogueChi 2019 年 8 月 2 日 via Android 推荐选熟悉的语言，如果确定压力比较大，建议直接上 Java，据我了解，一些公司是先 PHP 快速开发，让服务以最快的速度上线，业务量快上升到 PHP 瓶颈的时候，再用 Java 重构。 我个人还是推荐一下 .net core，性能不错，API 写起来很爽。大项目上表现怎么样我不清楚，我没写过大项目。如果不熟悉这个东西的话，就当我没说 |
 | 33 xuanbg 2019 年 8 月 2 日 都要上微服务了，还纠结个 P，用最熟悉的 PHP 先撸出来再说了。后面新项目换技术栈也是随便换的事情，根本就不会影响到已有的项目。 |
 | 34 jorneyr 2019 年 8 月 2 日 使用不熟悉的，2 个月都不够你们学习的，除非你们敢把 Hello World 用到项目上。 |
 | 35 ytlm 2019 年 8 月 2 日 openresty? |
 | 36 a852695 2019 年 8 月 2 日 用 python ？ 一周就开始上手搞 |
 | 37 darknoll 2019 年 8 月 2 日 选 2 和 3，你们行吗？ |
 | 38 jingxyy 2019 年 8 月 2 日 别问 问就是 golang 用到就爽到 |
 | 39 kiwier 2019 年 8 月 2 日 go+etcd 啊 |
 | 40 zhang77555 2019 年 8 月 2 日 看你们愿不愿意加班咯, 选不熟悉的技术体系,一定会遇到坑. |
 | 41 liuxey 2019 年 8 月 2 日 如果“目标是微服务化”，那么这三个选项中只有 2 有成熟的生态体系，不要想自己搞，出不来的 再看时间 2~3 个月，看你们的业务量，如果你们 PHP 熟手都觉的有点赶，那么还是选 1 吧 选 3 等着爆炸 |
 | 42 toma77 2019 年 8 月 2 日 1 go+gin |
 | 43 spotfg 2019 年 8 月 2 日 选熟悉的搞，开发速度最快，因为每个语言都有坑，可以有效避免 |
 | 44 lowman 2019 年 8 月 2 日 1 现在不埋坑, 后续怎么有理由去重构, 不重构, 怎么立项目, 没项目, 怎么来就业岗位, 没岗位, 怎么养活自己, 怎么出业绩, 怎么保证自己在公司的存在感, 水还是有的, 看要流多少, 坑还是有的, 看要挖多深....................... |
 | 45 anteros 2019 年 8 月 2 日 目标是不是错了？你说目标是微服务化，这只能说是手段，而真正的目的应该是项目模块解耦，解耦的前提是，项目确保能用且少出问题。 |
 | 46 hoyixi 2019 年 8 月 2 日 怎么舒服怎么来，都是 PHP 老手，轻松搞出来，维护也舒服，bug 也少，剩下时间深研一下 PHP 前沿，或者喝喝咖啡听听音乐不好吗，为啥要为了 go 而 go |
 | 47 qdl 2019 年 8 月 2 日 .net core 了解下 |
 | 48 nnnToTnnn 2019 年 8 月 2 日 Java 上 spring 全家 PHP 不知道，感觉不合适，根据 PHP 的特性 Go 更加简单，拿 bilibili 用就可以了 |
 | 49 shynome 2019 年 8 月 2 日 via Android Golang echo 框架，开箱即用，感觉和 php 差不多简单了 |
 | 50 urmyfaith 2019 年 8 月 2 日 方案考虑点 0) 结合项目时间,交付方要求,后期维护考虑. 1) 首要,选最熟悉擅长的 2) 其次,选择生态好的,有成熟解决方案的,(java/php) |
 | 51 hikarugo 2019 年 8 月 2 日 总觉得你来这里问意义不大。。。 |
 | 52 shanYueFengCheng 2019 年 8 月 2 日 首选 2，后期微服务化升级基础，java 技术体系成熟，方案多。备选 3,看你们同事水平，都是渣渣一路踩坑会延期严重 |
 | 54 vmskipper 2019 年 8 月 2 日 根据团队的整体技术水平和项目工期定 肯定排除 3 go 需要写很多通用组件 |
 | 55 lonelygo 2019 年 8 月 2 日 技术路线选择，首位要考虑的就是项目时间。 2 ～ 3 个月，考虑到设计、架构、测试、填坑、微服务发布，乱七八糟的一堆事情。 建议选 1 ； 上线跑起来了，趁着用不量不大，而且大家确实“技痒”，也对未来一段时间的挖坑、填坑有心里准备，也互相信任不会甩的锅满天飞，以：“因对未来可遇见的大并发”以及“业务需求可遇见的增加与变化”，需要“引入”“ DDD ”设计模式，通过“微服务”逐步实现“中台战略”，所以要“重构”为 SpringBoot，最终实现 K8S 的分布式架构。 切记： 技术选型千万不能为了技术而技术。 |
 | 56 yy77 2019 年 8 月 2 日 只写个 rest 接口不能叫微服务。时间短就用自己最熟悉的了。 要上微服务国产的 dubbo 之类的比较好吧。 |
 | 57 myyou 2019 年 8 月 2 日 既然有 php 的人力优势，还是选 1 吧，php7 性能还是不错的。 |
 | 58 jayin 2019 年 8 月 2 日 选 3，有挑战 |
 | 59 PerpetualHeng 2019 年 8 月 2 日 java 吧，不然等着后悔吧 |
 | 60 37miao 2019 年 8 月 2 日 .net core 了解下 |
 | 61 Cbdy 2019 年 8 月 2 日 熟悉什么用什么，即使用 Java 也要有对 Java 熟悉的人 |
 | 62 yl666 2019 年 8 月 2 日 可以先用 1，后续慢慢磨用 sc 的 sidecar 把服务逐渐迁移到 2 上来 |
 | 63 T3RRY 2019 年 8 月 2 日 go gin |
 | 64 Raymon111111 2019 年 8 月 2 日 java 用别的最后还是换成 java |
 | 65 ittianyu 2019 年 8 月 2 日 直接上 serverless 吧，方法为粒度的微服务（手动滑稽） |
 | 66 golden0125 2019 年 8 月 2 日 如果 PHP7.3 + SWOOLE 也无法满足你们你们需求的话,有什么底气选择半路出家的 JAVA 和 GO? |
 | 67 Felldeadbird 2019 年 8 月 2 日 请选择成熟的。轻易尝试新技术，做好后期重构的成本。 |
 | 68 rwecho 2019 年 8 月 2 日 |
 | 69 useben 2019 年 8 月 2 日 go+gin，秒杀一切 |
 | 70 jss 2019 年 8 月 3 日 via iPhone 1 真实案例告诉你，go+gin 秒杀你说的其他所有语言，示例：PHP 一万条数据做无限级操作大概需要 5~7 秒，GO 毫秒级完成 |
 | 71 liuhan907 2019 年 8 月 10 日 via Android 如果你们考虑.net core 可以尝试 service-fabric，体会一下只管业务逻辑其它全都不用操心的全套服务。 |
Select Language