技术成长四个阶段需要的架构知识

109 阅读 0 评论 72 点赞

我是靠谱客的博主悲凉大雁，最近开发中收集的这篇文章主要介绍技术成长四个阶段需要的架构知识，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

今天的下午茶活动，与很多技术圈的老朋友详谈甚欢，听到了几位老朋友的分享颇为受益，我也给小伙伴分享我的一点心得。

技术成长需要什么架构知识？

初入工程师这行时我有一个梦想，希望具备强大技术架构能力，让服务于亿级用户的产品稳定运行于其上，今天我看到身边很多架构师都走到这一步。

但对于当年刚入行的我来讲，要达到这一点还只是个梦想，因为那时我并不知道应该怎样构建这样的架构，甚至连需要学习哪些知识都不知道。

我相信很多工程师在成长的路程上也跟我一样，会被一个大大的问号困扰很久：如果要成为一个大牛，应该需要什么样的技术路线？

今天跟大家分享下通过观察身边的案例，我总结的一些在技术成长方面的心得体会。

架构师是怎样炼成的？让我们从圣斗士说起。

技术人成长之路四阶段

小时候有一部我特别喜爱的动画片——圣斗士星矢，现在来看，这俨然就是一个技术大牛的成长之路。（小编：校长果然是老司机了：）

1. 从接受训练成为圣斗士，就像刚刚入门的初级工程师

大多数的应届毕业生，虽然之前学习了编程语言及算法基础，能用代码解决一些简单的业务问题，但编码规范与真正的业务开发实践的要求还是有些距离。

个别彪悍的同学，毕业时能力已经达到中高级工程师的水平了，就可以略过这个阶段。

这一阶段最重要的是夯实编程基础，养成好的开发习惯。比如：基础库API的使用、并发线程机制、基础算法、优雅的单元测试等。

这个阶段与其挑选薪资，不如挑选合适的锻炼环境，比如寻找有良好的技术氛围、有合适的导师，有挑战的项目的团队。

2. 到获得青铜圣衣打败暗黑圣斗士，就像中/高级工程师

工作 1 – 3 年的工程师，在实战中积累了一些开发经验，了解常用技术框架原理并可以在实际工作中快速搭建服务；了解常用的设计模式，让程序的扩展性变得更好，也可以开始胜任解决相对复杂的一些问题，负责中等规模的服务开发和维护；

这一阶段最重要的是寻找可能的机会进行架构实践，学习别人的架构经验，最终总结吸收为自己的经验或理论。多研究下典型场景的架构设计很重要，比如：典型社交场景的微博架构，典型电商场景的京东淘宝架构等。

如果公司有合适的历练项目，则多向项目中的前辈学习。但更多的人遭遇的可能是不那么理想的环境，参与的项目不需要太高技术含量，身边也没有资深的前辈学习。

这种情况下，在满足项目交付时间的前提下，可以更主动去积极寻找项目中可以值得优化的点，通过网上阅读的案例，引入更合适的技术来解决，给自己创造使用一流技术的实践机会。

3. 到击败白银圣斗士，就像架构师

此阶段，部分 3 – 5 年或经验更久的工程师，随着在工作中不断遇到复杂问题和技术挑战，工程师对原有的技术框架和设计模式有了更深的理解，再根据实际场景的应变，开始能够独立设计和维护大型服务功能。他们具备针对特定场景完成合适的架构设计的能力，在团队中承担高级工程师或架构师角色；

上文之所以说部分工程师，是因为并不是所有人都能跨过中高级工程师这个槛，成为一名合格架构师。

这一阶段是架构知识由泛到专的过程。在特定业务场景下，能够对架构有清晰的目标，并利用已有架构技巧实现目标与成本的平衡，最终满足业务要求。比如作为一个合格的互联网架构师，需要理解常用缓存、存储资源的特性及优缺点，具备架构选型和实现的能力。

另外，我觉得在大多数人看来，中、高级工程师差异还是很大的；而高级工程师和架构师反而过渡不是那么明显。

4. 再到战胜十二黄金圣斗士救出自由女神雅典娜

工程师到这个阶段，已经不能用时间年限来衡量了，更多的是需要对这个行业的热爱和合适的成长平台。

随着具体场景下架构设计实践经验的增多，一小部分架构师能够把这些经验抽象为一种通用的理论，形成架构设计的理念，并能够用这种理念指导影响团队中的其他人，加上对于技术如何应用到行业的深刻理解，成为一个公司的首席架构师；

成长为首席架构师，除了个人的努力和不断学习总结积累外，一个好的实践锻炼平台至关重要。

就像高可用架构方向，如果没有亲身经历过高并发、海量数据的服务架构设计和开发的过程，很难凭空想象可能的场景问题和技术挑战，实践经验的总结抽象也就无从谈起；

在这个成长的过程中，圣斗士们通过不断的磨难激发出了第六感、小宇宙，从而使他们变得越来越强大；而工程师也是在解决服务性能瓶颈、服务器宕机、异常峰值应对、分布式数据一致性、海量数据存储等问题中，不断的总结出经验和教训，从而变得越来越有经验。最终，极个别的一些首席架构师脱颖而出，成为了大师。

吴军博士在《硅谷之谜》中也提到，这类工程师通过对行业及技术的理解，具备做出行业最好产品的能力，并进一步可以做出给世界带来惊喜的产品，比如 iPhone 及 Google Glass 的总设计师。

高可用架构群就有很多首席架构师级别的前辈，他们在技术架构、技术管理等方面传到解惑，成为技术人员成长的引路人。

在技术人员成长的各个阶段，需要具备的知识和技能不同，从最初的语法规范的学习，到后来设计模式的灵活运用，再到对架构的理解和抽象，对技术人的素质要求越来越高。特别是架构知识，这是技术人成长中非常具有挑战的那部分，涉及了方方面面的问题，看似杂乱无章，实际还是有迹可循的。

架构知识拓扑

所谓架构，在互联网的场景，就是保障服务高性能、高可用、可扩展的一系列技术措施。架构的维护成本是评价其好坏的重要因素。

1. 互联网架构的要求

具体来看就是通过一系列的技术手段达到以下要求：

性能要足够快以能够满足业务需求；
业务流量峰值能够扛得住；
突发异常流量能够应对的来；
部分服务器宕机不影响整理服务；
能够随着业务的增长保持有节奏的容量扩容；
再高级点就是，资源成本要足够低，研发效率要足够高，支持异地容灾，资源弹性伸缩提高资源利用率等。

然而，所有这些针对架构的要求和保证，都需要建立在一定标准之上，如果没有标准，服务的好坏，性能的高低就没法界定，所以，为服务制定 SLA（Service-Level Agreement）就变得非常重要。

2. SLA 设置

SLA 从性能、容量、程度三个方面对服务好坏做了约定，比如一个服务的 SLA 可以简单的描述为：

99.9% 请求响应时间 < 100ms；最大 QPS 2W；

这里就规定了最大容量 2W QPS，性能上99.9% 的请求小于 100ms 响应，其中 99.9% 就是程度，这 3 个指标会让我们很好的了解服务的状况。

SLA 体系是架构的基础，即作为对外部的保证，也是对内部的约束。

3. 监控的要求

另一方面，好的架构应该时刻了解服务所处的状态，以保证能适时作出合适的应对策略，这让监控体系变得非常重要。就像打红警游戏，有个间谍卫星和电力仪表盘是多么重要！

所以，你需要知道如何能让你的监控系统实时准确的反馈相关数据信息，实时、方便、直观是衡量一个监控系统好坏的重要指标。

总结：拓扑结构

有了以上两个重要基础，架构设计变得不再那么困难，通过 SLA，你已经知道目标是什么、通过监控体系，你已经知道问题在哪里，剩下的就是通过一系列措施去解决它们。比如，选择合适的存储资源，适当的容错和降级策略，为了架构解耦而做的服务治理和隔离，高可用的异地容灾，为了极致性能而做的网络拓扑调整，以及为了运维效率和资源利用率做的弹性伸缩。这些知识相互关联，互为制约，是设计一个好的架构的重要知识基础。

下图是我在负责微博多个项目的 SLA 时候提出的架构要点。

架构知识都掌握了也不一定就能设计出好的架构，还需要针对具体业务场景灵活的变通。一般分为 2 个层次：术与道。

架构上的术与道

在前面提到，架构师与首席架构师都具备架构设计的能力和经验，但他们却有着术与道的区别。架构上的术，就是针对特定场景的解决方案；架构上的道，是一种思想和理论，能够指导很多通用问题的解决，它更有整理性、全局观。

由术向道的转变，是一个大量亲身架构实践和总结的过程。一方面这取决于你是否有一个好的发挥平台，如果没有这种锻炼平台，大量的亲身架构实践将无从谈起，这种转变几乎不可能实现；另一方面，经验的总结和抽象也不是闭门造车，和业界的高手共同交流探讨是避免走进误区及快速拓展思路的好方法，所以经常的技术分享，适当的技术社群互动就显得非常必要。

通过不断的学习和努力，很多人可以成为架构师，但只有很少的人能成为首席，一个很重要的原因是，除了出色的学习、抽象、总结能力外，大量复杂问题的架构实践至关重要；而这一点一般只有在较大的平台才能遇到。

架构知识说了不少，我们如何高效的获得这些知识呢？

技术阅读

对于工程师来讲，我一直认为我们生活在最好的时代。互联网的蓬勃发展给了我们很多的历练和成长机会，技术社区的繁荣让我们自我学习和提高成为可能。在这个年代，技术人员的成长在一定程度取决于知识获取及消化能力。

技术博客，技术丛书，技术文章，技术公众号，让技术知识和思想在工程师群体中自由传播，形成技术成长的肥沃土壤，比如从类似「ArchNotes」高可用架构这样的公众号就可以学到大量一线架构师分享的知识与经验。

然而，伴随着技术社区的繁荣，技术知识变得越来越丰富，甚至太丰富了，以至于我们几乎无法全部消化这些信息，我们需要有选择、有甄别的来看；有些需要泛读，有些则需要精读甚至去实践。

初级工程师在夯实基础阶段需要系统的学习基础知识，这个阶段看书会让你的知识吸收更系统，博客和技术文章作为辅助知识扩展就好了。其他阶段则需要逐渐养成良好的知识获取习惯，比如：每个月看一本专业方向的书，每天定时浏览固定方向的博客或公众号文章，确保系统知识和架构经验都能够不断的获取和吸收。

一般来讲，技术博客或者公众号，是扩展技术视野，吸收他人实践经验的好的方式和渠道；技术丛书则是系统学习某一方面知识的最有效途径。

这么丰富的知识内容，这么多样的展现方式，是技术人共同分享贡献的成果；每个身临其中的技术人既是贡献者，也是受益者，他们学习别人的经验，分享自己的思想，在相互影响中共同进步。

学习与分享

关于学习与分享，让我想起了 Tim 在高可用架构群第一次分享时候引用的那段话：

你有一个苹果，我有一个苹果，交换后每人还是一个苹果；你有一种思想，我有一种思想，交换后每个人会有两种思想

这句话完美诠释了分享与交流的价值。

要成长就必须去不断倾听别人的分享，学习别人的经验。分享知识的人多了，大家的学习成本就会降低，成长速度就会变快，大家就会相互促进更快的成长。

根据我自己的体会，对外分享还是一个自我总结、积累以及进一步提高的过程。为了避免分享给大家错误的知识，我一般会对分享内容进行多次 review，把之前模糊的、不十分确定的问题搞清楚（分享后被人问住或质疑总是分享者不想碰到的），这个过程往往让我对问题的本质有新的认识。

好的分享还会带来很多讨论和咨询，促进对问题的更全面认识和思考。比如 2015 年我在 ArchSummit 大会分享了《新浪微博高可用服务保障体系演进》，现场和会后有很多小伙伴专门来找我一起探讨相关问题，其中有不少场景是我没有遇到的，也给了我很多新的启发。

所以，学习与分享是一个互相促进的过程，学习别人的经验，把自己的实践总结分享出来，技术慢慢的积累，再分享，不断成长，不断学习。。。

所以，我今年除了写些技术文章，我还计划给自己一个新的挑战，写一本关于架构的书：《大型网站高可用服务架构实践》。

写到这的时候，其实我犹豫了很久，想做为啥非要说出来？我之前写过一些技术文章，感觉还不错，所以，就有过写一本书的想法，但真准备去做的时候，发现写书和写一篇技术文章差别非常大。技术文章一般阐述解决一个问题，但书是让人系统学习某一领域的方式，需要有条理的阐述解决一系列问题，并且还需要让大家有兴趣坚持读下去，想想都很有挑战。

今天前面同学分享时提到，如果实在感觉困难就倒逼一下自己，所以为了让自己能坚持下来，我就尝试下这种方式，让“太忙了、没时间”等借口少一些机会，说不定还能吸引一些感兴趣的小伙伴一起参与。