看下资深架构师平时须要解决的问题，对比你离资深架构师还有多少距离——再论技术架构的升级之路

    我目前奋力在技术架构的路上不断前行，虽然中间遇到不少障碍，目前本身感受，勉强能达到架构师的级别，因此本身感受还有底气写这篇文章。

    以前，我写过篇博文，架构师更多的是和人打交道，说说我见到和据说到的架构师升级步骤和平时的工做内容，这篇文章更多的是从沟通角度分析架构师的升级之道。但咱们知道，架构师更可能是靠技术拿高薪。

    在本文里，我将列些我见到的技术架构平时须要解决的问题，有技术的，也有沟通协调方面的，以这些实实在在的案例，来列举些技术架构须要具有的技能，以此来分析下高级开发如何更高效地升级到技术架构。好了，开场白结束，正文开始。

 --------------------------------------------------------------------------------------------------------------

1 技术自己不产生价值，业务才会，论技术和业务的整合

      通常会把架构分为技术架构和业务架构，这里我无心对比这两类的优劣，但我只想说，在公司里，是靠业务价值创造盈利点的，因此技术，好比消息队列，内存优化，以及分库分表数据库集群等，只有嵌入到业务里，才能经过提高业务的可扩展性或性能，从而产生价值。

    

    上述彷佛是废话，但偏偏是架构师工做的难点，你们能够想象一下，好比经过MyCat搭建个分库分表架构不难，甚至把分库分表组件经过负载均衡搭建成集群也不难，这些网上都有现成的案例。但如何要在当前的业务系统里实现分库分表，难度就不小了。具体来说，由于业务系统里或许有冗余数据，并且有各种带join, group by等的查询语句，如何在分库分表系统里兼容这些历史问题，并且在上线新分库系统后迁移历史数据，又如，在产线切换到分库分表时，万一有问题如何回退，这些绝非是知道些Demo案例的高级开发能解决的问题。

    因此在技术和业务方面，我本身的感觉是（包括我见到的和听到的） ：只有接触到业务了，才能用技术解决实际问题，才能更了解这个技术用起来的各种坑，像刚才提到的分库分表是这样，其它的诸如日志组件，消息队列组件都这样。经过下面部分给出的架构师平时要解决的实际问题的讲述，你们能更深入地体会到这点。

2 资深架构师平时要解决的问题

    以下的问题均是来源于实际，出于项目保密的原则，本人隐去了关键性的业务描述，但你们都能看懂，并能感觉到架构师平时要解决问题的难度。

    

    问题一，A公司有财务管理人事管理等10个左右的项目，它们在产线上，须要标准化管理，好比用同一个Maven仓库，不论功能业务如何，得用同一套配置管理服务，用同一套日志管理和分析组件，还得用同一套大数据组件来根据不一样的业务维度来分析数据。

    若是是从新搭建一套系统，这个难度也不小，更况且，对资深架构师的要求是，在历史项目的技术上作标准化管理，不然每一个项目各管各的，维护成本大不算，不一样项目间的库还很容易产生冲突。架构师要在保持业务稳定的前提下实现这点，你们能够考虑下难度。

    问题二，随着B公司业务量的上升，数据库里的数据达到了T级，因此须要经过分库分表来实现优化。这自己不难，但如何在升级的过程当中保持业务的稳定？不能说上个功能点，关键业务就挂了，并且，万一上线后出现问题，得提供应急的回退方案。

    问题三，C公司是个创业型公司，刚开始的时候，经过SSM外加Oracle，能知足大多数的业务需求，但随着业务量的提高，须要资深架构在短期里实现针对高并发和大数据的方案，好比并发量高了，系统至少不能垮，并且针对每笔订单，处理能够稍做延迟，但不能丢数据。

     问题四，D公司须要在linux上搭建一套和产线同样的测试环境，在平时的开发过程当中，各业务组能够经过工具，在测试环境上部署或回退本项目的组件，这里，不只要搭建测试环境，更要经过jenkins等工具给各业务组搭建一套能便捷部署系统的工具。

     除了上述的问题以外，资深架构更像一个救火队员，好比在公司的业务体系里，任何一个团队报出的和架构相关的问题，好比调消息队列有延迟，调分库分表时报内存OOM异常了，或者因Dubbo底层而致使的延迟或OOM，资深架构得能亲自或带领手下解决具体的问题。

3 和高级开发相比，资深架构必定得精通的技能（或素质）

    其实高级开发和资深架构在须要掌握的技能方面，并没太大的差异，具体而言，能帮助实现性能优化的分布式组件和数据库组件（或者叫中间件）也就这么多，linux下的操做命令也就这么些，一些系统管理的工具，好比Maven，Jenkins，ant等的用法也不难。但和高级开发相比，资深架构的差异在于以下几点。

    1 资深架构解决的问题种类和数量要比高级开发多不少，所谓神枪手得靠子弹喂出来，有些问题，好比针对Kafka消息中间件的问题，资深架构一看日志就知道该怎么改，或者一看log4j错误信息就知道和其它哪些类有冲突了，又如，在搭建线程池时遇到了OOM问题，资深架构估计也能经过简单地看日志，也能快速定位问题所在。

    也就是说，资深架构已经积累了不少处理问题的经验，遇到通常问题时，无需再经过比较耗时的debug看问题根源，每每在脑子里已经存储了大量可能会致使问题的缘由，再经过查看关键日志便可定位到具体的代码点，而后就能很快地给出解决方案。

    2 在给出解决方案时，好比要上个分布式redis集群，或者上个消息中间件，对高级开发而言，每每会有不少试错的时间，好比上线后有某些功能点没调通，得经过Debug或查日志来逐一解决问题，或上线某个基于python的大数据分析系统后，虽然能知足基本的功能，但在某个场景（好比写日志线程并发量太多）里，可能会致使OOM异常。

    而对资深架构来讲，每每以前已经作过同类事情，因此能避免不少坑（少了不少试错成本和时间），并且因为对底层代码比较熟悉，因此哪怕出现比较疑难的问题（好比不能稳定重现），资深架构能经过看日志很快定位到具体的底层类，（而高级开发通常对此就一筹莫展了）。相比之下，资深架构的中流砥柱效应就能体现出来。

    3 资深架构通常具备对各组件的差异很是了解，好比作分布式队列，该先用Kafka仍是rabbitMQ，或者搭建数据库集群时，该用MySQL里的哪一种引擎。

    这样，在选型时，因为知道了各类方案的优缺点，因此能知道哪类方案更适合本业务系统，或者说，经过重写哪类组件的底层代码，能很快地搭建起知足本系统的中间件组件。这点，高级开发未必能作到。

    总结一下，资深架构得对关键组件的底层很是了解，而且精通针对某些组件（好比消息组件，分库组件）的实施和排查问题的能力，此外，资深架构的基本功也得很是扎实。

    1 debug能力就不用说了，得能熟练地经过linux命令，从各种日志中发现并解决问题。

    2 无需了解全部组件的底层代码（这太难了，也作不到），但须要了解一些经常使用组件的关键底层实现（好比Spring IOC或经常使用中间件） 方式，更得具有到组件内部jar里debug排查问题的能力。

    3 学习能力更不说了，和高级开发相比，资深架构更得了解哪类组件该学，并且，每一个组件内部的知识太多，好比Kafka的知识就能写至少一本书，对于资深架构而言，首先须要用较短的时间了解该组件（好比kafka）的架构以及和其它分布式组件（好比Flume）的整合方式，并且还得具有过滤知识的能力，即知道哪些知识不用学。这样一旦有需求，就能够较快地搭建出系统原型骨架，随后再逐步完善功能效果。 

4 对于程序员而言，如何高效地升级到架构或资深架构？

     当我还处在通常开发和高级开发的中间水平时，我认为我能很快地升级到架构师的水平，所谓无知者无畏。当我迈出升级的步伐时，刚开始，我忽然发现升级的难度很大，从而无处下手，由于平时我缺少实践架构师技能的实战机会。如今，经过一些努力，我虽然没有自信说本身必定达到了架构师的水平，但大多数架构师能干的活，我勉强能作好。并且我平时也在不断揣摩身边技术架构的思考方式和解决问题的方法，因此在这方面我自认为给出的建议不会耽误你们。

    首先是巩固本身基本功方面的建议。

    1 学再多的视频和材料，也不及动手实践一个案例。

    好比，你们在学习消息队列时，必定得动手搭建个环境，最好用虚拟机模式分布式的场景，这时可能就有同窗说了，环境太难搭建，怎么办？本身查资料，这种动手能力对架构师而言就属于基本功，若是这也作很差，那么也没但愿升级到架构师了。

    相似这样，你们可列个学习列表，网上升级到架构师的系列视频不少，质量高的也很多，都是别人的经验之谈，但若是就看理论，或者看关键点，这连架构师的面试都经过不了，更况且作实际的架构师的活。

    2 平时不能畏难，必定得多解决问题。

    在平时工做中，必定会出不少问题，并且很多是出在核心代码和底层代码里，这时就必定得经过看日志等方式去排查问题。 我知道，对不少想升级的高级开发而言，刚开始的时候必定很难，好比linux命令都不熟，或者效率很慢，别人都找出问题点了，本身才刚打开日志。其实你们都这样过来的，多查多练，最多三个月，动手能力必定能提高。 

    3 得锻炼本身在linux里（或在分布式环境里）部署系统部署组件的能力，尤为是部署集群的能力，在此基础上，经过各类工具能进行压力测试。

   好比仍是拿kafka来讲，搭建好集群后，就能够用kafka自带的Performance来作压测。其实若是是本身练习，压测的结果没太大的意义，但这个流程走下来，必定能对搭建环境，使用工具和看日志等技巧就很是熟悉了。

    4 尽可能培养本身的调优意识。说这个话很虚，具体而言，本身得能经过各类数据库日志（好比各sql的运行时间）来找出长sql，并在此基础上经过执行计划来优化，又如，能够经过dump文件和GC日志来看虚拟机的内存使用曲线，看内存主要耗在哪些方面，若是是本身代码没写好那还好办，若是是耗在（中间件的）底层jar包里的代码里，那也得知道解决方案。

    以上只是架构师所须要的基础技能， 其实若是能真正作到上述4点的话，你们离开架构师的水准也不远了，在此基础上，你们还得继续锻炼整合的能力。

    从纵向来说，须要进一步深化搭建集群的技能，好比能从底层代码的角度，了解集群的组成方式，这样的话，就能很清晰地了解到集群的扩展方式和性能调优势。

    从横向来说，须要进一步了解多种组件的整合方式，好比系统如何同日志组件整合，大数据分析工具如何同日志组件整合等。

    剩下的就是不断积累经验技能了。

5 在升级路上，如何避免一些坑

    我在平时还有机会接触一些大神，这些其实都是大神们的经验之谈。下面分享下在升级过程当中应当避免哪些坑。

    1 就像你们之前准备政治考试时，先准备大点，在保证大点不拉下的基础上，再详细复习每一个大点里的细节。好比，能够先了解Spring Cloud里有哪些组件，好比Ribbon能够用来负载均衡，Hystrix能够用来容错等，先把Spring Cloud里诸多组件先了解个大概，能用它们搭建成一个微服务体系后，再深刻了解其中每一个组件的细节，好比Spring Cloud Stream里Kafka配置细节。

    但我通过和多位架构师沟通，他们在升级时，多少都在这方面走过弯路，我本身有时候也会不知不觉陷入技术细节之中，而忘记我学这个技术的初衷。这里给你们的建议是，在明确学习目标后（好比要学Spring Cloud），刚开始别先本身闭门造车地为本身制定学习目标，能够先借鉴现有的视频讲解等的学习路线。制定学习计划时，以两到三天为单位，给本身定好一个短时间目标，等到Spring Cloud组件全都了解后，再经过运行通若干个案例来深刻了解组件的细节，这样就能控制住本身的学习步骤。

    2 千万别理论和实际脱节。这彷佛是废话，但我见过不少高级开发，平时就看视频和书，也不运行代码，结果进步的速度很慢。

    若是没机会实践架构技能怎么办？看本身组里有没有架构的活。若是也没有怎么办？（别嫌我啰嗦）回家本身准备环境，按视频里的搭建架构环境。必要时，你甚至能够经过跳槽来换得一个架构师的实践机会。

    3 架构师能够是技术控，但毫不能是完美主义，毕竟解决方案得和实际业务切合，并得考虑解决问题的成本。并且，架构师不能过于拘泥于细节，不能什么都事必躬亲，不少时候，得给出方向，或者把问题拆分红开发能理解的子问题，而后让手下人去干。 这彷佛和技术没有关系，这就要求架构师更具有和人打交道的能力了，这点将在本文的第6部分详细说明。

6 指导技术难于本身实现功能，再论资深架构的协调（或者说扯皮）能力的炼成

    很多开发者，尤为是资深开发者，或许都有这样的体会，对于一些功能，我宁肯本身作，而不是把它们拆分红若干个子功能再安排手下人去作。或者我宁肯去攻克一些技术的难题，也不肯意去和人扯皮，从而去制定架构里组件的选型方案。 

    能够这样说，架构师30%的价值来自他拥有的专业技能，30%的价值来自他分析和解决问题的能力，而40%的价值（甚至更高）来自于指导和协调能力。除去最后40%的价值，架构师其实和高级开发没什么差异。好比经过下面的例子，咱们能看到架构师为何还得具有指导和协调的能力。

    案例1：当架构师被要求改善本公司系统（好比是个应用网站）的调用性能时，他就得和多个组打交道，每每是，有些组未必肯支持（毕竟现有系统用得不错谁都不肯改），或者具体的改善点须要一些组来落实，这就至关于增长该组的工做量了。

    案例2：当架构师搭建好一套分布式缓存系统后，就得培训其它组的开发人员，让他们合理使用这套系统。

    案例3：又如架构师帮一个组解决了一个典型的OOM问题后，得把解决这个问题的思路向其余组推广，以便节省解决同类问题的时间。

    从上述案例中，咱们必定能感觉到在沟通，协调方面架构师须要掌握的技能水准。这方面说难不难，多练就行，但对IT开发而言，动嘴要比动手写代码要难。下面也给出些提高“动嘴”能力的技巧。

    1 首先得提高本身综合逻辑思惟的能力，这点能够靠多写博客，甚至写书来提高。其实写的时候，就至关于把本身要讲的内容用文字整理了一遍，这样无形中也提高了本身综合表达能力。

    2 在组内要多分享技术。其实刚开始分享时，必定不知道该说什么，甚至讲完后没人能懂（固然本身必定能懂），但多讲几回后，口头表达和与别人的交流能力也上去了。

    3  在遇到和其它组交流时（好比联调或沟通接口），必定得抓住机会多开口，刚开始的时候，估计很难让别人能接受本身的观点，或者本身有理也未必能讲清楚，但通过屡次协调后，就能让别人接受本身的观点，或者你们能达成彼此能接受的妥协方案。

7 总结，版权说明

    本人不想把这篇文章写成鸡汤文，并且更想在文内增长尽可能多的干货， 因此本文三易其稿。写完再回顾，感受文内更多的是我见到的和个人感觉，并且，本文从架构师所具有的技能入手，分析了架构师的高效升级方法，以及提高本身沟通能力的技巧，在每个要点里，都给了出具体的有可操做性的建议。

    因为出自实际项目，因此本身感受对你们多少有些帮助，若是你们有什么问题，或者须要看哪些方面的博文，请经过留言说明。

    本文在转载前，请和做者说明，同时注明文章来源，同时给出本人写的两本书的链接Java Web轻量级开发面试教程和Java核心技术及面试指南。

     再次感谢你们读完本文。