0

架构手到擒来,就能成为一流的架构师?

ADMIN 2019-07-01
89

为什么大部分工程师都无法成为优秀的架构师?做到纯精通 Coding, 是否能成为一流的架构师?如果你有这样的疑惑,就来听听蚂蚁高级测试开发专家懿泽怎么说。


图片来自包图网


今天,懿泽跳出大型互联网公司技术体系,从通用角度,谈谈对架构的理解,相信对想成为优秀架构师的同学一定会有所启发。


依托丰富的中间件、成熟的框架,在大型互联网公司做开发还是比较便捷的。


一线开发要做的是持续 CP(COPY、PASTE),不断从左边到右边的业务适配。


什么样的架构师才能称得上好的架构师呢?他至少得亲自编写 OR 维护一个上百万行代码的产品,体验一下没有架构的痛苦。


反复痛苦之后,才能深刻理解架构的好处,才会有架构意识,才能更快地提高。踩的坑多了,自然就懂得避坑了。


前瞻性


如何保持架构 3-5 年的领先?在实际项目中,经常见到有人把以前埋的坑填平,改个名字:XX 架构 1.0 ➝ XX 架构 2.0 ,就成了新架构了。


然而,只是在原本有问题的架构上打了个补丁,架构在本质上并没有变化,旧坑未平,新坑不断。


好的架构不是设计出来的,而是演进而来的。这就要求我们对技术保持敏感,时刻关注最新的技术,时刻保持自己技术栈的先进性,配合公司中长期战略,并充分考虑未来几年业务的变化和发展。


作为技术的引领者,就要成为导演而非演员,有一个梦想和愿景,让大家都能自动 Follow,保持情怀和信仰,并勇于创新。


懂产品


不了解产品的架构师无异于闭门造车,无法产生实际的产业价值,因此,永远不要脱离产品,好的架构师要清楚地知道自己要选择什么,做什么,放弃什么。


架构师通过业务目标作出自己的判断,并有所取舍,这一点非常重要,特别是当资源不足、进度紧张的时候,更要在关键时刻做决策,果断放弃部分内容。


架构师大多数时候都满身污垢,能在其中保持初心,保持平衡并不容易。当日活只有个位数的时候,不要谈千万级 DAU 的架构。


领域建模


在边界清晰、耦合低、内聚高的情况下,各种改动带来的成本就会比较低,领域模型划分尽量保证业务的高内聚和低耦合,划定领域边界,保证一个业务逻辑尽量在一个领域模型内部。


领域模型之间尽量减少业务来往,并保证一次业务流程涉及尽可能少的领域模型。


复杂系统领域建模能力:特别是业务域边界划分的问题,业务域边界会直接决定架构中相关系统的边界,如果业务域边界没有整理清楚,那么系统边界也会因为模糊从而带来一系列的问题。


技术能力


技术能力是最硬核的,前面提到写业务代码要做的是持续 CP,并不是说业务代码没有含金量,写好业务代码是最基础的一步。


在写好业务代码后,再一步一步,由浅入深,掌握设计模式、分布式、微服务化、性能优化,逐步熟悉并了解架构设计,然而架构之路是艰辛的、孤独的,注定需要付出更多。


技术能力也决定了架构的深度:操作系统、编译原理是最基础的知识,不管编程语言怎么发展,这些都是最 Base 的,在迷茫时沉下心来反复看。


当前主流的微服务架构,服务拆分粒度难以准确把握,需要遵循高内聚低耦合的基本原则,并清晰定义业务边界和数据接口,特别要避免过度设计。


设计模式有一个共性,就是如何让程序设计巧妙、合理地应对未来各种大概率可能的变化,包括需求的变化,技术的变化等。


Docker 容器化能够将 SA 的经验标准化并固定下来,有别于传统虚拟机,它并不去虚拟任何硬件,而是对硬件资源在不同的 Docker Container 之间作了隔离。


智能化依托大数据和算法,在解一些特定的业务场景时有效果,但不可过度,放眼望去,现在很多产品和工具无不带着智能两字的,手里拿个锤子,看什么都像钉子。


高可用、高性能


高可用、高性能是一个优秀的架构必须具备的,解决互联网架构中的高并发和高可用的问题,也是最能体现工匠精神的。


在架构设计之初就应该考虑容灾能力、资损防控、自愈能力等。系统上线前 OR 大促前,需要进行各种调优:性能调优、Web 调优、JVM 调优、DB 调优、强弱依赖治理等。


并通过主动发现手段(全链路压测、容灾演练、资损演练)发现架构 OR 设计的不合理的地方。


优秀的架构不是设计出来的,而是不断打磨演进而来的。


后记


在某大型通讯公司干了八年开发之后,我转到阿里技术风险部。


回想那八年,是一段饥渴的岁月,也没有觉得有多苦,看到优秀的设计、架构,会整夜分析疑难问题,反复去编写代码,困了累了就在桌子下面的行军床上睡觉。


也在编程考试中失利,觉得自己不适合做开发,后来在导师耐心的指导下,重拾信心,信奉笨鸟先飞原则,并比以前更注重技术内部实现细节,随后在大部门(1000 多人)编程竞赛中拿了第二名。


破土重生之后,更致力于大网效率、瘦身(运行时内存优化、堆内存优化、应用大小、应用启停速度、JVM 优化等等)、疑难问题攻关、新技术探索等。


最喜欢泛型编程与 STL,再结合设计模式,写出来的代码圈复杂度低,阅读起来也特别舒服。


记得当时有同学改掉了职责链设计模式,改回 if else 实现形式,我去打了一架,把代码全部回滚回来。


写代码容易,真正能守护好代码,却不容易。当时应用部署在 Sun 的 Solaris 系统上,在分析疑难问题时,发现学的知识还远远不够,又啃了很多操作系统、编译原理,汇编源代码和 CPU 指令集...


最近几年负责新产品研发,也深刻地认识到技术永远是为业务服务的,如果为了技术而技术,那是自 High,牛逼的技术都是需要通过业务价值来体现。产品设计以用户体验贯穿始终,并依托着技术让用户尖叫。


作者:懿泽

编辑:陶家龙、孙淑娟

出处:转载自微信微信51CTO技术栈

精彩文章推荐:

“分布式事务”,这次彻底懂了!

我是技术总监,我确实答不出那么多技术细节!

阿里技术专家:优秀工程师是怎样炼成的?

最后修改时间:2020-05-08 00:20:53
「喜欢文章,快来给作者赞赏墨值吧」
文章转载自ADMIN,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论

关注
最新发布
暂无内容,敬请期待...
数据库资讯
最新 热门 更多
本月热门
近期活动
全部
暂无活动,敬请期待...
相关课程
全部