50 lines
7.9 KiB
Markdown
50 lines
7.9 KiB
Markdown
# 结束语 | 一个架构师的一天
|
||
|
||
你好，我是李智慧。
|
||
|
||
时间过得真快，聊着聊着，这个专栏就到了尾声。恭喜你完成了这一阶段的学习，向架构师又迈进了一步！
|
||
|
||
在这里，我想问你一个问题：学完这个专栏，除了架构知识以外，你对“架构师”这个角色有了哪些新的认知呢？毕竟这个专栏的Slogan就是“附身”大厂架构师，我还是非常希望能为你代入架构师视角，体验这个角色的高光时刻。
|
||
|
||
我们这个专栏的案例，大多是一些庞大的系统，每个案例在真实世界中，都对应着一家数百上千亿美元市值的公司，需要数千名工程师开发，需要部署数万台服务器的系统。这样的系统不可能是由一个架构师设计出来的，正如开篇词所言，我们的设计是一种架空现实的设计。学习这种架空现实的设计，可以帮助你站在上帝视角，俯视一个个庞大系统的核心关键技术和整体架构，进而帮你构建起全局化的思维方式，而这正是架构师最重要的竞争力。
|
||
|
||
现实中，拥有一个庞大系统的公司通常有上百名的架构师，他们的日常工作也不是去设计整个系统，而是在自己负责的模块或者子系统内修修补补。所以在结束语里，相比于前面宏大的设计，我想做点“接地气”的内容，带你“穿越”成一位真正的架构师，感受架构师这个角色典型的一天。
|
||
|
||
我们以某大厂商家管理后台系统的架构师为例。商家管理后台是电商卖家的后台管理系统，卖家上下架商品、投放广告、查看运营数据等操作都在这里完成，是面向卖家的核心系统。商家管理后台开发部20多个人，分了4个开发小组。
|
||
|
||
> **9：20** 到公司，翻看昨天的邮件和聊天记录，看看有没有遗漏的事情。昨天下午数据库连接阻塞，连累应用服务器响应超时，焦头烂额搞了一下午，很多聊天消息都没来的及处理。翻了一下还好，没有错过什么重要的事情。
|
||
|
||
> **9：30** 开部门小组长晨会，开了10分钟会，今天晨会时间控制得不错。
|
||
|
||
> **9：45** 作为主讲人主持“商家管理后台架构重构设计”部门评审会，这次重构是商家后台最近两年最大的一次重构。已经和几个开发小组长还有核心开发人员已经讨论过几次了，这次做部门评审，事实上是做重构宣导，要让所有开发人员都统一认识，所以会上争议不多，开得比较顺利。另外，这次重构设计画了很多UML模型图，评审的时候也趁机给大家再普及了下设计建模的重要性和方法。
|
||
|
||
> **11：00** 参加另一个部门的架构评审会，会上他们部门的架构师和一个开发组长吵起来了。晕，自己内部还没统一意见，就不要拉别的部门的人来看戏了。开会是用来统一意见和思想的，不是用来解决问题的，问题要提前解决。趁他们吵的间隙，上极客时间看看有什么有意思的课程，发现《李智慧 · 高并发架构实战课》挺有意思，订阅了。
|
||
|
||
> **12：00** 午饭。
|
||
|
||
> **13：30** 这次架构重构引入DDD（领域驱动设计）方法，上午的评审主要从DDD战略设计的角度对架构进行重构。DDD战术设计感觉不太好掌控，先暂时不在部门推广了。自己先写个DDD代码Demo练练吧，用哪个功能做Demo呢？红包管理功能吧。上半年公司架构师委员会例会上，也有几个部门的架构师提出要搞DDD，结果没了动静，这个螃蟹看来还得自己吃。
|
||
|
||
> **15：11** 一个开发同学过来讨论技术问题，聊了十来分钟，越聊越觉得不对劲，把产品经理也叫过来讨论，确定这个需求是有问题的，先暂时不开发，产品经理回去重新梳理需求。继续写Demo代码。
|
||
|
||
> **16：03** 收到运维部门的会议邀请，明天上午10：30复盘昨天的数据库访问故障。麻烦，这个故障看起来是数据库失去响应，其实是个程序Bug，线程阻塞导致数据库连接耗尽。这个故障影响不小，责任主要在我们部门，看看会上怎么说，能不能让运维部门也承担一点故障分，毕竟他们数据库管理也没做到位。也不知道明天参加会议的运维是哪个，好不好说话？继续写Demo代码。
|
||
|
||
> **16：42** 收到监控报警通知，商品上架数异常波动，低于正常值60%。是商品上架服务出问题了？赶紧打开监控系统，上架服务系统指标正常；打开日志系统，异常日志数正常。什么情况啊？问问运维。哦，原来是监控数据消息队列消费服务出了点问题，数据统计有误，触发报警，虚惊一场。继续写Demo代码。
|
||
|
||
> **17：08** 公司负责培训的同事发来消息，问能不能做个性能优化方面的内部讲座，面向全公司的开发和测试人员。可以呀，什么时候讲？下周五。好的。时间有点紧啊，不做Demo了，先做讲座PPT，毕竟公司级的讲座，难得的提升技术影响力的机会。不过，性能优化这个话题有点大啊，从哪方面入手呢？对了，上午看到的李智慧的专栏里面有一篇性能优化的文章，看看他怎么讲。可以，就按这个文章的思路准备讲座大纲。离下班还有一个多小时，做PPT来不及了，先收集下PPT素材，案例部分用公司内部的，理论部分Google一下，不错，就这样……
|
||
|
||
上面就是这位架构师一天的经历，你认为他的工作怎么样呢？大部分人都希望工作轻松一点，你觉得文中这位架构师的工作是否轻松？以及什么样的工作是轻松的呢？
|
||
|
||
首先，**清闲的工作未必是轻松的**，工作不忙、无所事事，会让人觉得自己失去价值，进而产生焦虑，最后并不轻松。轻松的工作应该是自己做的事情有意义、有价值，还能在工作中不断获得进步；同时工作又游刃有余，自己可以掌控工作，而不是被工作驱赶着疲于奔命。
|
||
|
||
**架构师最核心的事情是要控制技术局面，让事情有节奏地推进，不要鸡毛蒜皮，做决策的人越是忙忙碌碌，团队效率越低**。文中这位架构师做到了这一点，他基本上掌控了他的工作，而不是让工作push他。大部分时间，他可以按照自己的节奏安排工作；突发的情况，他也能比较从容地应对。
|
||
|
||
他做事情看起来似乎毫不费力。事实上，他要处理的很多事情，都是一些既复杂又困难的事情，是别人搞不定了才到了他这里来的。他既要考虑各种人际关系，又要用技术做出判断，还要对判断结果负责，而且要有威望让别人听他的。此外，他还有时间学习、有时间写代码、有时间做设计、有时间扩展自己的影响力，还能按时下班。
|
||
|
||
其实，**做事情要想看起来毫不费力，必须要在看不到的地方费很大力气**，进行很多的积累。你也可以问下自己，自己现在每天都做些什么？多长时间用来学习，有没有帮助别人解决问题，有没有考虑积极做些分享扩展自己的影响力，还是只是低下头盯着自己脚下的这块巴掌大的地方呢？
|
||
|
||
当然，在工作中能达到这位架构师这样的境界并不容易，也不是成为架构师就可以这样工作。但是只要你想往上走，就需要不断学习，有目的地在工作中提升自己，并且主动找机会展示自己的综合能力，构建自己的影响力。相信最终你一定可以掌控自己的工作，还有人生。
|
||
|
||
希望这个专栏可以在你进步的路上提供帮助，使你对更宏观的知识和实践建立起感性的认知和清晰的目标，然后不断夯实自己的实践能力、拓宽自己的影响力，最后成为你想成为的自己。
|
||
|
||
[](https://jinshuju.net/f/x0MpWT)
|
||
|