Go 跨平台（机器）部署这么方便的吗？

[imherer]

这几天不忙就看了下 go，然后用 beego 写了个 demo

我是在 mac 上开发的，尝试部署在 Linux 和 Windows 上，我发现只需要直接 build 为对应平台的版本就行了，在对应的机器上不需要安装 go 运行环境吗？

像 Node.js 或者 Python 甚至.NET ，在部署在都得在需要部署的机器上提前安装好环境，go 不需要，直接 build 然后把 build 出来的文件丢到服务器上就行了？这么方便的吗？

另外还有几个问题请教一下大佬：

1.go 最后打包出来的可执行文件永远只有一个吗？有没有可能根据我的业务逻辑分别打包成几大块（例如：main、lib1、lib2 ），虽然好像这样意义也不大？

2.写代码前需要设置 GOPATH。假如我有多个项目的话 GOPATH 是不是也得设置多个？那 GOBIN 好像只能设置一个啊。
对于多个项目你们是怎么弄的？还是 GOPATH 只有一个，在 src 下建不同的文件夹来区分项目吗，最后通过 go build 指定路径来打包吗？

3.假如我现在打包出来一个文件为 main，在 Linux 执行它的方式为./main （是这样的吧）

4.go 有没有类似 Node.js 下的 pm2 这种守护进程管理工具？ 你们在服务器上怎么部署的 go ？总不可能是 nohup 吧

最后：刚接触，可能有些地方问的不对的还请各位大佬见谅！

[ShayneWang]

插眼

[hellojinjie]

4. supervisorctl 或者 systemctl

[Vogan]

go 支持交叉编译；
go 编译出来的是二进制文件；
可用 systemd 管理；

[Ediacaran]

1 应该是只有一个二进制文件，没见过 go 用动态链接库的

顺便插眼

[daigouspy]

谁说.net 一定要提前部署环境?

[ETiV]

pm2 也支持任意可执行程序的运行的～

偷懒就都用 pm2 …

服务器上也可以用 docker 拉起来

[richangfan]

“一次编译，处处运行”不服

[RqPS6rhmP3Nyn3Tm]

go 是真的牛逼，跨架构直接编译成一个 binary，复制上去就能跑
我不会写 go，但是有一次编译 armv7 的 ss-go，指定 CPU 就能直接编译出一个 binary，没有任何依赖问题，对年轻的我造成了巨大的冲击

[heimeil]

1. 可以随意组织项目结构，随便分多少都行，只要你愿意；
2. GOPATH 一般情况都是一个，用目录区分，$GOPATH/src/<源码托管站域名>/<ID>/项目，不过也可以很随意，看个人或团队习惯；
3. 编译成二进制文件随便怎么改名都行，在 Linux 上只要保证权限正确就行了；
4. 我个人喜欢用 docker 托管，其他方法也很多。

另外 Golang 不是不用装环境，而是环境都在编译的二进制文件里面了，你会发现 Go 编译出来的二进制比.NET 之类的大太多了。

[hnpyhyz]

战略插眼

[a719114136]

1. go 编译时把所有用到的东西、运行环境都放到一个文件里了，所以其他平台没安装 go 也可以运行。至于生成多个块没研究过，go 编译时有个参数-buildmode，不知道能不能做到这个。
2. GOPATH 设置看习惯了，两种方式：每个项目有每个项目的 GOPATH，或者所有项目用一个 GOPATH。
3. 是
4. 进程管理工具都是通用的，有：supervisor，Upstart，Systemd 都可以

[zarte]

1.按微服务一个个开发。
2.我是在底下按文件夹分
3.是的
4.supervior 这类守护

[v2xe2v]

docker 了解一下

[lfzyx]

systemd

不管什么服务都推荐 docker 的，不是坏就是蠢

[giuem]

自从有了 go mod 之后，只要一个全局的 GOPATH，项目随便放，不需要非得放 GAPATH 下

[zst]

3.是的
4.用 systemd 就好

顺便问一下除了 go 还有有哪些不用安装依赖的😊

[TinyKube]

@giuem +1 GOPATH 各种不方便

[iwtbauh]

这正是我讨厌 golang 的原因

必须静态连接，无法动态连接，为什么不能拨出来一个 libgolang.so ？如果系统中都是 golang 编写的程序，那得多浪费多少内存啊（同样的代码被数次加载到主存），你们发现没有，Google 的软件从来都是不管内存占用的 。

由于静态连接，导致无法使用 dlopen 等方法动态载入共享对象到内存。这对于希望在运行时动态加载二进制插件的程序是灾难性的。

由于静态连接，程序体积膨胀。

由于没有共享库机制，使二进制代码重用非常困难。

所以，我站 rust，不知道比 golang 高到哪里去了

[auin]

@iwtbauh #18 Java 我觉得还是场景问题，rust 和 golang 主战场并不一样。

[wentaoliang]

1.go 最后打包出来的可执行文件永远只有一个吗？有没有可能根据我的业务逻辑分别打包成几大块（例如：main、lib1、lib2 ），虽然好像这样意义也不大？

go 是静态编译， 所以是只有一个；但是也是可以采取动态编译的，如果你想根据业务逻辑分别打包还是比较难受的，建议还是静态编译。

2.写代码前需要设置 GOPATH。假如我有多个项目的话 GOPATH 是不是也得设置多个？那 GOBIN 好像只能设置一个啊。
对于多个项目你们是怎么弄的？还是 GOPATH 只有一个，在 src 下建不同的文件夹来区分项目吗，最后通过 go build 指定路径来打包吗？

1.9 版本之前确实 GOPATH 比较蛋疼， 要么设置一个 GOPATH， 所有项目都放一起；要么每个项目设置一个 GOPATH， 写个 shell 放项目下， 然后开发哪个项目就运行下切换下 GOPATH， 但是 1.9 版本引入了 go mod， 可以摆脱对 GOPATH 对依赖，也是未来 go 的官方解决方案， 推荐使用 go mod


3.假如我现在打包出来一个文件为 main，在 Linux 执行它的方式为./main （是这样的吧）

对的

4.go 有没有类似 Node.js 下的 pm2 这种守护进程管理工具？ 你们在服务器上怎么部署的 go ？总不可能是 nohup 吧

supervisord 可以监控进程

[fcten]

编译成单个二进制文件不符合 unix KISS 的原则。不过 KISS 是一个对开发者友好，而使用者体验很差的原则……

[wentaoliang]

顺便有说静态编译体积大， 我倒感觉浪费一点体积换取运维的便利性还是值得的， 如果真的觉得太大，可以考虑 upx 套壳压缩

[TinyKube]

还是要区分场景，Go 在云原生+微服务场景还是能解决很多问题的

[miniliuke]

golang 有插件(动态库)的吧，仅 linux 可用，虽然没怎么用过

[alichen]

加上 cgo 的话交叉编译就难过了

[iwtbauh]

@liuxey #19

java 不一样，主流的 java 实现是编译为 java 字节码而不是二进制文件。gcj 我没用过就不说了。

golang 的诞生不就是为了取代 c++ 来“提高内存安全”,“提高编程效率”的吗，rust 也是在各方面和 c++ 比。可以说主战场是差不多的。现在好了，c++的某些重要优势被 golang 抛弃了，依赖这些优势的 c++程序员怎么可能转去 golang。

[trait]

@iwtbauh rust 和 go 没有可比性，go 的对标 C# java 更多

[barbery]

就是这么方便啊，进程监控用 supervisor 啊

[jsfaint]

Go 可以分成多个模块的~~
有几种方案
1. 动态库方案，编译成 C 的 shared library，这样可以用 C 或者其他语言去做交互
2. 用 Go 自带 plugin 去编译成特殊的动态库
3. 多个 binary 通过 rpc 通讯

[circleee]

插眼

[zicla]

插眼

[iwtbauh]

@trait #27

“ golang 对标 c#” 来源请求

在我看来，golang，rust 都是设计者讨厌 c++而诞生的。目的是做一个性能达到 c++并且简化编程、提升安全性的语言。所以是同一类的。

[gamexg]

如果用了 cgo(内嵌了 c 代码) 交叉编译就比较麻烦了，需要 c 的那一套交叉编译方式。

另外也不是完全的不依赖，很多情况下还会依赖于 glibc。

[nekoyaki]

go 程序是可以编译成动态链接的共享库的，好像只在 linux 平台上可以，没试过别的平台。
另外 go 可以被编译为 c 风格的库，嵌入到 python/ruby 里。

[rockyou12]

@trait go 最开始确实是为了取代 c++，他们觉得 c++特性太多完全是 shit。但对 java、c#，特别是在基础设施这层造成冲击完全是出乎设计者的意料。

[trait]

@iwtbauh golang gc 系只可能跟 C# java 争市场，怎么可能跟 c/c++对比，google 重新定义系统语言概念，并不是所有人会认同

[janxin]

1. 做动态库比较麻烦还不好用，还不如单体应用，太大了就拆分走微服务间调用的模式
2. GOPATH 单个就行，走 go mod 或者 vendor 解决多版本间冲突问题；当然空间够用的话多个也不错
3. ...
4. systemd 是 Linux 下系统自带的进程守护方案，什么都不需要装，没什么不好的地方

[trait]

@rockyou12 完全不是取代 C++，当然 google 重新定义的“系统语言”环境下无可厚非，而是 Rob 亲口 go 方便大学毕业生，显然他们不信任这些新人的内存管理水平，把 C/C++的内存管理权限从菜鸟手中剥夺了，直接放到语言层面。没什么出乎意料的，带 gc 的“系统语言"确不能对内存作出精确管理压榨性能，去跟 gc 系抢饭吃是必然

[lideshun123]

@daigouspy .net 还有人用吗

[keniusahdu]

怎么这么多"插眼"的? v2 不是不让水么.

[AlphaTr]

1. Go 有 Plugin 机制，可以编译多个，也支持 -buildmode=shared 编译，但还是觉得编译为一个文件最方便；

2. Go 1.11 以上支持 go mod，开发上现在基本不用关心 gopath 了;

3. 编译的就是可执行文件，同样可以放在 PATH 目录内执行；

4. systemd 管理；

[CRVV]

@trait
“不信任这些新人的内存管理水平”

1. 不是信任不信任的问题，而是手动管理内存要付出更多的开发成本，很多项目不乐意花这个钱

2. 你好像把内存管理想得太简单了。在某些情况下，即使是老人也一样管理不好内存，或者手动管理内存的运行时开销不比 GC 小
比如
https://software.intel.com/en-us/forums/intel-moderncode-for-parallel-architectures/topic/295279

[Narcissu5]

ahead of time 编译，java 的 graal 也可以做到。不过应该没有运行时优化，猜的哈

[trait]

@CRVV
1. 把新手与内存管理隔绝降低开发成本就是 go 做的，需要精确控制的场景 gc 省下的那点钱跟性能等优势比起来不值一提
2. 我从没把内存想简单，新手就是水平太差，没能力管理内存，所谓的老手真的是老手？至于你发那帖，读完主楼和回复并没发现 gc 在内存管理上有什么过人之处

[dany813]

插眼

[ixiaohei]

@iwtbauh 程序体积大占用内存就一定多么？系统都是分页的，实际占用内存很小的，很多都在 swap 上。另外内存相对于 cpu 真心便宜的；全部静态连接在一起，反而是 go 跨平台最大优势，没有依赖，那种裁剪的 linux，和嵌入式 arm 上直接拖过去就可以跑，爽的不要不要的。

[limers]

插眼

[isCyan]

可是 golang 内存占用还是很小

[dacapoday]

@iwtbauh #18 现实情况是内存和存储空间成本 远低于 部署成本，又不是嵌入式环境，可执行文件总比各种多媒体资源文件体积小吧。而现实中各种 库依赖 发行版依赖 版本不兼容，依然需要打包依赖配置依赖路径，搭建编译部署环境费时费力，而且相关知识不易传授培训给非开发人员，不然 docker 也不会火。

[qieqie]

可以链接 C 的 shared library，也可以 build，但不是主流，go 的主流库都是源代码 distribute 的。
cgo 交叉编译对熟悉 gcc/g++的其实也没有麻烦到哪里去。用 pkg-config 管理好依赖，就多一步 CGO_ENABLED=1 CC=... CXX=...
上面还有说体积 /内存的，源码依赖的 go build 只会编译可以被执行到的代码，而通过 cgo 链接二进制库的你同样可以使用-Wl,--gc-sections 这样的 linker flag。

[Mrun]

go 跨平台编译时优势

[ptyfork]

@heimeil

> 另外 Golang 不是不用装环境，而是环境都在编译的二进制文件里面了，你会发现 Go 编译出来的二进制比.NET 之类的大太多了。

你这比较的时候，.Net 还是要装环境啊， 不想装.net 环境，而是像 Go 一样把环境都打上，最后的安装包只会更大。

[iamwh1temark]

我感觉还好吧,有了 Docker 之后这个应该不算问题了.

[yuikns]

要求 disable cgo 才能不需要 runtime。
一般我输出 linux 然后丢 docker 里面。一个 image 几 M 到几十 M，特好用。

[neoblackcap]

@iwtbauh Google 内部用 golang 又不多，C++依然是他们的头号语言，紧接着是 Java，Golang 怎么样对他们又没有什么影响

[iwtbauh]

@ixiaohei #46

请注意看，我没说第 2 条和第 4 条有因果关系吧。（我没说是程序体积大导致内存占用大啊）

占用内存大是因为“重复的代码被多次载入主存”，因为如果我假设标准库 libgolang .so 文件（等）存在，那么 libgolang .so 只会载入主存一次，这就是操作系统的 cow 机制，即使系统中运行数个 golang 程序。然而因为静态编译，这部分代码只能重复载入主存。（而这一部分还不小）

换入磁盘在大部分情况下对于解决这个问题的意义不大（并不是说 swap 无用，只是对这种情况是用处不大的），因为这些程序执行 libgolang .so 中的代码（或访问数据）时，必须再从磁盘上重新换回到主存，这样只会导致系统缺页中断增多，拖慢系统性能。

另外，你也说了嵌入式系统，在嵌入式系统中更应该减少外存和主存的占用。

@dacapoday #49

注意看，我说的前提是“如果系统中大部分程序都是 golang ”。毕竟 golang 设计者差不多就是这样想的。原因见上。

[iwtbauh]

@neoblackcap #55

其实也不少，比如 dl.google.com 这个

主要是 Google 太富了，在硬件上使劲氪金，导致我等穷人非常难受。

chrome 内存泄漏因为内存大看不出来

chromium （还是 aosp ？） 的工具链直接丢进 git 里面简直疯了

[kwanCCC]

rpm

[hlwjia]

是只有我不知道“插眼”什么意思吗

[pursuer]

@iwtbauh 我个人觉得除了静态编译的内存消耗，动态加载目前也还不太行，plugin 一直不支持 windows，而且一共就实现了两个函数，Open 和 Lookup，用起来手感和 dlopen 和 dlsym 差不多，相比较我可能更喜欢 Windows COM 里 CoCreateInstance,QueryInterface 那套（但用 C++写会比较痛苦）或者 Java 的 ClassLoader 这样的

[plqws]

如果没有 分发单文件 binary / 无痛跨平台 这两个需求而去选 go 完全就是吃饱了撑着，所以那群需要动态链接的还是老老实实用其他语言吧

[ixiaohei]

@iwtbauh 静态链接讲的很有道理；另外嵌入式设备上令人烦躁的都是缺少依赖；特别是那种裁剪的嵌入式上，更令人头大；没有正常 linux 发行版有包管理工具...

[caryqy]

@hlwjia 收藏 /标记 /mark

[neoblackcap]

@iwtbauh 是的，因为这个是很久以前 Google 发文说的，不过除此以外我非常怀疑他们内部还有什么大系统是用 Golang 写的。就算现在吹那么多的容器编排，Borg 也还是用 C++写的。我对 Golang 在 Google 内部有很大的占比表示怀疑。

[suley]

@ixiaohei 如果经过剪裁的嵌入式，恐怕动态链接更需要了，毕竟静态链接编译出来的一般都比动态链接的大不少，嵌入式空间有限，捉襟见肘。

[pathbox]

go mac 下交叉编译放 centOS 上有 net 包的 bug 还是老老实实在 Linux 编译放生产

pm2 挺好用的。一般直接用于 go 项目 基本够用

一个 gopath。其他项目做软链接过去

[hlwjia]

@caryqy 谢谢，我大概能猜到是类似的意思。但是插眼和 mark 收藏是怎么关联起来的？

[0xCNSumi]

@hlwjia 插眼来自于游戏英雄联盟(lol)中的放置控制守卫，放置后可以在一段时间或者永久的或者放置区域的视野，引申到收藏可以关注帖子的动态

[hlwjia]

@gocnsumi 哈哈 谢谢详细地解释，不玩游戏的我是怎么都不会想到这个

[dabaibai]

相当方便好用

[ixiaohei]

@suley 现在嵌入式设备硬件配置很好的。

[Muninn]

我用了好几年 golang 了，应该能提供更好的答案，回答一下吧。

1. https://github.com/spf13/cobra
2. https://colobu.com/2018/08/27/learn-go-module/ 最新的 golang 不用了
3. 是 一般推荐用绝对路径，更一般的见 4
4. docker 研究一下不吃亏。golang 生态大多都用的容器，毕竟 docker 是 golang 的明星应用。

[Muninn]

补充，学 golang 别用 beego。会被带沟里。
web 框架的话推荐 gin 或者 echo

[wenzhoou]

只有我喜欢静态编译吗。反正编译之后也不太大。(当然体积能缩小一下就更开心了) 确实用了 docker 就能感觉出来 golang 的好处了。

[imherer]

@giuem
@wentaoliang
@janxin
@AlphaTr
@Muninn

问下大佬，看了你们的回复然后今天用了下 go mod。 我发用 go mod 方式的话不管是 go run 还会 go build 很慢，会花很长时间。
我就只引入了 github.com/astaxie/beego 这个
直接在 GOPATH 下无论是 go run main.go 或者是 go build 很快（ 1s 不到就完成了），但是用 go mod 的话初步估计至少 30s 以上

是什么原因呢？大佬们有遇到同样的情况吗？

[janxin]

@imherer 因为依赖会下载一遍，和你没用的时候的依赖管理方式不一样

[blless]

动态链接多了就知道恶心了…不小心错一个版本直接系统都炸了，没有特殊需求我选择 go

[imherer]

@janxin 我用 time go build -v 看了下过程，第一条信息就是 Fetching https://golang.org/x/crypto?go-get=1
这个没梯子肯定拉不了，但是我在 go.mod 里已经用 github 的源把它给 replace 掉了，为什么还要拉呢

发现就是这个一直卡到 timeout 然后就 build 成功了

[jjx]

python 装环境哪里有你们说的那么可怕

如果是 gfw 问题的, aliyun 有 pypi 镜像


虽然我也用 go, 但 python 环境装一次后面的更新很小, go 每次要传 10 多 m 的文件

关键如果用 cgo 等, 交叉编译还是用不了的

[jjx]

补充一下, go 传文件更新还要解决文件锁定问题, python 都可以直接覆盖

[blless]

@jjx go 的依赖更新就是 git 另外 python 跟 go 没有可比性

[mmdsun]

@lideshun123 . Net 用得少不过还是有人用的。微信支付清算网关，.net core。腾讯游戏平台，Service Fabric

[janxin]

@imherer 没有私有仓库我推荐使用 https://goproxy.io

[imherer]

@janxin 谢谢，我试试

[icylord]

golang 写的东西是不是没法闭源？

[sammo]

又怕炸
又想要动态链接 节省载入内存
被链接的库又无法保证每一个稳定的新版本可以向前兼容
又还幻想瞎链也不炸

你叫我很难办阿

[Muninn]

@imherer 网络问题 你如果有一个很快的梯子的话，就不是问题了。
因为用了 go mod 后，每次 test 或者 build 都会检查一遍依赖。gopath 模式下不会联网。

而且你需要弄成 http proxy 才能对命令行起作用。

用 vscode 的话，也要在 http proxy 在环境变量时的终端里用 code 命令启动 vscode
或者在 vscode 里配置梯子。

[xrlin]

跨平台交叉编译+单文件部署是我最青睐 golang 的一点，自己写点小项目部署很方便，资源占用还小，还有因为没有各种特性，浏览器装上 sourcegraph 就可以像 ide 一样浏览代码。

[realpg]

@BXIA #8
就是静态链接
最常见的类似东西就是 windows 的程序大量采用静态链接，就算动态链接也把一系列动态链接库放到自己目录下自己独占避免系统里面包含的版本不对问题

linux 系则是大部分依赖系统内的公用库，造成了直接拷二进制各种跨机器都费劲的问题，内核版本，各种库版本的不一致

[imherer]

@Muninn 嗯，是的。我只是奇怪我在 go.mod 里已经把源 replace 到 GitHub 上的源了，为什么还会去拉取。
不过用了 janxin 给的方法直接改 GOPROXY 更简单

[RqPS6rhmP3Nyn3Tm]

@realpg 我知道他是静态链接，但是如此方便跨架构编译给我造成了巨大的冲击
交叉编译个稍微大点的 C 项目就很让我绝望了（依赖问题太麻烦，就算静态链接还是很痛苦），go 在这方面上是真的牛逼

[TinyKube]

@imherer 这个代理似乎没有同步更新，个人依赖的 Kubernetes 相关的依赖都很久，设置下 http 代理就可以直接拉