「作者面对面 (Chat Chat)」是 GitChat 团队出品的一档对话技术写作者的栏目。我们希望通过展示更多 Chat 作者的视角，来分享程序员关于生活和工作的态度，以及学习和成长的经历。立足于写作，但不限于写作。
这次我们的采访对象是一位有十多年研发经验的资深架构师 秦金卫，KimmKing。他曾经在阿里担任架构师，也曾担任某商业银行北京研发中心的负责人，他还在最近成为了 Apache Dubbo PMC。
他关注领域包括互联网、电商、金融、支付和区块链等，熟悉海量并发低延迟交易系统的设计实现以及各类中间件，擅长 SOA/微服务等分布式系统架构。在工作之余，他也是各种开源技术的支持者、活跃于多个开源社区。
他和几位作者一同出版了《高可用可伸缩微服务架构实战：基于 Dubbo、Spring Cloud 和 Service Mesh》一书，并在近期推出了 GitChat 专栏 《JVM 核心技术 22 讲》 。
本期面对面，我们一起聊聊他架构师路上的磕磕绊绊，以及他多年坚持技术分享的原动力。
是什么让你一头扎进程序员队伍里的？
很久很久以前，我刚上大一，专业是化学，但是我发现自己对编程感兴趣。正好我们学院自己搞了一个机房，我有幸成为几个管理员之一。这么好的机会不能浪费。我那时候一不看电视剧二不玩游戏（小编：学霸啊！没有对比没有伤害），天天痴迷于学习 VC、VB、Matlab，后来则是 Java 和 Dotnet。
今天做个纸牌游戏玩斗地主、明天搞个聊天室系统，一发不可收拾，每天最少几百几千行代码起。看着自己的代码成功编译、运行起来以后，那种成就感，是无法比拟的。可以说，我是误打误撞➕兴趣使然，进入了这个行业。
2011 年的时候，我在淘宝，对面工位是一个在中间件团队做 TDDL 的技术大牛，巧的是他也是学化学的（北京大学化学工程专业）。我问他做程序员这一行的，学化学的人多不多。他跟我说前几天去参加一个 C++ 的会，他前后左右好几个人都是学化学转行做的程序员。
所以我们的亲身事例说明了，无论你是什么专业，只要有心去学习和尝试，都能够在程序员这个群体里找到适合自己的位置。（小编：不要轻易给自己定性，对自己说“我不行”。）
我也要感谢这个高速发展的行业，让我们这些从业者有机会跟着行业一起快速发展。
这一做就是十多年，应该也遇到过一些坑，能跟大家具体讲讲吗？
回顾我这十来年的经历，既有成功的经验，也有不少失败的教训。踩过很多坑，填过很多坑，也挖过不少坑，三天三夜也说不完。总结起来，特别想跟大家分享两点：
1）所有的坑，都是具体的问题。有些是已经发现的，有些是潜在还没爆发的。
陈春花在《管理的尝试》里说，所有的管理都应该以问题为导向，而不是以成就作为导向。深以为然，技术领域其实也一样，不管是解决方案、架构设计，还是编码实现、测试部署，都是在解决一个个的问题。翻过了一个问题的大山，还有另外一个。
而解决问题，需要我们去了解分析问题，然后依据分析的情况，结合自己过去的从业经验去给出下一步的诊断方向或者可能的解决办法。但是技术的发展变化速度实在太快了，如果作为一线从业者的我们不去努力持续学习，跟着行业和技术本身一起成长进步，那么很多可用的方法、工具和技巧就会在你考虑问题的视野之外。你自己都不知道，肯定不能很好地解决问题。
2）技术，一定要创造价值。创造价值，可以是提升了业务的业绩数据，也可以是改善了用户的体验，也可以是降低了现有的成本或损失。
如果一项技术工作，没有创造价值，那么无论我们在上面做出了多少努力，从团队和公司层面来讲，它就是与我们的实际需求相割裂的，没有意义的。（小编：有的时候可能只是假忙碌，却一直在做无用功，只是感动了自己罢了。）
举个例子，我在几个规模不同、发展时期各异、研发成熟度不一的研发团队中，都发现过一个共同的关于 JVM 的问题：线上经常有 JVM 实例自己突然崩溃，这个过程也许是三天，也许是 2 周，异常信息也很明确，就是内存溢出 OOM。运维人员不断加大可用堆内存或者云主机的内存，也无济于事，顶多让这个过程延缓。
大家怀疑内存泄露，但是看 GC 其实一直还都算正常，系统在性能测试环境也没什么问题，开发和运维还因此不断发生矛盾和冲突。
有个运维同事为了缓解问题，通过一个多月的观察，持续把一个没什么压力的服务器从 2 台逐渐扩展了 15 台，因为每天都有几台随机崩溃。而从系统通知到他去处理的这段时间内，他需要让其他机器可以持续提供服务。大家付出了很多努力，做了一些技术上的探索，还想了不少的歪招，但是没有解决问题，也就没有创造价值。
在深入了解了问题之后，我几分钟就解决了问题，我们把服务器又压缩回 2 台，可以保证系统稳定运行、业务持续可用。既终止了提高成本带来的损失，也得到业务方和客户认可。
那么实际问题出在哪儿呢？一台云主机 4G 或 8G 内存，为了让 JVM 最大化使用内存，服务部署的同事直接配置了 xmx4g 或 xmx8g。因为他不知道 xmx 配置的内存和 JVM 可能使用的内存是不相等的。我让他把 8G 内存的云主机，设置为 xmx6g，从此再也没出过问题。他也观察发现，Java 进程最多的时候自己使用了 7G 出头的内存（堆最多用 6g，Java 进程自己、堆外空间都需要使用内存，这些内存不在 xmx 的范围内），而不是 xmx 设置的 6g 内存。
这个事情让我意识到，可能很多人并没有系统地了解过 JVM 的一些常识，这些都是很实用的 Java 基础知识。市面上的 JVM 书籍，虽然深入讨论了 JVM 内部的实现细节，但对一般学习者来讲太深了，容易让人望而却步。这样就导致了大家也不知道实用的知识点是什么，怎么转化到实际的工作中，以及如何在工作中更好地应用这些工具。
所以，我们就觉得写一个深入浅出的 JVM 专栏，是非常有益于大家的学习和工作的。既能让大家很快系统地学会知识点，也可以让大家能直接应用到实际工作中，产生价值。
您的履历特别丰富，曾先后在阿里、银行等大厂负责技术架构这块。那你还记得当时面试的场景吗？能给我们的读者们一些面试的建议吗？
我去淘宝是 2011 年初，面试细节我已经不太记得了。大概方向我还有点印象，像 JVM 之类的知识是面试中的重要技术问题。
近几年来，我面试过的人超过一千位，从应届校招生和实习生到中高级和资深开发，再到架构师和技术专家总监。我和我的团队最为关注的要点包括：基础技术基本功是不是扎实、对实际问题有没有深入分析和处理能力、跟同事/领导/业务部门等合作方的沟通能力、对自己的清晰认识和明确发展定位、对各种新鲜事物保持好奇心和探索精神等。
特别是基本功的持续积累，如果做不到，基本在面试的前 10 分钟就可能让面试官形成一个非常不好的印象，进而导致面试失败。
您是资深的微服务方面的专家，既跟程超和张逸几位老师合著了《高可用可伸缩微服务架构实战：基于Dubbo、Spring Cloud和Service Mesh》一书，还撰写了《微服务架构深度解析与最佳实践》等技术文章。您分享相关技术的初衷是什么？
我个人因为工作关系，对 SOA 和微服务架构非常了解，也一直在从事相关框架的研究和应用工作，今年也成了 Apache Dubbo 项目的 PMC 管理委员会成员。
近几年来，我在微服务相关技术和实践上积累了大量的一手经验。所以我也一直持续在社区和 GitChat 上，把这些经验分享给大家，希望能帮助大家在做微服务项目或旧项目改造的过程中，尽量少走弯路，让微服务架构的思路和原则，多快好省地在自己的场景落地。所以，我的初衷就是：我因为分享而感到快乐，希望能跟大家一起用技术创造价值、改造世界。
您和任富飞老师一起撰写的专栏 《JVM 核心技术 22 讲》 近期上线了，对于那些潜在的读者们，你希望读者能通过阅读你的专栏有什么收获？
市面上各类 JVM 相关的资料虽多，但是明显存在两个极端：要么过于生涩难懂，要么流于某个片段而不系统化。同时各大公司也都越来越重视推动和发展 JVM 相关技术，在一线大厂的技术面试中 JVM 知识也是必考科目。
在这个背景下，我们全面梳理了系统化学习 JVM 的知识和经验，包括 JVM 的技术和内存模型、JVM 参数和内置工具、GC 算法、GC 日志、内存和线程等相关问题排查分析，以及常见的面试问题深度剖析等进阶方法与实战。既满足大家快速系统化学习和全面掌握知识的需求，又兼顾大家的面试经验辅导。
夯实基础：掌握 JVM 的基础知识和常用工具，了解一般原理，知道从什么地方着手分析问题；
深入学习：掌握各类 GC 算法的一般原理，知道如何根据实际需要选择使用合适的 GC 策略；
分析问题：掌握 GC 日志、线程、内存等维度的分析技巧，知道排查问题和优化系统的套路；
积累经验：了解常见的分析调优经验，熟悉常见的面试问题和技巧，彻底学会 JVM 知识。
本专栏的特点可以总结为 16 个字：
体系完整、层次分明、深入浅出、实践为要。
对于广大的程序员们，尤其是刚踏入此行的年轻人们，他们可能很关心编程语言、具体技术的选择，纠结是选择新兴开源的还是成熟的技术，对于这些“焦虑”，您有什么过来人的建议吗？
先告诉大家一个好消息，完全不需要焦虑，就像我在知乎的一个回复里提到的一样：
按各方的统计口径，今年中国的程序员数量大概在 400-700 万之间。也有人保守估计大概在 350-450 万之间。这其中 Java 程序员的比重最高。
虽然数量很大，但从招聘行业的统计来看缺口还是越来越大，而且越是技术高手（工作 5-8 年的资深或专家）越缺，其实每年毕业新进入到行业的人数比大家想象的少得多，同时还有不小比例的流出。
其实从两个侧面就可以看出来这种现象：
市场前景：传统 IT 的互联网+进程还在继续扩大，传统企业的信息化进程还有很大空间，这就需要越来越多的技术人员加入互联网，这说明在未来一定时间内，市场需要更多的技术人员。
薪酬红利：IT 技术人员的薪酬待遇还是比一般行业高不少，虽然门槛也要稍高一些，这说明优秀的 IT 技术人才还是卖方市场，缺口很大，所以待遇上有行业红利。如果哪一天技术人员的薪酬跟一般的办公室职员差不多了，就说明红利结束，市场饱和，目前看来还很远。
还是那句话，技术正是因为 IT 行业的快速增长而爆发式发展。那些学会了一定知识就可以一成不变地使用 20 年的行业，都正在走向日暮西山的境地。我们只需要跟着行业终身学习，就可以在未来的 5-10 年，甚至 20 年内，持续享受到行业发展的红利。
一个小窍门就是，不要只选一门语言或技术。我特别建议大家选择 Java 这种市场广阔、生态成熟、招聘量大的语言作为主语言。深入学习，勤学苦练，在工作中使用，在大型项目里使用，学透、用熟。同时选择一两门第二语言，比如 Python 或 Golang。在很多不同场景下，这些第二语言也会发挥一些意想不到的作用。
对于框架来说，开源是大趋势。所有的好技术，越来越拥抱开源，连微软都改了一向与开源为敌的做派，开源了 dotnet core，收购了 GitHub 最大的开源网站。我们可以看到，微服务、大数据、云原生、AI，每一个领域都有无数开源项目。每一个新兴的技术，不是在开源，就是走向开源的路上。
在我们采访的尾声能否告诉大家，从你的经验来看，未来比较有潜力的技术方向会是什么？
这个问题太大了，我简单缩小一下范围来说说自己的看法。
1）从目前的大环境来看，比较热的技术方向主要是 ABC：
A 是 AI 人工智能：近年来随着深度学习、卷积神经网络的发展，应用技术层面也发生了大爆发，可以说是未来可期。
B 之前是 Big Data 大数据，现在也指 Blockchain 区块链，这两个技术，在我们可以展望的未来里，就是整个 IT 行业的血管和骨骼，支撑着我们的所有活动。
C 是 Cloud，包括云计算，云平台、云原生的技术体系、云一体化等等，公有云、私有云、混合云成为所有 IT 行业的水电煤，支撑所有的 IT 系统和业务发展。
2）缩小到微服务架构、企业应用架构来看，从单体架构 -> 分层架构 -> SOA 架构 -> 微服务架构，我们越来越具备去指导大家设计、开发和维护更大规模的复杂业务系统的方法论和相关技术工具。同时微服务架构本身也开始出现两个大的方向：
一个是我们发现现有的各种微服务相关技术一边在处理业务逻辑，另一方面同时也在处理各种非业务的特性，比如如何扩展、均衡负载和流控等等。因此我们应该把这些非业务部分的处理从应用程序里拿出来，下沉到了下面一层，我们称为服务网格（Service Mesh）的基础设施上，以 Istio/Envoy 为代表。
另外一部分人发现，我们之所有要搞这些非业务的特性，是因为我们需要高可用和可伸缩这两个重要的特性，于是发展了基于消息驱动的响应式微服务架构（Reactive MicroServices）。它要求我们的系统不管在什么情况下，都保证一定范围内的响应服务能力，同时又能够快速恢复故障，在流量的压力下可以快速扩展，增加实例或者减少实例，以 Vert.x 为代表。
3）具体到 Java 相关的话，明显可以看到 3 个大方向：
一方面是最近 2 年多 Java 每半年发布一个大的版本，新的特性不断加入，特别是 lambda 和 var，以及 Stream API，Zero GC 和 Shenandoah GC 等，给我们带来了很多惊喜，也给 Java 注入了更多活力。
第二方面，基于 JVM 的各种新语言层出不穷，从最开始灵活的脚本语言 Groovy，到 Scala、Clojure、JRuby、Jython，到后来的 Ceylon，Kotlin，Fantom，Xtend 等等。越来越多包含新特性的语言加入到了 JVM 上，也催生了 Vert.x 这种以多语言编程为特点的框架，这意味着你可以直接使用不同语言来开发不同的微服务模块、独立部署，并允许它们在一起很好的工作。
第三方面，除了 Oracle JDK 和 Open JDK 之类的开发运行环境，还有 Azul JVM 和 Oracle Graalvm 等非常有特点的 JVM：Azul JVM 的 C4 GC 能够支撑上 T 规模的堆内存做到 GC 时间 1ms 一下；Graalvm 则是不仅支持多语言编程，而且能够把 Java 程序直接编程 native 的平台原生代码，从而大大降低启动时间和内存使用。
总之，技术的发展是日新月异的，我们要与时俱进、了解新技术、学会接受和尝试新技术。技术是第一生产力。成熟而稳定的新技术，只要使用得当，就可以给我们带来技术红利，进而为团队、公司和行业创造出更多的价值。
点击阅读原文，关注秦金卫