跳出大公司技术体系谈架构

导读：为什么大部分工程师都无法成为优秀的架构师？做到纯精通 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，牛逼的技术都是需要通过业务价值来体现。产品设计以用户体验贯穿始终，并依托着技术让用户尖叫。

跳出大公司技术体系谈架构相关推荐

如何解读《微信技术总监谈架构：微信之道——大道至简》
[http://www.52im.net/thread-201-1-1.html]学习一下一.前言最近在朋友圈看到有人分享腾讯微信技术总监周颢的一个技术报告,题目是< 微信技术总监谈架构:微 ...
【大数据】企业级大数据技术体系概述
目录产生背景常见应用场景企业级大数据技术框架数据收集层数据存储层资源管理与服务协调层计算引擎层数据分析层数据可视层企业级大数据技术实现方案 Google 大数据技术栈 Hadoop ...
为什么有些大公司技术弱爆了？
点击上方"码农突围",马上关注这里是码农充电第一站,回复"666",获取一份专属大礼包真爱,请设置"星标"或点个"在看&quo ...
好问题：为什么有些大公司技术弱爆了？
戳蓝字"CSDN云计算"关注我们哦! 本文整理自知乎上的同名讨论帖:<为什么有些大公司技术弱爆了?>,版权归原作者所有,原文地址:www.zhihu.com/quest ...
为什么有些大公司技术却弱爆了？
程序员的成长之路互联网/程序员/技术/资料共享关注阅读本文大概需要 15 分钟. 来自:www.zhihu.com/question/32039226 tips:文末有好书推荐~ 有网友提问: ...
知乎高赞：为什么有些大公司技术弱爆了？
点击上方 Java团长,选择设为星标优质文章,及时送达本文整理自知乎上的同名讨论帖:<为什么有些大公司技术弱爆了?>,版权归原作者所有. 原文地址: https://www.zhih ...
有枚举他不用，非要把值写死——为什么有些大公司技术弱爆了？
本文整理自知乎上的同名讨论帖:<为什么有些大公司技术弱爆了?>,版权归原作者所有原文地址:www.zhihu.com/question/32039226 有网友提问: 今年年初,到一家互 ...
建立大数据技术体系学习的新思维
一. 开篇随着大数据时代的到来,各类数据都在惊人的增长,形成了WEB与社交媒体数据.机器对机器数据.大体量交易数据.生物计量数据和人工生成数据的五大类型.数据越来越不满足于处于静止状态,数据越来越处 ...
[技术讨论]谈架构设计：如何界定前后端，前端是否需要数据库？
[正常]兼职 9:47:11 我问个问题,如何界定前台与后台的功能范围?什么是前台?什么是后台? [惜言]+群 9:47:39 我基本用协议来分 c<->s c就让前端码农搞,s就让后 ...

跳出大公司技术体系谈架构

跳出大公司技术体系谈架构相关推荐

最新文章

热门文章