聊聊自己
前几天看到阿里云小编姐姐在群里抛出了《架构师成长之路》这个专题，其实蛮开心的，因为我终于可以“被迫”总结下这些年的经验了，所谓压力才是生产力，偶尔对自己施压总结，提升最大的还是自己，假如读者也能从中有一点收获，那我大概是赚翻了:-)
在这之前，我先卖卖自己。
我大约10年前入行，一直从事软件开发类工作，以Java技术栈为主，偶尔用Node，其他技术也略有涉及。期间做过各式各样的产品，包括但不仅限于政务、电商、教育、社交、金融及区块链等等。18年出版过一本技术书籍《Akka实战》（机械工业出版社），今年也可能会出一本译作。我目前坐标上海，担任多家公司高级技术顾问，提供技术分享、培训和咨询等服务。同时今年也非常荣幸，被授予阿里云最有价值专家(MVP)，希望能在自我提升的同时，也带给大家一些有价值的思考。
我算是一个典型的白羊座，以及非典型的工程师。为什么这么说呢？因为我多多少少有点冒险精神，也擅长折腾，中途曾多次尝试过创业，有的是自己主导的，有的是跟随合伙创业，但无论怎样，都一直没有脱离技术圈。在任何组织里，都是以技术负责人或者架构师的角色存在，算是见证了多个产品从0到1，然后从1到100的成长过程。在这个过程中，无论是研发体系还是业务体系，甚至HR体系，都会快速发生变化，正是因为我亲历过这些变化，才使得我能以业务全局和团队整体情况来考虑技术架构问题，而不会从最开始就陷入技术细节之中。
我是一个非常喜欢写作和分享的人，这算是我迄今为止养成的一个最重要的习惯。互联网行业发展太快，要学习的东西非常多，我们每天都能接收到来自四面八方的信息，仅依靠大脑来做瞬时的过滤分析，已基本不可能，甚至会出现思维钝化的情况。写作，可以让自己内心平静，对信息进行有效去噪，然后将所思所想真实的记录下来，形成自己的知识财富。同时，分享给其他人，看起来是帮助别人，但可能会因为收到有价值的反馈，反而提升了自己。所以说，分享者往往是最大受益者，正如我写本篇文章一样。
回到架构师成长之路这个话题，在很多人眼里，架构师就犹如古代的将军一般，既能运筹帷幄决胜千里，又能独闯敌营取人首级，是所有士兵们崇拜的偶像...好了，其实我只是想说：能成为一名优秀的架构师，确实是所有工程师的梦想。架构师这个title，没有一个统一的标准，大多数都是公司内部按照一定职级设定的，甚至有的工程师一直在做架构师的事情，但仍然没有架构师的title，这都很正常。我相信大多数人不是为了混title才想当架构师的，最终还是希望自己能达到架构师的能力级别。那么，架构师应该具备哪些能力呢？基于我近几年来的一些血泪经验，大致总结出了下面几点：
1.有扎实的技术功底，对底层有庖丁解牛的能力；
2.对领域内的技术栈有全面的了解，能做合理的架构评估；
3.对新技术敏感多情，并能预判其引入风险；
4.有较强沟通、学习、分享、协作能力；
5.有较强业务分析能力，深刻理解业务及产品价值；
大家会看到，这里面大概有一半儿与技术有关，另外一半儿纯属软技能，这些都非常重要。我们以前评价一个技术牛人，都会以【技术实力】强来描述他，但实际上，作为一个架构师，技术实力只是他能力模型的一部分，我认为，一个更能描述架构师能力的词汇应该是【技术掌控力】，上面列的这5点，其实都属于其范畴。本篇我们主要看看，什么是技术掌控力？以及如何提升技术掌控力？
什么是技术掌控力？
大家都知道，技术实力是架构师安身立命的基础，也是你的同仁或朋友对你打的最重要的一个标签，你在团队内的影响力大概率由你的技术实力来决定，假如在技术上有明显问题，那么在这个团队内基本上没有未来。那么，技术实力是怎么体现的呢？
图中两个妹子虽然是外行，但是有时候“写代码快”，确实也会被认为是技术实力强劲的表现（虽然不一定准确），不过更多的，可能是下面这类同行们的评价：
“张某某的算法写的真好哎，技术牛人一枚啊。。。”
“李某某刚才解决了一个并发问题，技术真牛逼啊。。。”
“王某某刚采用了一个新的中间件，一下解决了耦合度过高的问题，膜拜一下。。。”
不得不说，这三个人的技术实力肯定是不错的，他们都能在自己的方向上解决产品上的问题，但是，假如要做一个优秀的通用型架构师，仅仅在某一方向偏科是不行的。架构师不仅要能在某一方向上做到顶尖，更应该【对领域下的技术栈有全面的掌控力，并有能力通过技术手段让业务及产品发挥出最大价值】，这里的领域可以理解为当下要做的事情，比如产品、方案、系统升级等。说的更具体一点，所谓【技术掌控力】，大致包含两个方面：
1.从技术层面来说，能够对各类技术方案的核心底层逻辑有非常清晰的了解，然后根据实际情况进行架构评估（比如易用性评估、扩展性评估、替代方案评估、风险评估等等），最终做出一个最合适的架构方案。
2.从业务和产品层面来说，能时刻关注业务产品发展现状，以及预判未来发展趋势，进而动态的、持续的调整和完善架构方案，通过技术手段，实现业务产品的最大价值。
所以说，技术掌控力，是技术实力的全方位升级，是更加全面的一种能力。工程师假如要往架构师方向发展，应该将技术实力进化为技术掌控力。
至于如何提升技术掌控力，我有下面一些粗浅的看法。
苦练内功
很多工作几年的工程师，在精通CURD之后，往往会陷入技术上的停滞状态，
这时候可能会出现两个极端：
1.由于没有学习目标，所有学习想法只停留在脑袋里，最终出师未捷心先死；
2.由于学习目标太多，频繁在各个技术领域来回划水，最终弱水三千一瓢都没取到；
老实说，每个人都可能会在某段时间内突然失去目标感（没有目标或者目标太多），包括我自己，每个月也有那么几天是这样:-)
其实这个时候最好的做法就是去苦练内功，就好比你打篮球一样，当周围全是防守人员，挡住了你传球的思路，什么都做不了的时候，那么最好的做法就是：拼命往球框的方向扔就完事儿了，进不进无所谓，至少方向是对的吧...而苦练内功，绝对是最正确的方向。
不知道大家爱不爱看武侠，在武侠中，内功是所有绝学的基础，只会招式而内功缺乏，战力非常有限。比如《射雕英雄传》，主角郭靖武功盖世，人人敬仰，是我们年少时的偶像。那么他的武功是怎么一步步达到顶尖的呢？郭靖在年少时，由江南七怪教他练一些拳脚功夫，以招式为主，内功基本没有，打打小流氓不在话下，假如遇到高手，肯定会输的吐血，会再多的招式也没用。后来，全真派马珏传授了2年全真内功，武力值一下提升了数倍，这才为日后练习降龙十八掌打下坚实基础。假如没有内功基础，我想洪七公肯定是不会贸然将此神功传授于他的。包括后来学会老顽童的空明拳、以及被骗学会九阴真经，都是因为他有强大的全真派内功基础。
其实在技术领域，道理是一样的，技术领域的底层基础，既是内功。对于工作两三年的工程师来说，想入门一个新的编程语言、框架，其实都非常简单，搭建完环境，跑跑demo，看看API，相信一天内能完全搞定。但是，你要开发生产级别的产品，你会发现，以前用A框架要面对的问题，用B框架也仍然需要面对。就以最常见的并发、GC这类问题来说，只要你用Java，采用任何框架都是逃不掉的。而这类问题，就属于内功问题，一旦内功提升，哪怕用最简单的招式，也能解决很多问题。同时，学习其他新技术的时候，也自然可以融会贯通。
在我看来，练习内功（底层基础）其实是蛮简单的一件事，大部分情况下，你不需要依赖其他环境，比如说学习并发编程，直接打开IDE就可以开始做了。再比如GC，只需要配置几个启动参数，学会几个命令，就直接可以开始看了。相对于其他各种大而全的框架技术来说，它对环境的依赖程度非常低，提升效率非常高。
所以，当大家不知道学什么，而又想提升自己的时候，练内功吧，成长速度比自己想象的要快，We can do this all day...
对技术敏感多情
以前在面试的时候，我经常会问候选人几个额外的问题：
1.你会经常逛什么技术社区嘛？哪些社区？
2.最近有哪些想了解的新技术？
3.你关注了哪几个技术类的公众号？
4.最近读的一本技术书籍是什么？（偶尔还会问下对方作者是谁？）
5.最近技术圈儿有什么八卦没？
6.......
之所以会问这些问题，主要是想考察候选人是不是经常关注IT圈子，对一些新的技术或技术牛人有没有过了解，我认为，哪怕是天天在社区里面灌水或者搞八卦，也比什么都不闻不问强。可是，很多工程师自诩热爱技术，却连技术社区都不逛，对新技术新名词一无所知，让人如何相信呢？
我认为，工程师一定要对新技术保持敏感，“花心”一点。每种新技术的出现，肯定是为解决当下问题而出现的，虽说解决问题的方式有很多种，但最终肯定有一种最优解法，对新技术理解的越多，在做技术选型时就会越从容，更易做出最优选择。我们经常说，要学习一门技术，得通过项目实践才能真正掌握，这是一句正确的废话。很多时候，你想要学习的技术，并不一定会在实际项目中采用，你能做的，只有自己创造Demo场景，然后编写各种测试代码进行研究。我在工作的前几年，也经常抱怨不能通过实际场景学习新技术，然后心安理得的拖着不去做研究，以至于在遇到真实案例时，只能边学边用，出过很多严重的生产问题，经常吐血。
所以，大家要尽早放弃用生产案例供自己学习新技术的想法，任何机会都是留给有准备的人的。
学会识别风险
虽说我们要对新技术保持敏感，但是在真正选型时需要格外慎重，有句话说的好：大胆尝试、小心求证，我觉得放在这里非常合适。有很多新技术，虽然能解决现有的问题，但是也可能带来新的问题，所以很多时候，工程师都是在不停填坑，然后挖坑，最后继续填坑的反复循环中。作为架构师，需要识别任何新技术带来的风险问题。
这里举一个之前经历过的一个小例子。当时有个老产品，除了做运营活动时会出现一定的性能波动，其他时间一直平稳运行。团队中某工程师发现，之所以会出现性能波动，是因为在订单处理时同时会做一些积分、赠券相关的计算，当量大的时候，计算量水涨船高，占用了极大的资源，也会导致更长的延迟。该工程师提议，可以在订单处理时引入MQ，将订单更新成功的消息发往一个计算服务去执行，这样不仅使订单落库的更快，还解耦了这块的复杂逻辑。老实说，这是个非常好的方案。但是呢，仔细思考，这个做法会带来下面的风险：
1.引入MQ中间件，势必要保障MQ的高可用，假如出问题了怎样？运维是否有能力hold住它；
2.万一发现RabbitMQ存在问题，RocketMQ能不能在尽可能少改动代码的情况下进行快速替换；
3.计算服务独立出来，需要增派人手进行开发（人是否够？），并且也需要纳入运维的日常巡检管理；
4.计算服务既不能少算，也不能重复计算（幂等性），可靠性要非常强；
5........
当然，这里面还有很多细节问题，不再一一列出。由于这确实是个好的方案，所以最终采纳并完成实施，在解决完这些风险后，顺利上线了。顺便说一下，第1、2个问题，由于考虑到当时团队现状，直接上云保平安了。
所以大家看，即使这么一个看起来非常简单的方案，也需要考虑很多问题才能最终执行。我一直认为，能有效识别风险，是架构师技术掌控力的最佳体现。
关注非功能性需求
应用程序一般包括两类需求：功能性需求和非功能性需求。功能性需求是指应用应该实现的业务功能，这类需求一般由产品经理提出并形成PRD。非功能性需求是指应用的性能、维护性、扩展性、可靠性、以及高可用等运维保障性需求。本质上，我们做架构，大部分时候都是在做非功能性需求，这是架构师最重要的工作之一。
现实情况是，Boss或产品经理往往只会关注功能性需求，它们最常见的说辞就是：我要加个这么小的功能怎么这么麻烦？老实说，我理解他们，因为站在他们的角度，都是以业务实现来看待研发问题，能把功能性需求的逻辑整自恰了就已经很好了。而作为架构师，此时的价值就需要体现出来，不能完全被动接受纯功能性开发的需求，老实说，即使你用最糟糕的语言、最糟糕的架构，你都能实现Boss给你的任务，但是一旦产品稍微有点起色，就免不了完全推倒从来的风险，最后不仅给自己和团队挖坑，还会对公司造成损失。有的工程师可能会吐槽，产品开发周期有限，功能性需求都可能做不完，非功能性需求更加没空做。确实存在这种问题，我认为，即使由于deadline太紧而无法顾及更多非功能性设计，也应该在整个架构设计文档和开发文档中加以说明，这是作为“技术负债”的一部分，是需要给产品或者Boss详述报告的。除了让他们对当前产品有个合理的预期之外，也给团队以后“还债”预留时间和空间。顺便提一句：假如永远没有还债的机会，可能公司并不需要一名架构师:-)
我们工程师很容易进入一个误区，那就是总觉得只有大一点的产品才需要考虑非功能性需求。实际上，不同阶段的产品有不同阶段的非功能性需求。比如说，很多互联网公司的产品，特别是创业阶段的产品，都遵循MVP（最小可行性产品）策略，即用最短的时间内完成最核心的功能，然后小范围投入市场进行反馈收集，并持续迭代。这种产品开发形式，虽然不考虑高性能、扩展性等问题，但是仍然需要考虑快速迭代、快速发布、稳定性等问题，否则用户会吐槽“你这款产品本身就已经极简了，不仅发新版慢，还各种卡死闪退”，好不容易积累的种子用户也会消失殆尽。随着产品不断发展，非功能性需求会原来越多，工程师需要关注更多更复杂的非功能性需求，比如考虑性能问题、服务或数据拆分等问题。假如一直坚持下去，不仅可以持续为产品发展带来价值，自己也能得到很大的提升。
学会交流与分享
在我入行的时候，经常听求伯君当年单枪匹马一年多，写出了WPS的传奇故事，总是感觉热血沸腾，不能自已。在那时候，我心里的技术大牛，就像武侠中的世外高人，他们独来独往，身怀绝世神功，但不为外界所知，而一旦横空出世，必定威震武林。事实上，在几十年前的IT行业，确实存在着大量顶尖高手，他们以一己之力推动者行业的发展。那个时候的高手们，是孤独的，就像求伯君说的：“有了难题，不知道问谁，解决了难题，也没人分享喜悦。”。
不过，IT&互联网行业发展到现在，已经不是当初的样子了，应用的复杂度急剧上升，靠单打独斗已经搞不定了。过去之所以个人英雄主义更多，其实是因为信息传播能力、交流协作工具等受限，人与人之间基本是信息孤岛，不像现在，有Github，各种社区、甚至微信群，可以很方便的进行交流协作。
事实证明，当信息传播能力越强，交流协作工具越来越高效，IT行业的整体水平都有更快发展，以Github为例，它吸引了全世界最知名的互联网公司，以及最有创造力的工程师群体，最终产出了最顶级的开源软件，为整个IT行业的发展做出巨大贡献，这是集体智慧发挥到极致的典型案例。
作为工程师个体来说，我们不应该故步自封，关起门来搞建设，而应该多和外界交流学习，无论是社区、行业大会，还是高质量的微信交流群，直播群，都可以尽可能的去参加，以吸取大家的集体智慧，这对增强行业见识，拓宽技术视野都是很有帮助的，当然了，假如能持续在Github上 show your code，那肯定是最高级的交流方式了:-)
我一直相信，人的精力非常有限，不可能所有技术都能完全精通，在我们自己冥思苦想仍不得解的时候，可能别人的一句话就点醒了自己，反过来也一样，这些都在我身上时有发生。老实说，以前的自己，也不太喜欢和人交流，内心总有点小傲气，总觉得人家讲的都是XX，有那么一点“技术相轻”的意思，而自己想去和别人分享心得吧，又抹不开面子，生怕自己讲不好，毁了自己的人设。直到后来，因为做了一次讲师，我才改变了这个观念。那是我人生第一次受邀做分享嘉宾，对方是一知名外企。第一次嘛，我亚历山大，也格外认真，在准备内容的过程中，竟然把我有关该主题的一些不起眼的盲点全部扫清了一遍，当时我就两个感觉：
1.这次分享我收获最大，这么爽的事儿以后不要钱都干啊；
2.分享的讲师之所以有底气站在台上，肯定是掌握了听众不知道的东西；
所以可以看到，无论是当分享者还是当听众，都是会有很大收获的。这里特别提一下，假如大家在公司内外都能做几场成功的分享，你自身的影响力也会逐渐提高，然后对很多事情的掌控能力也会越来越强，这对自己未来的职业发展是有很大帮助的，至少，你可以来申请阿里云MVP，对吧:-)
关注产品与业务
我和很多工程师一样，早年间只迷恋技术，对业务开发非常排斥，对业务的理解仅限于最基本的逻辑，对业务功能所能带来的价值更是不了解，让我理解用户？对不起，我可能连用户是啥群体都还没摸清楚。所以在头几年里，总感觉自己一身武艺，却没有发挥的地方，实际上是自己“作妖”导致的。后来在积累了更多开发经验后，就发现，假如对业务的理解有偏差，做出来的技术架构，开发出来的产品，基本上都是“不良品”，正是印证了那句话：虽然懂得很多技术，但仍然做不好架构，原因就在于此:-)
依我看来，IT行业对架构师的业务理解与分析能力的要求是越来越高的。以往有很多人，把架构师分为技术架构师和业务架构师。技术架构师，通常负责做好技术选型、搭建技术框架、攻克技术难点等工作。而业务架构师，通常负责平台架构、产品规划、领域模型等工作。但实际上，技术类架构师越来越需要拥有业务架构的能力，因为技术肯定是为业务服务的，他需要对实现业务价值做出自己的贡献，而脱离业务场景谈技术架构纯属耍流氓。
举个最常见的例子，大家现在都在讨论微服务架构（如图所示，这是我参考《微服务架构设计模式》并结合自己的经验给出的一个通用步骤），我们都知道微服务化是有诸多好处的，比如提高可扩展性、可维护性、资源利用率等等，这是会对产品带来长期价值的非功能性需求，是每个架构师都想做好的一件事。其实做微服务，最难的点已经不是技术栈了，毕竟SpringCloud、Dubbo这类框架已经非常易用了。最难的实际上是领域模型、服务拆分等问题。什么叫领域模型呢？这是DDD（领域驱动设计）中的常见词汇，它是指通过业务需求建立的具有统一术语的业务实体模型，它指导着程序的开发实现，同时，DDD中的另外一个概念叫限界上下文，对它的识别可以有效解决微服务拆分的问题。而这些概念，都与业务息息相关。所以说，假如对业务分析不足，是不可能做好微服务架构的。
平日里我也经常和众多研发团队负责人进行交流，大家有个共识就是：假如某个小团队里存在一位只追求用新技术或所谓“底层”技术而对业务完全不care的架构师，是非常容易出问题的。而且说句可能会被喷的话，对于大部分中小互联网公司来说，业务发展的规模可能还远远不到拼技术（我是指硬核的那种）的时候，这些公司架构师产出的，其实是业务产品。更何况，由于云计算的普及，有很多以前看起来“高高在上”的技术，已经完全达到开箱即用，便利性犹如水电煤一样。当然，这倒不是说技术无用，然后大家转型去做业务专家算了。技术实力仍然是架构师最重要的能力，但是，我们不要忽略业务领域知识的重要性。时常关注业务与产品，不仅对当前架构的合理性进行有效评估，还能够让自己对产品未来发展有个更好的预判，以便提前做出合理的架构规划，笔者认为，业务与产品的深入理解，其实也是【技术掌控力】的一部分。
最后，送给大家一句话：技术能力将决定你能走多快，而产品(业务)能力将决定你能走多远！共勉！
