浅谈我对中台,中间件,微服务的认识

本文最后更新于:2022年7月12日 晚上

一,中间件

拿脉脉的搜索功能举例子,搜索功能分为 找人,搜职位,搜内容。初学后端的人一般是这么设计这三个api的:写三个函数,对应三个不同的功能,每个函数执行时都会取出request里包含的session,拿这个session验证合法性,如果合法则继续执行后面的部分并返回,否则直接返回。
由于验证session这部分重复率很高,我还把这部分写成一个函数,每个功能只要调用这个函数就可以验证了。
随着时间的推移,搜索功能扩展到了支持100种不同的搜索,函数也增加到了一百个,每个函数里都加上了验证session的函数。
突然有一天,产品经理说,这些api不再需要验证session了。那么开发就需要在每个函数里把验证session的代码给删了,工作量巨大,有没有一种方法可以满足这个要求呢?

这个方法就是中间件。第一次听到这个词的时候让我很困惑,中间件,顾名思义应该是在执行过程中间做什么操作。但它其实是在执行前,后做的一些操作。
中间件可以在收到request后,进入执行函数前,做一些操作。
比如这个例子里,就可以把验证session的部分给放到中间件里。如果验证成功,就允许这个request继续往下一步到达搜索函数,否则直接在中间件就返回错误。
也可以在执行完搜索函数后,先返回内容给前端,然后中间件继续处理如关闭数据库连接的一些操作。

二,微服务

在剥离了验证session功能后,搜索函数就变成了纯粹的搜索函数。秉持着疑人不用,用人不疑的原则,这个函数不会再去关心请求是否合法,不再关心频率是否过高,它只专注于获取内容并返回,如同一个没有感情的机器,这就是微服务。
假如这个搜索函数每次执行需要5秒,这台机器每次只能处理100个请求。这时如果第101个请求进来,它就需要等待5+5秒的时间
如何解决这个问题?扩展机器,简单粗暴
由于这个函数已经变成了纯粹的搜索函数,所以它可以被轻易直接部署在其他机器上。那应该部署多少个机器呢?如何避免低峰时期对空闲服务器的浪费?
这时候就可以用k8s。k8s根据你的请求数量情况,自动创建,销毁 包含你函数功能的容器。在请求高峰的时候,创建大量容器去处理请求。在低峰的时候,销毁多余容器,释放资源

三,RPC

举个例子,假如一个网站提供斐波那数列计算,那么当用户要获取n的值时,会有两种方式。1.通过http协议将这个n发送给后端,后段计算出结果后返回给前端。2.前端从后段获取计算斐波那数列的js代码,然后执行这段代码获取n的值。
RPC的本质就是获取原本获取不到的值。
可能有人会疑惑,那为什么不通过请求http的方式获取值?
因为通过RPC,可以像调用本地函数一样去调用远程的函数。
拿python举例,我们有两个文件,client.py和server.py.
当client要掉用add这个函数的时候,RPC对象会检查本地是否有这个函数。如果没有的话,它就会请求server把add函数的代码发过来。然后client拿到代码后,在本地执行。

由于RPC是支持跨语言的,也就是说在python可以调用golang的函数。那这时候就会产生一个问题,python如何执行golang的代码?答案是不行(或不方便),那么python就可以换种方式,将参数发送给server,server再返回值。
RPC可以基于TCP,可以基于HTTP,甚至可以基于微信聊天
举个例子,A不知道计算斐波那数列的代码怎么写。于是A给B发送一条消息:”哥,斐波那数列怎么用python写?能不能把代码发我?”.于是B将代码发给了A,A拿到代码后成功执行了
如果这时候,B不会python,只会golang。那么A即使拿到代码,也不能执行。所以这时候A就会问B:”哥,斐波那数列n为30的时候,值是多少?”.B用golang计算出值后,将值返回给A.A拿到了答案,但是不需要关心B是用什么语言

四,中台

在传统的架构中,各个项目相对独立,虽然后端有很多部分逻辑一致,但会产生很多的轮子。于是有了中台的概念,中台就是把共同的东西 如:支付系统,用户系统 取出,只做一次,然后不同项目使用相同的中台,提高开发效率。如阿里的淘宝、天猫、支付宝,都可以由同一个中台支撑,如 用户中心,商品中心,交易中心。 中台分为业务中台,提供支付中心,用户中心,搜索中心等。技术中台,提供MQ,容器,RPC等。数据中台,提供数据建模,用户画像等。算法中台,提供图像识别,推荐算法等。现在很多的应用都提供微信一键登录,从某种意义说,微信在其中就是起到业务中台的用户中心作用。


本博客所有文章除特别声明外,均采用 CC BY-SA 4.0 协议 ,转载请注明出处!