现在，越来越多的人了解 Go 言语，学习 Go 言语，越来越多的公司开端尝试选用 Go 言语。我也是一向在用 Go 作为服务端开发的主力言语，也了解过 Java 和 Spring 那一整套服务端开发体系，经常在想，Java 的这一套体系，在长时间的迭代下，技能沉积和事务覆盖现已十分完善，为什么 Go 还能锋芒毕露？让咱们所熟知。我知道，这中心存在一些从众效应，尤其是大公司的带头运用带来的引领作用，这为 Go 的声名带来了正向反应，使 Go 越来越被人们所了解。
抛开这些不谈，Go 自身也是有一些独门绝技，不然，它活不过开头，也就没有后续的正向反应作用了。我想，找出这些独门绝技绝不是无用的思维内讧，它能够让咱们这些 Gopher 找到未来发展的方向，确定未来学习的思路。
当咱们比较 Java 和 Go，咱们在比较什么？
2007 年 9 月，像往常一样，一位程序员正靠在椅子上喝着咖啡，他在等着自己提交的代码被编译完毕。这是一个巨大的工程，整个编译过程大约要继续 45 分钟，而他现在能做的也只有等待。这时，桌面上弹出的待办事项引起了他的注意，这是一次行将开端的宣讲会，几位 C++ 的搭档将宣讲有关行将发布的 C++11 的新特性，他自然不能错失，于是他脱离工位，坐到了会议室。
讲台上，担任宣讲的搭档神采飞扬，滔滔不绝地介绍着整整 35 项新特性。据他们透露，这还只是其间一部分。他抿了一口咖啡，细心地听着，右值引证，这是什么鬼？可变参数模版，听起来倒很 C++…… 忽然他感觉有些厌烦，C++真的需求这么多新特性吗？他想，有人说言语升级的更大成就不是添加了多少东西，而是减少了什么东西，虽然这话有些片面，但不失为有必定的道理。
他的思绪回到了几个月前，那时分他在宣讲一个由他发明的言语 Newsqueak，这个言语运用了 CSP 并发模型，这是一个很优雅的模型，他想把它参加到 C++ 中，可总是没办法和谐的很完美，问题出在哪？好像 C++ 过分杂乱了，他也不敢说自己彻底理解了 C++。
讲台上的声音忽然中止了，这打断了他的思绪。另一位搭档上来介绍一个新特性：原子类型。这是言语层面支持的原子性，经过硬件来保证的原子性。听到这儿，他忽然握紧了自己的咖啡杯，是的，问题出在这儿，将这样一组微观界说的细节放入一个现已不堪重负的类型体系中，是短视的。由于底层的硬件在未来十年或许会产生天翻地覆的改变，将言语与当下的硬件紧密结合是不明智的。
他应该规划一门新言语，一门面向未来的言语，它精约、易懂、运用 CSP 模型。这个主意使他热血汹涌，他想着会议一完毕就去和坐在他周围的 Robert Griesemer 交流这个主意。当主持人宣告会议完毕时，他刻不容缓的走回办公桌，看到桌上自己的电脑现已提示编译完结，耗时 45 分钟。
对了，他想，这个新言语还要有个功用，那便是编译快。
这篇小短文不是我的臆造，而是 Go 言语的作者之一 Rob Pike 的实在经历，虽然经过了艺术加工，但咱们也能够看到文中主角敏锐的判断力。是的，十年过去了，软件的运转环境产生了天翻地覆的改变，原先你能够切当地说，我的程序运转在什么架构 CPU、几 G 内存的机器上。现在，容器和 Kubernetes 的革新现已让你答复不了这个问题。它或许这一秒运转在这台机器，下一秒被调度到其它机器；乃至机器自身，也或许是虚拟机、或者虚拟机虚拟出来的虚拟机。硬件现已被笼统，变成了一个被称作“云”的庞然大物。
让咱们从 Go 诞生的故事回到当下，Java 言语依旧是服务端名副其实的王者，而 Go 言语会是那颗闪着银白色寒芒的天狼星吗？许多人在发问，也有许多人从语法、结构、面向对象和面向接口……层面去对比，去剖析。
我也一向在考虑这个问题，我现在的答案是，会，但有前提条件。
假如咱们一向从语法、结构、面向对象的层面去对比，那么永久也不会有结果，“术”的层面总是各有优劣的，咱们要一同往更深一层次去剖析。
于 Java 而言，中心是 Spring，以及那句名言：“一切皆对象”。许多 Java 程序员最爱干的，应该便是“笼统”这个事儿，所以如何合理的规划和笼统，让代码可读，成为了衡量 Java 程序员最重要的指标之一。从公司的视点看，日积月累的笼统，也让内部的结构越来越杂乱，功用越来越多，乃至最终，这个结构自身都能够拿去 2B 的商场去卖个好价钱。结构，也成为了Java最大的护城河，许多刚从 Java 转 Go 的程序员都会问一个心爱的问题：“Go 有类似于 Java 这种 Spring 的结构吗？”
请咱们等等，请咱们停下来想想，假如 Go 有这种结构，那么转 Go 的含义是什么呢？Go 的 CSP 模型这么吸引人，Java 难道就没有吗？ Java 曾经不行快，现在还不行快吗？容器镜像大？能大多少，这点差距对你的事务真的很重要吗？
假如这些问题无法答复，那么转 Go 只不过是一次内讧，或者是或人的一次 KPI 举动。
事实上，我认为，假如不是一样东西的横空出世，Go 是不或许替代 Java 的，你不或许在竞赛对手的优势范畴打败它。
这样东西叫微服务（Microservices），谈到它，咱们应该很不陌生。微服务嘛，那就得拆，把服务离散，怎么拆呢？网上搜，有人说：“这么办，单体服务，咱们竖着给它一刀，把它按事务拆分，这叫 SOA 架构；再横着给它一刀，把它按代码层次拆分，这叫水平分层架构。好了！这便是微服务了。”当年我看到这句话，豁然开朗，本来，SOA+水平分层便是微服务，简略，这就把单体服务按在手术台上大卸八块。
等等，各位，咱们仍是要停下来想想，就这么一个服务拆分方案，有必要搞得这么火吗？
有人又说，那是由于你切的不对，你得依照 DDD（范畴驱动规划） 的规律来切。
让咱们先放下手中的手术刀，回顾一下微服务的界说：“微服务是一种经过多个小型服务组合来构建单个使用的架构风格，这些服务围绕事务才干而非特定的技能标准来构建。各个服务能够选用不同的编程言语，不同的数据存储技能，运转在不同的进程之中。服务采纳轻量级的通信机制和自动化的布置机制完成通信与运维。”这个界说到底在说什么？
不同言语？不同进程？轻量通信？那我 Java 的 Spring 怎么办，其他言语纷歧定有。我结构封装的通信不或许轻量啊，要完成那么多功用：负载均衡、限流、健康检查、监控等等等等，难道我每个言语都完成一遍吗？
想到这儿，咱们回到本节的开头之问，咱们的比较，实质并不是 Java 和 Go 之争，而是以 SDK、Libary为代表的结构思维，和微服务代表的服务思维之争。这是一场思维上的革命，在微服务看来，整个体系是由一个一个的服务组成的，服务和服务之间相互解耦，各自完结自己的职责，共同对外供给服务。在这个国际里，不存在一种上帝般的结构，一切服务都要接入，都要崇奉。
失去了结构的捆绑，各服务能够自在迭代，自在挑选言语，自在替换，自在弹性。容器和 Kubernetes 会保证这些服务的有序调度，ServicesMesh 会保证负载均衡、限流、健康检查、监控等一系列事项的正确运转。
因此，正是由于现在流行的这些技能，催生了微服务的土壤。这是一种思维观念的改变，从重结构，重规划的思维，改变为重服务，重Sidecar的思维，而咱们正处在这一年代的革新之中，Java社区、Java的保护者，这些国际尖端的聪明人，他们何尝不知道，Java也在改变，也想适应这个年代的改变，变得轻量、快速。但有个人告知过咱们，看待事物要辩证的看待，当年Java搭建的护城河，那些让它登顶的技能，相同也是它现在要改变所碰到的最大壁垒。
在这个年代的改变中，Go言语成为了其间的基石，不是由于它规划的多么精妙（事实上，比它规划的精妙的言语多的是），而是由于它是其间一些技能的关键言语。
编程前史学
我一向在想，为什么咱们的大学没有这样一门学科，从国际第一台计算机埃尼阿克开端，编程经历了多少令人心醉的故事，衍生出了多少技能分支。其间一些分支永久也不会有人提交了，它输在了年代的竞赛中；其间一些分支被合并到主线，成为了咱们的主流技能。或许是编程技能发展的太快，比较回溯过去，咱们更向往未来的提交。
但回溯真的不仅仅是一种怀念，它让咱们了解到一个技能的由来，而不仅仅是经过它的官网简介，咱们要知道它为什么呈现，要处理什么问题。经过前史的经历，咱们能够总结出，它能不能处理这些问题。
是的，我现已从事编程5年了，也经常听到这些问题，有人说，技能更新换代太快，学不动了；有人说，技能没什么用的，不要沉迷技能；有人说，咱们要学习底层技能，才不会被年代筛选。
各位读者还记得自己第一次运转成功的喜悦吗？为什么，为什么越到后面越失望了呢？为什么35岁筛选论总是围绕着技能人？
假如在技能范围内找问题的答案，永久也不会有答案。学习更多的技能防止筛选？假如你学的技能自身就要被年代筛选，这和49参加国军有什么区别。花心思学习底层技能？各位假如是编程新手，我想说，现在商场上这种岗位十分少，专门为这些底层，如操作体系、算法、网络规划的专门岗位，即便有，要求也十分高。你能够让底层技能作为你的优势科目，但千万不能想着光靠它吃饭。
必定要跳出技能看技能。实质上，技能便是一种东西，谁的东西？商场、公司的东西。它们用技能为自己盈余，用技能制作护城河，打败竞赛对手。虽然和“技能改变国际”的标语纷歧样，咱们技能人好像是年代的弄潮儿，其实不是，从古至今，盈余才是年代的实质。技能能够很重要，也能够很不重要，取决于它们用技能作为自己的中心盈余点仍是边际辅助事务。
请先不要去痛骂资本，痛骂它们是金钱的奴隶。辩证地想一想，正是由于它们想盈余，它们挑选了先进的技能，技能才干改变国际。
那么，未来它们需求什么样的技能，学了这些技能的人就不会被筛选，反而会成为自己的中心竞赛力。
怎么样，以上是不是一句废话，你或许会说，我要是知道未来它们会用什么技能，我还干技能干什么，我去买彩票不好吗？稍安勿躁，各位：咱们虽然不是东方朔，可是咱们能够了解前史，去考虑“一门技能的发明原因是什么？被挑选的原因是什么？它在那个前史条件下被挑选，在现在的环境下还会被挑选吗？或者是被筛选?我该不该挑选学习这门技能？”
以史为鉴，能够知兴衰。这便是编程前史学的魅力。
Gopher 的真正中心竞赛力
到了这儿，各位Gopher是不是有点激动，计算机和编程现已深化了各行各业，程序员再也不是本来那个奥秘、高收入、令人尊敬的工程师，也只不过是一个一般的技能人员。下一步，年代的车轮滚滚转动，商场挑选微服务，挑选一种更进退自如、能够自愈的架构方法，替代本来万能结构，又会带来一次新的革新。
在这场革新中，Gopher假如不能改变观念，仍是以学习java那一套来学习go国际，应该很快会碰到一个问题，那便是go自身也没什么好学的。
go面试就没有Java面试那么丰厚的常识点，没有23种规划模式，没有JVM，语法层面也没有什么特别多的问题，更没有一致的结构能够问。也只能问问Channel、GC 这块。
所以既要学好 Go 自身，更要学好微服务，学好完成微服务要用到的各种东西：容器、Kubernetes、ServicesMesh。由于这些东西许多都是用 Go 编写，这就为咱们的阅览、学习、改造供给了便当。近水楼台先得月，这便是Gopher的中心竞赛力。
微服务的优与劣
总结一下，微服务是一场架构层面的革新，而 Go 由于其简略实用的语法、编译快、可执行文件小等特点，是微服务所依赖的底层基础设备常用言语，这或许会为 Go 开发者进一步学习供给必定的基础，但“千里之行始于足下”，假如不认真去学，一步一个脚印，常识也不会凭空而来。
我在前面的篇幅着重介绍了微服务，好像它便是未来软件开发的首选，今后每个开发、每个公司都会挑选它，但咱们都知道：“软件开发没有’银弹’”，一个事物，假如它的优势越显着，那么它的下风也越显着，并且一般来说，它的下风便是它优势的反面。
微服务优势能够总结有如下几点：
- 事务代码和技能代码别离
原先在结构内部的代码如负载均衡、服务注册、熔断限流、链路追寻等等，均沉积到技能底层，对事务的开发人员透明化，事务开发人员能够更好的考虑用什么言语、什么存储去完成服务逻辑，而不必遭到结构的限制。
- 快速迭代，安稳发布
微服务专心于一项功用，且有明晰的接口鸿沟。这样，无论是迭代升级，仍是彻底推到重来，改造的成本都比较小。并且，由于底层调度体系的支持，发布服务时再也不用比及凌晨用户量少的时分悄悄更新一下，发布变得更快速更安稳。
- 简化开发步骤，提高效率
微服务化今后，关于一般开发人员而言，担负是更轻了的，技能代码的抽离使底层技能成为黑盒，开发新服务只需求一个轻量的结构，快速配置一下即可立刻开端开发，梦回 SpringBoot 年代。
而微服务的下风，相同也是三点：
- 沉重的技能架构带来的考验
代码的别离势必导致团队内对底层服务的了解更少了，即便团队内有人愿意去学习，一方面或许了解的人不愿意花心思科普；另一方面自己也有沉重的事务开发担负，精力不行。
所以有关微服务的书籍都会不谋而合的说到“康威规律”，便是要求这些别离出去的技能设备需求独立团队保护。自从阿里提出“中台化”战略后，这些基础设备也有巨大上的姓名：“技能中台”。
但抱负很饱满，实际很骨感。就我的视点看，这样一个团队在中小型公司存活的概率不大，一方面这些设备的建设是长期工程，短期难见成效；另一方面，这个团队在内部推行新设备的阻力也是比较大的，简单遭到事务侧的反对。
可是这个团队无法建立，微服务就只能沦为拆服务的游戏。
- DevOps 的要求
微服务相同对运维团队提出了更高的要求，也便是现在常听的“DevOps”。原先发布或许便是丢个包上去就行，那些“build once , run anywhere”什么的标语都是广告，实际上一般的公司也没那么多的平台需求。
现在发布要搭建一套自动化发布流，与“技能中台”团队有更多的重合部分。实际上问题和“技能中台”团队碰到的差不多，效益和推行问题。
但 DevOps 略微温文一些，由于实打实的能在短期内看到作用（发布变快了）。
- 固化程序员的阶级
一般开发者能更快的开发程序，关注更少的架构侧的改变，对公司是功德，对个人不见得是功德。技能团队由人人都或许成为精英，变成了少量精英带领大量技能工人。原先人人开发，线上呈现问题，咱们各自处理 bug。现在，bug 先由基础设备过滤一遍，一些或许不会呈现，一些或许基础设备自身就处理了。导致工人们无法处理更多的 bug，获得更多的实践经历。
举个比如，一个新手后端开发，原先写的代码或许会导致流量过大时呈现内存走漏，本来是一个严峻的过错，可是在微服务架构下，流量变大时，服务自动扩容，或许内存走漏底子不会被触发，那这位新手后端开发永久也不会知道自己的代码哪里呈现了问题。
那么，精英们在优化基础设备的过程中越来越稳固自己的常识，工人们却现已无法经过实践更新自己的认知，这种马太效应会越来越分解精英和工人之间的差距。
工人们能经过学习改变自己吗？就软件学科而言，很难。没有实践，看再多书，学再多的东西，只不过是什么时分会忘记的问题。
参考文献
- 《凤凰架构》 icyfenix.cn/architectur…
- 《微服务规划》
作者正在找工作，在新的一年，希望能迎候更多的技能应战，深化云原生范畴学习，尤其是服务治理和可观测性，如有相关岗位可与我交流~
