目前在一家互联网公司工作一年多，接触过很多技术和业务架构师。自从我升级到架构师，我能直观地感受到高级开发和架构之间的差距。而且，对于如何从高级开发升级到架构师，我现在有了更多的亲身体验。本文将结合本人在互联网公司的工作经历，与大家分享架构师在工作中的关注点和进阶开发，可以给大家带来升级架构师的灵感。差距首先体现在工作态度上。立志升级为架构师的架构师或高级开发人员，在日常工作中必须具备以下特点。1、出现问题时，要第一时间调查分析问题，即使问题看似与自己无关，也不要试图逃避问题。2、上班的时候基本没有时间看无关的网页或者手机。即使手头没有工作，我还是看看项目框架或者技术，或者想想怎么优化。3.如果有问题，我们通常会深挖，即使不能从根本上解决问题，我们通常也会找到根本原因，而不是想办法绕过它。这点我深有体会，别说互联网公司的架构师都是这样，就是表现出色的高阶开发人员也是如此，因为这些可能是在互联网公司生存的必要条件。当然，我也见过擦肩而过的人，但一般晋升空间都比较小，或者升不上去，或者无法在外面竞争更高薪的职位。技术方面，架构师的基本功和高级开发的技术盘点，大多集中在“单机版”的代码上，只要在本机完成开发任务，再进行一些调试即可技能可以用来跟踪代码和使用数据库。没关系。超前发展的“超前”体现在两个地方。首先，你对业务比较熟悉。不过话又说回来了，换公司的话，生意值多少钱？二是对代码底层有更好的理解，比如理解SpringBoot的启动步骤。架构师的基本功高于高级开发。对比一下我见过的架构师和高级开发的各种表现。你可以看到两者之间的区别。1、由于大多数高级开发都是调试单机版的程序，所以查看日志的时候一般都是在本地查看，或者用工具把日志下载到本地Windows，然后用a搜索关键字文本工具。但是对于架构师来说，这种日志检查的效率实在是太低了，而且大部分都是通过less、grep等命令查看的。也就是说，架构师必须熟悉linux的操作和运行。2、高级开发一般不需要考虑打包部署等问题，但架构师必须在优化分布式组件之前对项目进行打包。因此，架构师需要对项目打包（如maven命令）、项目部署（如jenkins或uDeploy）和项目质量管理（如继承sonar）有所了解。如果项目还需要部署在云平台上，可能需要了解Docker或者k8s之类的工具。也就是说，除了会写代码，架构师至少要了解项目的集成和部署。3、架构师要多了解组件集群，比如分布式组件、云平台集群，反正不是单机版的。可能高级开发者也会知道一些Dubbo、缓存等组件，但是架构师要掌握这些组件的分布式部署，也就是如果一台机器出现故障，其他热备机器应该如何顶上去。除了代码开发，架构师更要关注压力测试、方案评估、系统上线等实施点。架构师必须有一些与产品相关的意识。这些意识必须始终贯穿他们的工作。这与高级开发相比。建筑老师宝贵的技术。1、对于架构师来说，仅仅做产品（或相关的组件模块）是不够的，还要进行压力测试。压测结束后，架构师还要挑三拣四，想办法优化点。2.架构师必须从当前的同类产品（或竞争产品）中学习。在性能方面，只有更好并不是最好的。比如一个模块当前的运行时间是2秒，一定要压缩到1秒。秒，这需要架构师精通各种技术。3.架构师必须评估各种风险，尤其是在推出新版本时。发布时间就像一个通行证。首先，新旧代码必须兼容，以免造成服务中断。第二，风险要可控，各种基于代码或数据库的回滚或处理计划，一旦有风吹草动，必须立即回滚。也就是说，架构师首先要保证系统能够顺利上线，其次，在开发过程中，要提前考虑线上的各种风险，时刻考虑优化的方向，而高级开发则不没有这样的要求。架构师是某个领域的中坚力量，高级开发还停留在“干活”的阶段。计划。也就是说，架构师虽然不会像项目经理那样专注于项目管理，但也需要有带人的经验。一方面，他可以让团队成员贯彻他的设计理念。对于问题，高级开发还是可以退的，架构师应该负责解决。这里我列举一些我见过的架构师常见的工作场景。1、架构师手机上有各种群，有业务类的，也有技术类的。要求是@your必须尽快解决。如果客户不是@你，虽然没有@，但反映的问题与你有关，必须立即解决。因此，大部分架构师都养成了手机不关机，半夜醒来查看手机的习惯。而高级开发也可以等架构师分配工作。2、一旦出现问题，比如业务功能出现问题，或者系统运行时出现OOM等性能问题，或者通过监控发现关键指标出现下滑，需要架构师第一时间介入。3、本组或分管领域其他组出现业务、技术等问题，应协调解决。4、更多时候，架构师要和相关人员（产品、其他组或系统运维人员等）开会，评估各种方案的实施方式。在制定计划时，每个小组都会有私心，希望为自己的小组做更少的改变。这时，建筑师不得不就各种方案进行协商或妥协。架构师在这方面的工作量甚至超过了编写代码的工作量。经常看到很多架构师上班开会，只有下班或者周末才有自己的时间写代码。系统发布阶段最能体现架构师和高级开发人员的水平。在高级开发者眼中，系统发布只是将最新的代码和脚本部署到生产服务器上。我之前也是这么想的。但在这个阶段，架构师需要考虑以下几个方面。1.上线期间，新旧代码共存。比如灰度放出后，部分流量会被切到新代码。这时候怎么保证兼容性。2、发布时的回滚步骤，如果涉及到数据库回滚，需要准备各种SQL。3.在数据清洗和数据迁移步骤中，新增功能后，数据清洗的范围是全局的，架构师不得不考虑性能问题。4、系统上线后，那些关键步骤应该进行监控管理，系统管理后异常阈值应该如何设置？由此可见，架构师要掌握系统运维+综合性能调优+系统监控的能力，这对于高级开发来说其实是很low的。我遇到的天才架构师和他们先进的方法在进入互联网公司之前，我也因为写了两本书而遇到了一些人才，但是进入互联网公司后，我发现第一批人才的数量远远超过预期，而且他们都很年轻，第二好的人在某些领域比我想象的还要精通。单说我师傅，除了工作态度好、责任心强、乐于助人的软实力外，读取日志、调试代码打成jar包调试的硬实力也很强大。更重要的是，对于一些分布式组件，它可以达到出版畅销书的地步（至少10,000份）。而我师父的师父，更是业内的大腕。他不仅出版了很多关于Spring的书籍，最近还录制了极客世界的视频课程。跟着牛仁学，我在互联网公司提升能力的速度也不慢，在结构上也有了一些进步。根据我个人的经验，我怎样才能快速提高？1.当然，你一定要熟悉业务，否则就没法工作，但是熟悉了之后也不能沾沾自喜，还要看技术（尤其是有价值的技术）如何与业务结合。如何熟悉业务？没有捷径，一是看文档，二是看代码，三是问人，四是看上下文系统，不是自己的领域，系统会称呼。2.如果有问题，不要强推。检查日志和其他方法。如果不行，就得调试一些组件包看看。当排查问题的次数和种类积累到一定程度后，我或许就可以无师自通了。我遇到的一些大牛，基本都是有问题就去查，从不推卸责任。3、人的眼界毕竟是有限的，人脉未必多，所以要多和有才华的人打交道。找好人帮你排查问题的时候，自己要多看，平时多和好人交流。好心人往往会给出学习方法和学习要点，好心人会帮忙指导各种技术中的坑。4、多参与本领域以外的工作，如压力测试、系统部署等。工作时不能只停留在技术领域，更要关注项目立项、组件部署，甚至项目部署。其实很多有才华的人不仅做过开发，还做过系统集成和系统运维。这样一来，之前对分布式组件的了解就不仅仅停留在“会开发”的地步了。有时即使你可能没有被分配到这种工作中，你也必须多参与。通过哪些渠道可以获得架构师相关的帮助文档和实践机会1、目前网上有很多高级架构师的资料，包括分布式组件，包括云计算等等，甚至还有架构师相关的面试技巧。对此，大家一定要多看一些有框图的业务实践相关的文档。2.理论必须与实践相结合。如果只是看架构师相关的文档，会很枯燥，很容易半途而废。我亲身经历过这一点。如何组合呢？最好去互联网公司锻炼一段时间，即使在里面做高级开发工作，也一定有机会接触到架构师的技能。3、要多和人打交道，小到可以和自己的团队成员多交流，中到可以和自己公司的相关人才多交流和请教，大到可以和一些大人物多交流在互联网上。我意识到这些交流永远不会白费。除了获得技术交流的机会，还能掌握一些赚钱的渠道和方法。综上所述，升级为架构师不仅仅需要提升技术，升级为架构师离不开技术的提升，但架构师最终还是要让技术解决实际的业务问题，所以在升级的过程中，我付出的更多关注“技术+案例”信息，比如我会搜索“dubbo案例”之类的，深入挖掘技术的实现。而且，架构师要和人打交道，这比和技术打交道要困难得多，因为有各种各样的人。那么升级为架构师后，会带来哪些好处呢？当然有很多钱，不仅如此，架构师往往是某个领域的专家，所以在这个领域可以用技术换钱，比如卖视频教程。最重要的是，升级为架构师所积累的一些软技能，如责任感、时间管理方式、高效的工作方式、思考问题的方式等，是最有价值的。
