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

前文提到在一段较长时间内，国内的技术热点是单机高并发高QPS，因此很多那个时代走过来的人会本能地质疑web框架的性能，而更偏好TCP长链接甚至UDP协议。然而这往往是自寻烦恼，因为除开特别的强实时系统，无论是休闲手游、视频点播还是信息流，都已经是基于HTTP的了。

上图所提到的两个问题中，我想强调的是第一点：所有的业务，在能满足需求的情况下，首选HTTP协议进行数据交互。准确点说，首选JSON，使用web API。

Why? 这就是上图第一个问题所回答的：无状态、易调试易修改、一般没有80端口限制。

最为诟病的无非是性能，然而实际上对非实时应用，晚个半秒一秒不应该是大问题，要考虑的是水平扩展scalability，不是实时响应(因为前提就是非实时应用);其次实在不行你还有websocket可以用。

这一部分是简单列举了一下不同框架的使用，可以看出不同框架的概念其实差不多。重点是要注意到middleware这个说法在web framework和后端架构中的意义不同。在web framework中是指具体处理GET/POST这些请求之前的一个通用处理(往往是链式调用)，比如可以把鉴权、一些日志处理和请求记录放在这里。但在后端架构设计中的middleware则是指类似消息队列、缓存这些在最终数据库之前的中间服务组件。

最后这里是想说web framework并不是包治百病，实际上那只是提供了基础功能的一个library，作为开发者则更多需要考虑如何定义配置文件，一些敏感参数如token、密码怎么传进来，开发环境和生产环境的配置如何自动切换，单元测试怎么搞，代码目录怎么组织。有时候我们可以用一些比如Yeoman之类的scaffold工具来自动生成项目代码框架，或者类似django这种也可能自动生成基本目录结构。

下面进入Middleware环节。again，强调一下这里只是根据个人经验和感受谈谈演化过程。

这一页只是大致讲一下怎么定义中间件middleware。说句题外话，在美国湾区那边提这个概念的很少，而阿里又特别喜欢说中间件，两者相互的交流非常头痛。湾区那边不少google、facebook还有pinterest/uber这些的朋友好几次都在群里问说啥叫中间件。

中间件这个概念很含糊，应该是阿里提出来的，对应于middleware(不过似乎也不是完全对应)，可能是因为早期java的EJB那些概念里面比较强调middleware这一点吧(个人猜的)。大致上，如果我们把web后端分为直接处理用户请求的frontend，最后对数据进行持久存储(persistant storage)这两块，那么中间对数据的所有处理环节都可以视为middleware。

和中间件对应的另一个阿里发明的概念是中台。近一年多阿里的中台概念都相当引人注意，这里对中台不做太多描述。总体来说中台更多是偏向业务和组织架构划分，不能说是一个技术概念，也不是面向开发人员的。而中间件middleware是标准的技术组件服务。

那么我们自然会有一个问题：为什么要用中间件?

谈到为什么要用middlware，这里用推荐系统举例。

推荐系统，对数据少用户少的情况下，简单的mysql即可，比如早期论坛的什么top 10热门话题啊，最多回复的话题啊，都可以视为简单的推荐，数据量又不大的情况下，直接select就可以了。

如果是用户推荐的话，用户量不大的情况下，也可以如法炮制，选择同一区域(城市)年龄相当的异性，最后随机挑几个给你，相信世纪佳缘之类的交友网站早期实现也就是类似的模式。

那么，如果用户量多了呢?每次都去搜数据库，同时在线用户又多，那对数据库的压力就巨大了。这时候就是引入缓存，memcached、redis就出现了。

（编辑：新余站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!