小土刀

【通天塔之架与构】1 系列概览

时隔八个月,【架与构】系列的第二篇文章终于和大家见面了。这段时间里,我参与了几个系统的开发,又独自设计实现了俩系统。在和不同部门的合作中,我逐步了解了从生产、硬件到知识产权、软件这一整套的流程,终于能以更高的视角去看待架构本身。在这里写下自己的想法,跟大家分享。


更新历史

  • 2016.11.09: 完成初稿

系列文章

写在前面

今年三月决定开始这个系列的写作时,我自己心理也是没底的,因为除了课本上的内容,我仅有的架构经验仅限于在大公司刻舟求剑以及在实验室搭脚手架,于是这个系列的写作便陷入了无限期的停摆之中。

工作之后,先是阅读了公司各大项目的源码,再是参与了几个系统的核心功能开发,之后又独立设计并实现了俩系统。虽然有些辛苦,但是快速把工程经验较弱这一短板补上了。遇到问题都可以在短时间内拿出一套较为合理、分工明确、可阶段性验证的解决方案。

能有这样的进步,需要特别感谢的是同事的倾囊相授和领导的充分信任,在遇到难题时可以并肩作战,让我有机会比较深入去了解公司的整体架构与业务流程,这对后续系统和架构的设计与搭建很有帮助。之后到需要我自己设计与搭建系统的时候,也并没有给我太多限制,对于这种不拘小节专注把事儿做好的态度,我是非常喜欢的。

既然学有所得,便想分享出来,整理思路的同时是很好的提炼与升华,更何况能以此与有志于此的朋友们交流讨论,一石二鸟,何乐不为?

系列内容计划

『架与构』这个系列原则上来说内容自由度是很高的,正因如此,才更需要一个比较完整的计划,不然东一榔头西一铲子,让人完全找不到重点。在自己学习和实践的过程中,很清晰意识到了『架与构』的痛点在哪里,于是,这个系列核心便是:

结合对于架构的理论研究与实战经验,搭建从书本到现实的桥梁

有了一定架构的实践经验之后,回过头来思考校园所学,发现其实各类架构和系统设计课程上的内容都是非常有价值的。但是最大的问题是,对于学生来说,这些经过提炼和抽象的核心概念,是接近于无法理解的,最终回到了『鸡生蛋蛋生鸡』的问题上。

那怎么办?正所谓最好的学习方法是『用』,概念需要在不断的实践中打磨,才能足够锋利。但是对于大部分对架构感兴趣并且想要入门的朋友来说,是很难有机会去直接参与到一个大系统的设计与架构中的。当然,我们可以自己做开源项目,或者是借鉴各大公司的架构相关分享,却容易因为架构涉及的知识面太广导致学着学着自己都不知道自己在干嘛了。

针对这个问题,我的一个尝试是把概念与实际案例与业务模型结合起来,通过引导大家思考大公司中不同业务逻辑及其对应的架构的差异,去真正理解架构本身,甚至能够突破架构,去思考业务的模型。而在理解了核心概念之后,反过来又可以据此来分析和优化已有的系统和架构。这样就把概念和实际联系了起来,大约不会再出现『这个概念我懂了但是没什么用』的感觉。

举个例子,为了给广大用户提供稳定的服务,并发架构的设计基本上是每个公司都无法绕开的。对于这个主题,我会怎么讲呢,基本的顺序是:

  1. 从 CPU/GPU 的架构说起,解释并发与并行的差别,说明为什么需要并发,以及核心难点在哪里
  2. 为了解决这些难点,人们尝试了哪些方法,也就是具体的并发编程模型,比方说并行工作者模型、流水线模型和函数式并行模型。
  3. 介绍不同模型的实现方式,比方说流水线模型又包括事件驱动系统(Vert.x, Akka, Node.js)和 Actor/Channel 模型,也会简要介绍不同编程语言在解决并发问题上的思路与实现方式
  4. 挑选不同公司的不同业务进行简要分类分析,比如电商网站中的秒杀、聊天软件中的集中发红包或打车软件中的车辆实时调度,主要是理清业务场景和可能出现瓶颈以及需要注意的地方,简要进行业务量的估计
  5. 结合不同公司在开发者大会上的分享,说明架构的设计是如何去解决不同的业务场景的瓶颈,以及不同量级的数据需要如何去设计对应的架构。这之中,架构演变的介绍最有价值,我们可以通过分析每次变化去反推设计思路,最终用于自己的实践中

通过这样五个步骤,基本就把概念-设计-实践整个串联了起来,既有理论也有工程,融会贯通产生 1 + 1 > 3 的效果。

最后用八个月前写的一段来结尾吧,之所以把这个系列取名为『架与构』,是为了提醒自己设计和实现是不可分割的部分,『架』得再好,『构』不出来也没用。所谓『脚踏实地,仰望星空』,大概就是这个道理。

捧个钱场?

热评文章