今天下午正常的碰头会上几个技术一起讨论在后端API是继续Go还是换回Java的问题，首先说一下大致情况，我们团队内部5个人基本都有Java项目背景，吹牛一点可以说精通，都是在大厂干过的>35的老程序员（Go只能说是熟练不敢说精通）；
在项目差不多一个月的迁移压测后大致得出的结论如下：
- 如果按照Java DDD的思想去直接迁移代码，Go相对Java代码量差不多多出30~40%左右，大部分都是重复的Err判断和DDD数据隔离的复制；
- 如果忘记Java按照函数式编程去改造（部分模块已经改造完），差不多Go代码相对Java会多20~30左右，排除的都是DDD在不同层及域内部的各种O转换；
- Go的确需要我们造很多轮子，可能有同学说去网上一搜都是差不多对应的功能，但是想说的是真的用起来就不是那么回事，太多细节上的差异；
- 简单压测（Request->webServer->app->db + 内部报表）发现Go的性能并不是都是比JIT后的Java性能好，其实Java大部分场景更优秀；毕竟是B端业务应用，不是聊天类的小请求多的场景，Go的协程优势对我们来说就不那么重要；
- 内存占用Go启动30M，Java启动最少150M，并发上来后的压测其实Go和Java内存占用差别不大，反倒Go捡漏的GC的劣势就出现Request毛刺更明显；但但但我们的应用目前是达不到压测的200 OPS的，所以这个也影响不大；
后续我们会持续投入Go，主要是因为我们在起步阶段，内存成本是要考虑的很重要因素，追求更低的单位请求成本,大家咬牙继续，各种轮子的稳定性和长期维护头大，说不定哪天搞不定又把部分Go的换回Java
