本来之前标题的名字是不要被技术buzzword误导，觉得还是得标题党一些，:)，请大家谅解，技术圈时常会不断的产生一些新的buzzword，很容易被误导，最可怕的是一些技术团队在没搞明白的情况下，就按buzzword去做或者去靠拢，好像生怕如果自己做的技术和buzzword不相关或者不一样，就很low一样，感觉这现象在技术圈太常见了，有些看的不太爽，写篇文章来讲讲自己的观点。
作为技术圈的我们大家，对各种buzzword一定要慎重，了解它产生的背景，可执行的各种前提和条件，技术始终是为公司的战略而服务的，buzzword是不是真的给你的场景带来了帮助，要想清楚，拿时下比较流行的微服务、AI、AR/VR来说说吧。
说到微服务这个buzzword，必须承认到现在为止我都没搞明白和服务化的区别，我都搞不太清楚淘宝在2008年做的服务化改造后形成的SOA体系到底是不是和现在的这个buzzword就是一回事，在各种文章里，微服务简直就被宣传的像是技术界一些场景的救世主，直接误导了很多同学上来就必搞微服务体系，但不知道有多少同学仔细想过有没有必要，对业务发展来说采用微服务到底是帮助还是变成了阻碍，在互联网类型快速迭代的业务中，业务的迭代效率是核心问题，以我自己的认知，对服务化我的观点一直是如果能不进这个坑，最好不进，一个单一应用的复杂度远比N个应用组成的分布式系统简单、快速多了，一旦进入分布式的坑，在技术上就不得不有比较大的投入，而对于一些还处于中小规模的公司而言，我觉得完全没有必要，Google的Jeff Dean在一次分享时讲到他对于Google做服务化的观点：让Google具备了千人并行协作开发的能力，在看到这观点以前，我一直觉得服务化重点解的是水平伸缩能力的问题，其次是并行协作的问题，但我现在基本更加赞同服务化重点是让一家公司具备了百人以上的并行协作开发能力，我认为在几十个研发同学的情况下，并行协作开发不会成为太大问题，这个时候的并行协作上的一些投入会远比进入服务化后的投入小很多，所以以前有一些朋友问我公司到底要不要改变为服务化时，我都问两问题：1. 公司研发团队现在总共多少人？ 2. 目前的水平伸缩瓶颈是？ 如果在这两个问题上服务化并不是核心的瓶颈，或者只需要付出少量的人或机器代价就可以解决，我会强烈建议不要做服务化，所以拜托受微服务这个buzzword诱惑的同学们，请大家在采用这样的架构前一定，千万要慎重思考，策略应该是以尽量不采用去推导会产生的代价和问题，如果这个代价和问题并不是那么大，就不要用，除非真的万不得已，那就请做好组织、团队人员方面的布局，以真正的做好服务化，不要让这个东西最后变成业务发展的障碍。
ps: 2015年也写过一篇，《服务化，你真的需要吗》，点击阅读原文可以看看。
说说AI这个buzzword，我拿运维这个领域来举例说吧，AI实在是太火了，同样导致了运维界很多的工作也恨不得赶紧和AI绑上关系，当然不可否认的是，在运维这个领域，AI绝对是可以产生巨大帮助的，但首先要想明白的是你的整个环境真的为AI做好了准备吗？没想清楚这个问题，很容易最后出现一个状况是，各种算法，智能动作等等都准备好了，结果是基础的技术层面或环境层面压根就不具备这个能力，一切白扯，例如在运维这个领域，我认为要引入AI让其发挥作用，前提是要先把数据化、自动化、无人化做好，如果连这些都没做好，千万别先跳进AI的坑，AI通常依赖大量的数据去智能化的执行动作，这种情况下没有数据，不能自动执行，自动执行过程中需要人介入，那都意味着没法玩，很典型的在运维领域的一个case，容量的弹性伸缩，如果连判断一个应用容量够不够的数据都不充分，连应用能自动部署和启动都做不到，那先做了一个弹性伸缩的系统又有什么用呢？所以我更赞同的是AI确实是前景，但首先要把AI需要的一些前提给做好了，然后再进坑，千万别走反了。
最后说说同样极度火爆的AR/VR，AR/VR是个非常复杂的话题，同样很多的业务一冲动就决定投入大量资源去玩这两个方向，觉得不玩就挂了，但在玩这两个方向前，同样要想清楚的核心问题是，对于你的业务场景而言，AR/VR的一些技术普及的条件是不是都具备了，例如你生产了AR/VR内容，但现在的AR/VR的用户数，AR/VR设备的情况是不是真的到了值得你投入大量资源去做，君不见很多创业公司在做app的时候都先只做ios版本。
所以总的来说，就是技术圈的各种流行buzzword呢，当然会有它一定的道理，但是不是真的要去采用，千万别纯粹跟风，或者纯粹从技术角度判断，仔细的思考如果要采用buzzword，会发生什么，要做好什么样的准备，能获得什么样的收益（这和每家公司的战略地位，业务发展情况直接相关），毕竟一家公司的资源都是有限的，进了一个坑就意味着另一个坑可投入的资源少了。