网站架构师的工作内容( 架构师和高级开发如何升级到架构师？（干货分享） )

　　网站架构师的工作内容(

架构师和高级开发如何升级到架构师？（干货分享）

)

　　作者|hsm_computer

　　目前在一家互联网公司工作1年多，接触过很多技术和业务架构师。既然是升级架构师，可以直观的感受到高级开发和架构的差距，高级开发升级架构师怎么样，现在有了更多的切身体验。

　　本文将结合本人在一家互联网公司的*敏*感*词*，与大家分享架构师和高级开发在工作中的重点，能给大家带来架构师升级的启示。

　　差距首先体现在工作态度上

　　立志升级为架构师的架构师或资深开发者，在日常工作中必须具备以下特点。

　　1. 当出现问题时，尽快调查分析问题，即使问题看起来与你无关，而不是试图回避问题。

　　2. 上班的时候基本没时间看不相关的网页或者手机。即使我没有工作，我还是会看项目框架或技术，或者考虑如何优化。

　　3. 有问题的时候，一般会深入挖掘。即使你不能从根本原因解决问题，你通常会找到根本原因而不是试图绕过它。

　　我对此有深刻的理解。别说互联网公司的架构师都是这样，就算是表现好的高层开发也会这样，因为这些可能都是互联网公司生存的必要条件。

　　当然，我也看到过路过，但总体来说成长空间比较小，或者不能进一步提升，或者无法竞争外面的高薪工作。

　　技术上，架构师的基本功和进阶开发的技术盘点

　　一般开发多集中在“*敏*感*词*”的代码上，只要在本机上完成任务，再进行一些调试技巧，代码可追溯，数据库就可以使用.

　　而先进发展的“先进”体现在两个地方。首先，你对业务比较熟悉，但话说回来，如果你换了公司，业务值多少钱？二是对底层代码有进一步的了解，比如了解Spring Boot的启动步骤。

　　架构师的基本功高于高级开发。来对比一下我看到的建筑师和高级开发的各种表现。你可以看到两者之间的区别。

　　1. 由于高级开发主要是为了调试单机程序，所以在查看日志的时候，一般都是在本地查看，或者使用工具将日志下载到Windows本地，然后使用文本工具查找关键字。

　　但是对于架构师来说，这种日志检查的效率太低了。他们中的大多数都使用less 和grep 之类的命令。也就是说，架构师必须熟悉Linux的操作。

　　2. 高级开发一般不需要考虑打包部署等问题，架构师在优化分布式组件之前必须打包项目。

　　所以架构师需要对项目打包（如maven命令）、项目部署（如jenkins或uDeploy）、项目质量管理（如继承sonar）有所了解。如果项目需要部署在云平台上，你可能还需要了解Docker或k8s之类的工具。

　　换句话说，架构师除了写代码，至少要了解项目的集成部署。

　　3. 架构师需要了解更多组件集群和其他内容，比如分布式组件，云平台集群，反正不是*敏*感*词*。

　　或许高级开发者也会对Dubbo、缓存等组件了解更多，但架构师要掌握这些组件的分布式部署，即如果一台机器出现故障，其他热备机器该如何上手。

　　架构师除了开发代码，更要关注压力测试、程序评估、系统上线等实现点

　　架构师必须有一些与产品相关的意识，而这些意识必须始终贯穿于工作之中。与高级开发相比，这是架构师最有价值的技术。

　　1. 对于架构师来说，产品（或相关的组件模块）不仅仅是要做的，还需要进行压力测试。压力测试结束后，建筑师必须挑选鸡蛋中的骨头。优化点。

　　2. 架构师必须向当前的同类产品（或竞争产品）学习。在性能方面，只有更好，没有最好。比如当前一个模块的运行时间是2秒，他们要千方百计压缩到1秒，这就需要架构师精通各种技术。

　　3. 架构师要评估各种风险，尤其是新版本上线的时候，发布就像一扇门。首先，新旧代码必须兼容，不会导致服务中断。其次，必须提前控制和设计风险。各种基于代码或基于数据库的回滚或处理计划必须在出现混乱时立即回滚。

　　也就是说，架构师首先要保证系统能够顺利上线，其次，在开发过程中，要提前考虑各种上线风险，时刻考虑优化的方向。高级开发没有这样的要求。

　　架构师是某个领域的中坚力量，高级开发还处于“工作分配”阶段

　　架构师不仅是技术控制者，还要结合业务，与相关团队合作，制定出目前可行且实施风险较小的各种解决方案。

　　也就是说，架构师虽然不像项目经理那样专注于项目管理，但他也需要有带人的经验。问题，高级开发仍然可以缩小，架构师应该负责解决它们。

　　这里我列出了一些我遇到的建筑师的常见工作场景。

　　1. 架构师手机上有各种群，包括业务和技术相关的。要求是@你的必须在第一时间解决。

　　如果客户不是@你，虽然没有@，但报告的问题与你有关，必须立即解决。因此，大多数建筑师都养成了保持手机开着，半夜醒来看手机的习惯。

　　高级开发也可以等待架构师分配工作。

　　2. 如果出现任何问题，比如业务功能问题，或者系统运行时OOM等性能问题，或者通过监控发现关键指标下降，架构师需要第一时间介入。

　　3. 您自己的小组或其他小组的任何问题，包括业务和技术问题，都应通过协调解决。

　　4. 更多时候，架构师要与相关人员（产品、其他组或系统运维人员等）开会，评估各种解决方案的实施情况。

　　在制定计划时，每个群体都会有自私的意图，希望在自己的群体中少做一些改变。这时，建筑师不得不就各种方案进行协商或妥协。

　　架构师在这方面的工作量甚至超过了编写代码的工作量。我经常看到很多架构师上班的时候开会，只有下班后或者周末才有自己的时间写代码。

　　系统发布阶段最能体现架构师和高级开发水平

　　在高级开发的眼中，系统发布只是将最新的代码和脚本部署到生产服务器，正如我之前所想的。但是在这个阶段，架构师需要考虑以下几个方面。

　　1. 发布期间，新旧代码并存。比如灰度发布的时候，部分流量会被切到新的代码上。这个时候怎么保证兼容性。

　　2. 发布时的回滚步骤，如果涉及到数据库回滚，必须准备好各种SQL。

　　3. 在数据清洗和数据迁移的步骤中，新功能引入后，数据清洗的范围是全局的，架构师不得不考虑性能问题。

　　4. 系统上线后，监控的关键步骤有哪些，管理后提示异常的阈值如何设置？

　　由此可见，架构师要掌握系统运维+综合性能调优+系统监控的能力。这对于高级开发来说实际上是非常低的。

　　我遇到的伟大建筑师以及他们是如何进步的

　　加入互联网公司之前，我写过两本书，认识了一些伟人，但加入互联网公司后，我发现第一批伟人的数量远远超过预期，而且都很年轻。第二伟人在某些领域是精通的。学位超出了我的想象。

　　比方说我师父工作态度好，责任心强，乐于助人。他也有很强的硬实力，可以通过看日志来调试jar包中的代码。更重要的是，对于一些分布式组件，它可以达到一本畅销书（至少10000本）已经出版的地步。

　　而我师父是业内大牛。他不仅出版了大量关于Spring的书籍，最近极客世界录制的视频课销量也超过了2万，估计后期至少有5万+。

　　跟着牛仁学，我在互联网公司的能力提升也不慢，在架构上也有了一些进步。根据我的个人经验，我怎样才能快速提高？

　　1. 当然，你要熟悉业务，否则不能工作，但熟悉了也不能沾沾自喜。这取决于技术（尤其是有价值的技术）如何与业务集成。

　　如何熟悉业务？没有捷径可走。首先看文档，第二次看代码，第三次问人，第四次，查看域外的上下文系统，但系统会调用。

　　2. 出了问题就不要push了，看日志等看看，还是不行，就得去调试一些组件包了。

　　当排查问题的数量和类型积累到一定程度时，我也许可以在没有老师的情况下理解它们。我遇到的一些大牛，基本都是遇到问题就调查问题，从不推卸责任。

　　3. 毕竟个人眼界有限，接触的人可能不多，所以要多和厉害的人打交道。

　　找牛人帮忙排查问题，要多看一旁，还要和牛人沟通。牛人经常给出学习的方法和要点，牛人会帮忙指导各种技术的坑。

　　4. 参与更多自己领域之外的工作，比如压力测试和系统部署。工作时，不要只停留在技术领域，还要注意项目启动、组件部署甚至项目部署。

　　事实上，很多人才不仅做过开发，还做过系统集成和系统运维。这样，之前的分布式组件等知识就不会仅仅停留在“开发”这一点上。有时，即使您可能不会被分配到此类工作中，您也必须多参与。

　　通过什么渠道可以获得架构师相关的帮助文档和实践机会

　　1. 目前网上有很多高级架构师资料，包括分布式组件，包括云计算等，甚至还有架构师相关的面试技巧。在这方面，您必须阅读更多带有框图和与业务实践相关的文档。

　　2. 必须理论联系实际。如果只看架构师相关的文档，会很枯燥，很容易中途放弃。这方面我有自己的经验。

　　怎么结合呢？最好去互联网公司锻炼一段时间，即使在里面做高级开发工作，也绝对有机会接触到架构师的技能。

　　3. 与人打交道的地方很多，小到与自己的团队成员沟通，小到与公司相关人才沟通征求意见。如果你有更大的范围，你可以和互联网上的一些大牛交流。

　　我明白这些交流永远不会白费。除了获得技术交流的机会，我还可以掌握一些赚钱的渠道和方法。

　　总之，升级为架构师需要的不仅仅是升级技术

　　诚然，升级为架构师离不开技术的提升，但架构师最终要的是技术来解决实际的业务问题，所以在升级的过程中，我更加关注“技术+案例”的信息，对于例如，我会搜索“Dubbo case”之类的，以便更深入地挖掘该技术的实现方式。

　　而且，建筑师要与人打交道，这比与技术打交道要困难得多，因为有各种各样的人。

　　那么升级为架构师后，会带来什么好处呢？

　　当然，还有很多钱。不仅如此，建筑师往往是某个领域的专家，所以他们可以用技术来换取这个领域的钱，比如卖视频教程。

　　最重要的是，升级为架构师所积累的一些软实力，如责任感、管理时间的方式、高效的工作方法和思考问题的方式，是最有价值的。