写点什么

架构师训练营 第四周 个人感想

用户头像
且听且吟
关注
发布于: 2020 年 07 月 01 日

0 期 3 班 4 组 杨娴艳



本周智慧老师的课程主题全面进入了系统架构的知识范围,两次课程分别讨论了以下内容,包括:

传统企业应用和互联网应用的系统特点对比,引申出互联网系统面临的严峻挑战;传统企业应用和互联网应用在应用高并发的两个技术方向;互联网架构的演化、架构模式、核心要素和技术一览;列举了各类网站的技术架构案例,如:维基百科技术架构详解、淘宝早期的技术架构的演化、初创互联网公司产品宅米的系统架构演化历程等。



本次课程涉及到大量的互联网系统架构的理论知识、技术方案等相关信息,所以课后我还是利用工作之余的碎片时间重新听了一遍,课程涉及的架构方案、技术方案对于每个想要成为架构师的我们来讲都是需要掌握的常识,就如智慧老师的课程标题“系统架构知识是架构师的常识而不是能力”,对比仅需要研发工作的开发人员来讲这其实是一个不小的挑战,也是架构师的不凡之处,而本次课程的作业虽然题目只有一句话,却确实让大家有机会把到互联网(分布式)架构相关的技术都梳理一遍,在后续的课程中也会有的放矢,针对自己的薄弱点强化的进行学习。



下面我将就以下几个点谈一下本周课程后我的收获和感想。

了解互联网系统的发展历史

随着互联网技术的兴起,特别是最近几年公有云服务商的崛起,有很多的互联网基础设施、技术方案都非常的成熟,但是作为一名IT从业人员,特别是想要往架构师方向发展的时候,需要对一个互联网架构演化过程有基本的了解,每个阶段遇到什么问题,用什么方案解决,具体的技术方案有多少种,分别的优劣是什么,最后用最合适的方案进行解决。

业务推送技术进行架构演化

作为技术人,常常会觉得技术日新月异,特别是专注于互联网开发的IT技术人员更是觉得自己知道的还太少,了解的不够多,开发语言兴起了python、go等编程语言,包括Docker、K8S、ServiceMesh等容器化和容器化编排技术的蒸蒸日上,微服务架构模式的风靡,各种分布式中间件、分布式技术方案在各种大厂不断的成为业界的优秀产品和案例,以上的种种都让IT从业人员有一种紧迫感。在项目的开展过程中,作为传统企业的开发人员、创业公司的开发人员、大厂的开发人员都有过自己各自在不同处境的疑惑以及发展的瓶颈。而无论在哪里,我们在实际的项目进展过程中,始终要保持将业务放在第一位,秉持:需求业务化(线下->线上)、 业务领域化(分清领域边界)、领域模块化(将不同边界的领域做到解耦)、模块服务化(将独立的领域服务对外公开,达到最大的价值,做到微服务,自治的服务 )的思想开展项目,而不是一开始就立下Flag,在项目还为0起步的时候或团队只有3-5个人就先想着把微服务架构搭建好或者引入重磅的中间件技术、分布式技术等。我们要时刻记住技术永远为业务服务,业务死了,技术方案再牛也没有任何的价值。

智慧老师列举的几个技术架构案例也正好说明了这一点,一个世界排名第六的网站的技术架构图并没有想象中那么复杂,究其原因是因为其业务的简单;万能的淘宝曾几何时也是简陋的配置,但是随着业务线的扩展,技术架构越来越复杂,逐步成为了中国IT界的技术标杆;年轻的宅米,最后没有坚持下去,最大的一部分原因也是因为其业务的局限性。

用最合适的方案解决问题

解决问题的能力是软实力,需要经验和不断的知识的扩展进行加持,而随着互联网技术的兴起,各种问题的可选解决方案常常会让我们难以抉择,这就要求我们依据当前的项目发展阶段、项目的规模保持敏锐的判断力,举个例子当查询某个数据库语句遇到瓶颈的时候,先要考虑一下SQL语句的编写是否符合高性能要求,数据库索引是否已经进行了建立和优化,而不是一上来就考虑分布式缓存方案。

最后

无论我们处在哪个境地,是在传统企业也好,在创业公司拼搏也好,在大厂中不断摸索也好,刚毕业意气风发也好,30+已经开始想着如何突破瓶颈也好,我们都还是要在工作之余对自己有更高的要求,也许我们所在的公司业务还没有发展到可以让我们把高大上的技术进行实施,业务我们参与和负责的项目量级还是个微、中、小项目,但是我们始终要记得,机会是留给有准备的人,具备专业的能力才能做专业的人才。希望我们都有机会学以致用,不负韶华。

发布于: 2020 年 07 月 01 日阅读数: 134
用户头像

且听且吟

关注

没有绝世高手 2018.06.30 加入

还未添加个人简介

评论

发布
暂无评论
架构师训练营 第四周 个人感想