休息的第二天，被通知下周一复工

2020年2月28日 周五 雨

春雨贵如油，今天有段时间下得好大。

阳台不是矩形的，所以放窗外的植物还有淋不到雨的。

今天接收的信息量好大，原本以为还能休2周，突然下周一就要来上班了。不过下半周却又不一定。

这下离线的任务又不能算离线了，反反复复，极大削弱了计划性。

接触Go-micro的时候，还查到了go-kit，不过前者是微服务框架，后者的定位是工具集。

有人测评Go-micro的性能不大好，后来看文档，有描述“性能不是目前最关注的问题”。性能其实是一个相对的问题，golang在诞生了gin、iris等高性能框架的同时，目前我不知道怎么理解golang的“性能不好”。同时因为“协程”的概念，又不能拿同一伪代码逻辑去和其他语言比较性能。

不过，即使真的性能不好，这对我目前而言也并不是一个问题。因为对于企业级应用而言，性能并不是主要瓶颈。瓶颈在于业务复杂、多变，以及开发效率、规范上。

刚毕业那会儿，“企业级”恰恰表示了规模的庞大，随着互联网迅猛发展，大量“企业级”应用无论是在规模、负载、集群数量上，都远远不如互联网应用。

即便是现在，我还能看到很多单体应用正在被建设，集群最多两台，这还算是相对比较大的。不过服务器规格大多是顶好的。

密密麻麻的企业级应用已经成为低成本软件的代名词，多年的代码沉淀使很多辞职单干的人也能完成某个小业务域的单体应用的交付。

随之而来的，是服务治理的迫切需要。已经有很多人在焦虑这些信息孤岛在建设完毕后该怎么面对它们了，其实使用和运维的现状可能比他们想象得更糟。

今天B站上偶然看到一个关于2020年开发编程趋势的视频，里面有一个看发际线就很资深的胖纸，提到了go语言，说是一个被低估的语言。这一点深感认同，但之所以被低估，可能也和生态有关。前年公司买了个一个Java的办公系统，去年一直在实施。部署庞大，占用资源很多，高配的服务器都被用卡了。开发效率极低，内部错综复杂，而且还是在二次开发并不需要接触核心代码的前提下。不过，所以非实施时定制开发的功能，即产品自带的功能，倒是相当完善。复制来，就能成熟的使用，这是golang现在完全比不了的。

今天还发现自己贪多嚼不烂的一面，可能和早期开发经历有关，调研->设计->开发->部署->运维，一条龙服务，都不需要第二个人操心。那么现在公司期望从二次开发向自主开发转型（当然这个决定是按趋势来的，并不是按优势来的），又在疫情期间出现了互联网、微信小程序应用的需求，个人在这两天同时（也是浅尝辄止）学习了前端、微信小程序、golang微服务的一点点入门知识。结果当然可想而知，什么都没做成，什么都只懂了一点。按节奏，现在我处于最适合做键盘侠的阶段：做了而又没做成，正好是应该装懂并把没做成的问题甩锅回去的时候。

既然今天被通知下周一上班，那么就还剩两天互联网时间了，这下又得紧凑地规划时间了。