为什么Go语言能在中国这么火？

当年 写 CGI , php 打败了 perl , 无他, 在 web 的 CGI 时代, php 学习成本低. 同样 , 2018年 vueJS 与 react 相比更为"火", 无他, vuejs 学习成本低.

go 相对于 java 也有点类似, 学习成本低. 好几年前, 游戏开发, erlang 在后台来说, 那是中坚力量, 而这两年, go 作为游戏开发的后台, 也不少了吧. 也一样, 相对 erlang , golang 学习成本 低.

1.2 "其实有多大差别啊", 对头, 只是一些小差别, (业务逻辑)伪代码相同情况下, go 代码简单,易读(易维护)

有答主说了 "其实有多大差别啊，搬砖而已" ---------> 我同意这句话, 但也不完全同意这句话:

同意的地方是, 对于传统业务, 尤其是企业级应用或业务, 以及有明确终端用户的业务来说, 在不考虑量级情况下, 业务实现流程与处理约束有相似之处, 开发实现也有相类似之处.

所以, 不同语言/架构开发来说, 差别不明显, 比如说, 用户管理 / 资费交割/ 业务鉴权 / 商品管理都差不太多( 这里没说内容管理, 内容差别太大, 但商品管理差别不会大) .

这里说的业务量级, 指的是用户总量, 并发量, 业务运行随时间累积的数据总量与有效数据集总量

( 比如大型网店, 下架后的商品数据, 对于网店销售来说, 属于失效数据集, 但对于销售行为分析等大数据估算来说, 是有效数据集)

对于这些, 不同语言开发, 就是搬砖.

那搬砖有什么不同呢, 无他, 人不同罢了:

• 每个人都趋向于选择自己熟悉的工具.
• 研发经理/产品经理趋向于容易招聘, 按量交货(坑少的), 而且薪水还低的人

1.3 "并没有颠覆性解决问题", 是的, go 只是尝试着, 简单,轻松的去解决,没有黑魔法,很少语法糖,甚至,没有泛型(也许,将来会有...)

有朋友说了, "golang并没有颠覆性解决问题", 没错, go 能解决的问题, java 也能,甚至解决得更好. --------> 所以, 只是同样的"搬砖而..."

但, 砖与砖还是有差别. 对于开发量在 100人月上下的项目, 同样的业务管理( 是的, 我带队实施过, 设计用户总量10万计, 每月新增用户量3000到10000, 每天开机量90%, 业务模型/技术架构一样, 这里的技术架构, 指的是业务子系统划分/ 中间件/数据库模型基本一样, 尤其是各子系统/各业务单元之间的接口完全一致, 见注1), go 实现要比 java , 在部署/运维上, 成本要降很多.

同样是本科毕业2年内的开发人员, go 只要基本业务测试通过, 性能与稳定性, 比 java 要好. 至于说, 开发成本( 按人月计) , 也降不少.

注: 在上述3 / 4 两条, 说到的项目中, 分别是视频业务与金融业务, 我是项目经理/产品经理这一类角色, 除了需求规格说明书( MRD/RSD), 系统总体概要设计说明书( system HLD ) , 子系统概要设计规格说明书( subsystem HLD) , 接口定义文档( ICD ) 以外, 我不写代码.

但是, 如果是 100人月以上的项目, 开发人员在30人以上, 说实话, 这要看开发团队是什么样的人员构成吧. 这涉及到项目的长期维护与更迭换代, 以及人员招聘, 薪水开销等.

所以, 基本还是选择容易招人的开发语言( 与开发语言对应的成熟 架框/库). java 挺好招人. go 就不要选择了( 深圳宝安某几个公司, 招 go 开发人员, 招聘信息处处发, 都发了快一年了, 还在四处挂着招人)

几年前, 快递员在小区的手机取件的快递箱, 深圳某大公司以 java 为主, 快递箱内有一台 PC, 通道走2G无线模块, 开箱时间为3秒(2G通道基本通畅的最坏情况). 我在的技术小组作为技术顾问, 作出的优化是, 把 服务器端到快递箱内 PC 的通讯, 从原生 java RPC 换成 爱立信 ICE 作为中间件的 java RPC , 开箱时间, 缩短到 1.3秒(2G通道基本通畅的最坏情况).

ICE 是什么, 爱立信20多年前的 c++ 中间件啊, 20多年来几乎没什么大改进, 性能依然稳定而强悍.

--------> 所以, 砖与砖是不同的. c++ /erlang / hackell 挺重, 学习曲线陡上天, java 砖稍重一些, go 砖轻一些, python 轻灵, 而 Javascript ( NodeJS ) , 看看 TJ 的经历就知道了.

1.4. go 很"火"(假像...), 但绝不是万金油

我想说的意思, go 有特定领域, 有优秀的地方, 但绝不是万金油.

看起来 go 在中国挺火, 这只是个假像. 尤其是 go 还太年轻, 成熟的通用库或架框很少, 很多应用得自己撸. -----> 这个, 看看 uber 就知道了, 自己撸了不少, 还开源了, 例如 uber 开源了自己撸的 zap 日志库, 性能强悍.

相对来说, java 的库与框架, 那是陈年老酒, 好得不得了. 还有 python, python 再优雅再易学, 终究还是那些神级的库让 python 开发快人一步, 比如 sqlalchemy

事实上 go 在中国或世界范围, 并没有那么火, 但对比 java , go 也并没有那么不堪 .

2 一些建议, 别转到 go 来, 兼修就好

2.1 大可不必从 java /python /nodeJs 转 go

想对刚毕业3年左右的朋友说, 大可不必从 java 转 go , 而是应该以 java 为主( 战场上的 ak47 ,通杀) , 同时用 go 作某些部件的效率开发工具( 随身的长狙, 某些领域一枪见血, 一招制敌) . 如果还有兴趣, python / haskell / sql 也好好玩一把. ( 对的, 没错, 说的就是 sql , 尤其是 plsql 这一类数据库存储过程编程与 sql query 优化)

2.2 掌握如何编程, 比掌握一门开发语言更重要

这算是卖身说法, "王老"卖瓜吗? ( 绝对是!............) 我曾在 UTstarcom 的 IPTV/OTT 事务部 SA/SE 团队呆过, 8年, 历经IPTV解决方案SE/STB 解决方案SE 以及部分业务子系统 SA /播控系统产品线 SE /播控产品线 release SE ( 相当于产品线经理) , 后来拿了 package 出来了

说到开发语言, 个人在商用项目中用过的:

• perl ( 搜索 perlchina + tsingson 就知道我的黑历史)
• c/c++ ( mobile MSN / MSN中国社区)
• PHP, 宇宙第一开发语言, 在某,某,某,某...(都是UTstarcom 的 RollingStream 同一个平台下)用过, 这平台合同标的最大的一个,两个亿吧...
• Javascript ( 不管是前端还是后端, 都写过一丢丢)
• java / java / java ( 企业应用,金融平台, 广电/电信的业务平台RollingStream 的BOSS / 播控产品线/业务导航子系统...,公安交警RFID存储检索平台...)

离开外企后, 在深圳某机顶盒厂商作过某某运营平台的产品经理( 兼技术总工) , 视频播放平台开发, c++ (mpeg4与.264 .265 推流) / Python 为主, 这个 OTT 平台很成功( 试商用成功后, 我离开了)

在这个项目过程中, 除了项目启动期3个月, 写过一些业务网元的 prototype 作为演示外, 我几乎没写过在商用部署中的代码( 应该,不超过 1000行), 时间宽泛,我就花了两个月自学了 go, 先是写了一些命令行小工具,再写了一些tcp/udp 的小工具, 流式传输大文件, 测试网络抖动/网速采集....

3年后, 因为该某某平台很成功, 我也就山寨了自己一把,全新设计, 重写代码, 用 go 重新实现并商用成功(当然, 商用还在进行中) .

我想说的是, 这个平台, 除了一些"小差别", 用 java 也差不多

2.3 小差别? 是哪些小差别让我选择 go 作为现在的主力开发语言

小差别, 真的看起来很小:

1. 部署, 编译可执行文件, 加个配置文件说明文档, 接口验证服务健康运行的接口文档,一起打个包, 就丢给运维 copy 后运行, 好了,结束.
2. 写代码, 编译, 测试( UT/LIT/SIT...), 关闭开发测试日志, 编译, 丢给运维, 好了, 结束
3. 运维报告说, 有用户连接不到服务, 查用户在线数量, 超5000 ( 这是内部限制值), 让运维开新服务器, 再 copy 一份运行, 好了, 以后同此办理, 别来烦我.... 运维说, OK, 你旅行去吧...

除了 c/c++ , 其他语言有这么轻松的进行部署吗? 当然有...

但是

我们的运维几个,很年轻, 管理几百台服务器,几十个网元服务, IDC机房在北美,新加坡,欧洲..., 还在上学

3. 一些有趣的补充

3.1 补1 , 一些开发文档的名称编写

有知友问到那几个英文缩写. 简单说一下, 英文缩写只是某些习惯用词罢了.

需求规格说明书( MRD/RSD)-------> 就是作需求分析写的文档, MRD 中指的是 marketing Requirement Documention 即是市场需求, 是写给甲方与售前的, 目标是确认需求细节. 一般来说, 大公司技术投标附带的那个技术需求细节说明文档, 可视为 MRD.

RSD------> 是 Requirement Specification Documention , 说白了就是 use case 的集合, 是写给开发人员与测试人员看的

系统总体概要设计说明书( system HLD )就是系统级的 High Level Design Documention , 俗称系统架构吧, 说简单一点就是划分子系统, 确定各子系统之间的分工界定, 子系统概要设计规格说明书( subsystem HLD) , 就是个类似的玩意儿.

接口定义文档( ICD )英文是 Interface Control Document , 直译英文就是接口控制文档, 这个是老生常谈了, 开发与测试中依赖最多的文档. 例如 定义 web 服务器与 web 浏览器之间的 http 1.1 接口文档, RFC 7230 ~ 7235 , 当然了, 这类文档, 也可以叫 protocol specification 某某协议规范说明文档

3.2 补2, 软件架构, 什么东西

有朋友问什么是软件架构, 架构师是作什么的? ( 甚至有朋友问, 曾经作为架构师/产品经理/技术总负责的你, 为什么可以不写代码) ?

是的, 我曾说过, 我作为架构师, 在工作中, 基本不写代码

(事实上也写过一些代码, 比如写验证解决思路或算法的 prototype 原型, 或一些应急使用的补丁或工具, 这些代码一般不会长期用在生产环境中)

不写代码的架构师, 不表示不懂写代码, 哈, 这就不引战了.

architecture 架构 , 这是个简单又复杂的玩意儿, 这里就简单说说, 帮助了解

3.2.1 程序设计, 是这样, 大约

这里先说一个简单的业务(multi-user todo-list) :

1. 用户在一个网站上用手机号注册/登录( 鉴权/授权)
2. 登录成功后, 在网站的web界面中, 给自己发延时( 在将来的一周内任意时间点上定点) 提醒的文本信息, 发到自己的手机短信上.
3. web界面可编辑发布的时间(当前时间开始, 将来的一周内任意时间点), 可编辑要发送的文本( 500汉字以内)
4. 每人等待发布的信息总量是 100条, 发送短信信息的送达时间点误差允许在2分钟内变动. 短信发布后, 从用户的等待发布列表中移到历史记录中, 并记录短信发布状态供web 界面历史查询即可.每个人的延时信息发布提供历史查询上限为1000条, 超过1000条的, 按时间 排序 删除旧信息.
5. 每个用户只能查看自己的信息, 无法查看他人信息.
6. 用户使用这个 todo-list 全免费.

好, 上面就是业务需求了, 当然, 也基本描述了业务流程和一些规格要求. 当然, 隐藏着的一个需求是, 要和电信服务商对接, 以提供手机短信发送服务. 这里, 我们简化为中国电信已经提供无限量的免费接口, 对接方式也是简单有保障. ( 这里简化掉了资费问题, 也简化掉了部署/运维/运营成本.......等问题)

上面的业务, 其实任何一个开发人员都可以实现.

不管如何设计, 如何实现, 基本都会达成目标. ---------------------------> 这个, 就叫程序设计了,

但不太合适叫架构设计.

3.2.2 架构设计

达成 1 ~ 6 条目标, 一般不称之为架构设计, 一台服务器就搞定

那什么情况下叫架构设计??

在实现上面业务功能基础上, 加上实现一下保障业务长期/大量的全流程实现要求, 就叫架构设计了:

7. multi-user todo-list 业务 要求支持并发1千万用户( TPS) , 支持用户总量1个亿, 支持用户范围为中国境内所有中国电信手机覆盖的省市县乡.
8. multi-user todo-list 业务 要求单个用户登录 / 操作自己的延时短信提醒的 web页面在 IE11 以上的同等浏览器中, 页面响应时间为400ms, (允许上下20%波动), 最慢响应时间不超过 1800ms ( 接近最慢响应影响用户, 不得超过并发用户总量的 5%)
9. 要求整个平台每年全平台完全中断服务时间累计底于30分钟, 按县市级行政区划分, 每个行政区年累计中断业务时间累计, 不得超过6小时.

要实现 1 ~ 9 需求(重点就是 7/8两条) , 需要架构设计的帮助.

而架构师, 解决的就是7/8/9三点, 在解决7/8/9 的基础上, 会对 1~~~6 的实现, 有很大的干预. 当然了, 附带的, 架构师在技术选型与整体设计中, 除了技术成熟度, 商用支持, 学习曲线, 经验积累与人才储备, 也会考虑开发团队的成本, 开发效率, 运维的成本与效率, 运营成本, 部署成本, 人员变更(包括外包) , 技术升级, 业务功能可扩展性, 与第三方对接的成本/效益.........

想清楚了 7/8/9 这类架构师面对的问题, uber 从 postgres 转到 mysql 的动因也就清楚了, 并不是 postgres 不优秀, 而是 mysql ( 真实原因是 mysql 的那个低层存储引擎) 更适合 uber 的超大存储/查询需要. 对于架构师来说, 单一部件的优秀, 开发高效或执行高效, 并不是唯一决定架构技术选型的因素.

4. 小结

附图一张, 2015年画的, 2.2章节提到的某某某平台, 给新人了解这个某某某平台的第一张图, 网元之间的分工界面:

.

.

.

能看到这里, 谢谢了, 小文有点啰嗦.

浪费您时间了.

以上,致敬, 祝愉快.

_

_

关于我

网名 tsingson (三明智, 江湖人称3爷)

原 ustarcom IPTV/OTT 事业部播控产品线技术架构湿/解决方案工程湿角色(8年), 自由职业者,

喜欢音乐(口琴,是第三/四/五届广东国际口琴嘉年华的主策划人之一), 摄影与越野,

喜欢 golang 语言 (商用项目中主要用 postgres + golang )

_

_

tsingson 写于中国深圳

小罗号口琴音乐中心, 2019/05/14