从技术演变的角度看互联网后台架构

这是去年在部门内部做的一个面向后台开发新同学的课程，因为其他BG一些同学要求分享，所以发一下。

其实内容都是些常见开源组件的high level描述，比如flask, express框架，中间件的演化，micro service的概念，一些对nosql/column based db的概念介绍，docker的一些简单概念等等。从单个概念来说，这只是一些科普。

但是为什么当时要开这门课呢?重点是我发现很多新入职的后台开发同学并不太清楚自己做的东西在现代互联网整体架构中处于一个什么样的角色，而在IEG内部则因为游戏开发和互联网开发的一些历史性差异，有些概念并不清晰。

拿中间件来说，很多web application不用啥中间件一样可以跑很好，那么是不是都要上redis?到底解决什么问题?中间件又存在什么问题?中台和中间件又是个什么关系?如果开个mq就是中间件，微服务又是要做啥?

如果能从这十多年来互联网应用的整个tech stack变化去看待backend architecture的一些改变，应该是一件有趣也有意思的事情。这是当时写这个ppt开课的初衷。

我不敢说我在这个ppt里面的一些私货概念就是对的，但是也算是个人这么多年的一些认知理解，抛砖引玉吧。

强调一点，这个ppt的初衷是希望从近十多年来不同时代不同热点下技术栈的变化来看看我们是如何从最早的php/asp/jsp<=>mysql这样的两层架构，一个阶段一个阶段演变到现在繁复的大数据、机器学习、消息驱动、微服务架构这样的体系，然后在针对其中比较重要的几个方面来给新入门后台开发的同学起个“提纲目录”的作用。如果要对每个方面都深入去谈，那肯定不是一两页PPT就能做到的事情。

下面我们开始。首先看第一页如下图：什么是System Design?什么是架构设计?为什么要谈架构设计?

之所以抛出这个问题，是因为平时常常听到两个互相矛盾的说法：一方面很多人爱说“架构师都是不干活夸夸其谈”，另一方面又有很多人苦恼限于日常业务需求开发，无法或者没有机会去从整体架构思考，不知道怎么成长为架构师。

上面ppt中很有趣的是第一句英文，翻译过来恰好可以反映了论坛上经常有人问的“如何学习架构”的问题：很多leader一来就是扔几本书(书名)给新同学，期望他们读完书就马上升级。。。这种一般都只会带来失望。

何为架构师?不写代码只画PPT?

不是的，架构师的基本职责是要在项目早期就能设计好基本的框架，这个框架能够确保团队成员顺利coding满足近期内业务需求的变化，又能为进一步的发展留出空间(所谓scalability)，这即是所谓技术选型。如何确保选型正确?对于简单的应用，或者没有新意完全是实践过多次的相同方案，确实靠几页PPT足矣。但是对于新的领域新的复杂需求，这个需求未必都是业务需求，也包括根据团队自身特点(人员太多、太少、某些环节成员不熟悉需要剥离开)来进行新的设计，对现有技术重新分解组合，这时候就需要架构师自己编码实现原型并验证思路正确性。

要达到这样的目标难不难?难!但是现在不是2000年了，是2019年了，大量的框架(framework)、开源工具和各种best practice，其实都是在帮我们解决这件事情。而这些框架并不是凭空而来，而是在这十多年互联网的演化中因为要解决各种具体业务难点而一点一点积累进化而来。无论是从mysql到mongodb到cassandra到time series db，或者从memcached到redis，从lucene到solr到elasticsearch，从离线批处理到hadoop到storm到spark到flink，技术不是突然出现的，总是站在前人的肩膀上不断演变的。而要能在浩如烟海的现代互联网技术栈中选择合适的来组装自己的方案，则需要对技术的来源和历史有一定的了解。否则就会出现一些新人张口ELK，闭口tensorflow，然后一个简单的异步消息处理就会让他们张口结舌的现象。

20多年前的经典著作DesignPatterns中讲过学习设计模式的意义，放在这里非常经典：学习设计模式并不是要你学习一种新的技术或者编程语言，而是建立一种交流的共同语言和词汇，在方案设计时方便沟通，同时也帮助人们从更抽象的层次去分析问题本质，而不被一些实现的细枝末节所困扰。同时，当我们能把很多问题抽象出来之后，也能帮我们更深入更好地去了解现有系统-------这些意义，对于今天的后端系统设计来说，也仍然是正确的。

下图是我们要谈的几个主要方面。