5月25日，互联网架构技术沙龙圆满落幕。本期沙龙特邀请腾讯的技术专家分享关于技术架构、落地实践案例、无服务器云函数架构、海量存储系统架构等话题，从技术角度看架构发展，为开发者们带来丰富的实践经验内容，深度揭秘技术架构。下面是张力柯老师关于互联网后台架构的技术演变的总结。

我这部分主要是讲一下从一个演变的角度看互联网后台架构。架构是怎么一回事？实际上大家工作中经常有这样的说法：所谓的架构师好像是一个不干活的，干活的是一线的工程师等等。为什么会有这种观点产生？以及到底当我们在谈架构的时候，到底在说什么东西？这是不是一个很虚无或者很实际的东西？接下来我们一起探讨下。

我们首先看看架构设计是什么？为什么要做架构设计？当你新入职的时候，可能有一些比较高级的架构师，他们通常会建议你选一些所谓的经典书籍去看，好像一个武林秘籍一样，期望你看完这本书，就变成一个很有经验的人，或者所谓的高手。但是其实看完之后还是不明白，日常工作中还是会碰到这样的疑问。我们在讲架构和做设计的时候，并不是指望看一本书就可以达到你想要的效果，实际上在架构上讲设计，是希望程序能有一个统一的术语去沟通。设计模式不是一个很早的概念，首先运用设计模式只是让程序员之间在沟通时有一共通的语言和词汇，比如说早期的工厂模式和单例模式等。

第二，我们可以从一个较高抽象的角度去描述逻辑实现。我们现在谈微服务，我们知道服务都有服务注册的功能，我们会谈一些很具体的细节，因为现在越来越趋向于做一个基于云架构或者本地架构的互联网应用，由各种服务接口连接起来，呈现出各种不同的功能，其中关键就在于如何把不同的服务连接起来，所谓的中台即是一种概念性的描述。

这样对现行的系统更容易理解，而不是一开始就去谈论底层细节。然而国内有这样的趋向，上次我们招聘一个BAT的同学，谈到一些应用框架，他一来就说要看原码。我就告诉他你首先把它拆出看看什么是服务，把它的交互关系搞清楚，再来说要不要更深入地去谈，我们先要理解现有的系统怎么构建的、怎么处理数据、怎么接受请求中间件，这样才能把不管多复杂的东西都拆分开，形成所谓的业务逻辑。

当我们能够了解这套系统本质的东西后，我们才能去做出更正确的决策，决定需不需要添加功能或者修改，而不是去套一些概念。比如说现在中台是什么东西？到底需不需要？到底发挥什么作用？这个需要你对这个概念理解之后才能去决定的。有了这个概念之后才能知道怎么去重构代码，明确重码有没有意义。“Design Patterns”不是新的概念，我们今天把它叫做系统设计或者system design，其实这个内容我以前也有分享过，但是涉及了很多微服务等等的东西，这里因为时间有限我就讲一下其中最有代表性的两种：一是后台架构的演化，其实网上也有很多的公众号、文章在最近半年提到这个问题，就是互联网架构不是凭空由谁发明出来的，是慢慢演化过来的，是根据实际的需求演化过来的。二是演化中间件，大家知道存储变化不是很激烈，重点在于大家说的中间件在整个互联网架构的变化中是从无到有过来的，所以我就挑比较有代表性的内容来讲，它可以反映互联网在后台架构是怎么进化的。

后台架构的演化，互联网的第一个阶段是98年，20年前开始的，现在还有人说PHP是最好的语言，为什么？当年JSP/ASP/PHP、业务逻辑和页面显示混写‘’两层结构现在仍然流行于大量的软件外包、业务兼职外包、淘宝网站代码中。实际上在2006年前那几年如果你懂得三层架构，会写JSP或者写一个SERVLET的话，你就是大牛，找工作毫无问题。但其实架构很简单，并没有所谓的中间件的结构，基本上是JSP处理页面逻辑，然后直接处理数据库，实际上，在现在很多公司里面很多服务，比如OA系统等内部办公系统还是这样做。可能在代码层面上会好看一点，但是从架构设计方面来说其实是一回事。这个没有什么问题，所有的技术都是根据需求来的，作为内部公司的OA内部网站，完全没有必要去做中间件。

这种情况差不多持续到2007-2008年，就是十年前，为什么会以这个时间段作为一个节点呢？主要是由于这个时间发生了两个事情：一是google为代表的大数据应用诞生，再就是后边Twitter还有脸书社交网站的崛起。这些都涉及大数据的存储、搜索还有很初期的推荐系统，像世纪佳缘、百合网什么的都是2010年左右爆发起来的。用户推荐在这个时间段是个很重要的问题，当时的推荐系统很初级，就是一个简单的搜索，缺少并发能力以及业务的复杂度。所以如果我们还用前面的架构，首先要考虑DB怎么选，这就诞生了像Tomcat Servlet，Lucene/Solr等等这些。MQ系统在机器学习时代发挥了更重要的作用，但是当时其实主要是处理高并发的问题，也就诞生了HAProxy、Nginx、Python、Node.js等等。同时很多是关于海量数据的近实时处理，打个比方当时在公司做一个手机游戏的战斗匹配，我们要考虑到用户的点击量上升，不断地变化，不可能做实时，必须每半个小时或者定时给它排一下序，于是有了Elasticsearch等等。

上边所讲的这些技术的诞生，就解决了前面第一代互联网架构所解决不了的问题，那段时间最常的是怎么处理海量数据，怎么去做高并发。那个时候大家在面试的时候，这些概念也是面试官最喜欢问的，怎么做高并发，怎么去做平衡。刚刚腾讯云的广告也是HR认为你有云计算的经验就给你发Offer，其实无非就是怎么去做高并发怎么去处理大数据，现在可能会加一些运维的概念，当初还有一些比较新的概念，例如分布式这一基本概念。在做这些东西的时候必须要了解什么是缓存，还有搜索的概念，也要了解这些东西是用来做什么的。这些概念不是凭空出现的，只有存在必须要解决的问题，才会有这些东西的诞生。

2013年—2017年可以说是第三代，正式进入大数据的时代，我们之前的要求就是能够处理QPS到100万，但是2013年这些要求是基本的，高并发和负载等等这些问题已经不是问题了，已经有很成熟的方案，你只要选用就可以了，当然中间要考虑跟业务结合起来，但是从原理来说没有什么新鲜的东西。

这时候讲的是怎么去用这些数据，现在国内通常把这个叫做数据打通，其实意思是一样，比国外晚几年。大数据时代最重要的是要做数据挖掘，那个时候做数据科学家很火，需要考虑推荐的用户是不是能够加好友，或者推送的新闻就不是像以前一样随便抛出当天的热点就可以，这一点头条做的比较好，它也是那时候开始发展起来的，这都有它的原因，不是突然火起来的。我们总是说技术推动业务，怎么用技术推动业务？具体来说就是这些业务的需求怎么由技术演变和体现，这个可以从历史的脉络里面发现。云计算到Docker，2014年就出来了，那时候我帮几个朋友做一些Docker方面的创业活动，当时对客户很难去解释也很难让人理解，现在再去说的话，人家都说很好，都知道是什么东西；然后是微服务到Severless，还有一个很有意思的概念，DevOps以前的运维是有点不受重视的，现在DevOps更多是跟公司的基础架构绑定在一起，我们现在发布不再像以前那样搬几个机器放到机房里面就行了，现在是一个巨大的机房上面运行的是无数的服务器，还要考虑怎么样动态扩容，这都对运维人员的技术性以及对技术架构把控能力上提出了更高的要求，这也是为什么后来出现了DevOps这种比传统运维要求更高的职位。

还有就是快速迭代/AB测试，现在要做数据跟踪和分析，要定义各种复杂的评价标准来看到底怎么设计比较好。我们还是回到最基本的，我们刚刚谈到中间件，在大数据情况下，客户端很复杂，有IOS、安卓、微信、小程序等等一大堆东西，底层可能是Kubernetes到Elasticsearch，各种复杂的DB等等，底层多个数据库的对接，这可以看成基础架构中心。问题是在请求从客户端传到基础架构中间时，一般来说首先要做分流，请求下来之后可以把它看成一种网关的东西，是接受外部服务，可以是RESTFul，你可能在前端做一些简单的筛选，或者简单的权限认证就可以了。我们传统的做法是按顺序逻辑实现，首先去找到用户信息，需要找到你附近这个区域的用户发的什么消息出来，可能要跟你自己喜欢的内容做比较可能还有一些机器学习的东西，再去跟你的兴趣做比对，这个就慢而且不好调整，每一步的调整可能对其他地方都有影响。所以为什么现在要做微服务？微服务就是把这些东西拆分开成不同服务，每个服务由一个开发组独立完成，负责自己的版本迭代和全县等等，这就是很多专家会谈的，这里就不再细说。

现在又回到一个问题，什么是所谓的中台？中台是更偏向于上层的概念，比如说用户登录，在一个大型的类似于像微信也好或者微博也好，它首先要看这个用户是不是被屏蔽了，是不是被恶意登录，有异常情况发生会告诉你是不是有异常，你要报异常肯定要记录它登录的消息，在哪里登录的，频次，ID多少，然后就监控，要记住它的位置在哪里登录，有可能在登录的时候会把它的信息记录下来。假如说光是登录就要处理这么多问题的话，运行其他服务的时候是不是又要来实现这些？这样就很麻烦了，能否把这些通用的服务单独提出来？所以就有中台的服务概念，归根到底都是一个微服务的概念。这个概念不复杂，但是很多公司是做不到，别人要调用基础服务的话可能是各种艰难。

2017年年底AI开始火起来，每个人都说要做AI，以前叫做数据驱动、业务驱动，现在提法叫做“AI驱动、机器学习驱动”。在2017年、2018年比较新的公司，比如说国外的优步，国内的滴滴、美团、头条、抖音，甚至大家看安居客多少会考虑怎么用机器学习的方式取代人工的方式，比如说优步有什么业务、定价、车价，比如说今天晚上有一个什么球赛，周围的价格就会提升，现在还是会有，但是更多是用机器学习来做覆盖。为了做这些工作，大型的公司都是把数据训练到最后训练成模型反馈到页面上，再由用户的点击再反馈回来。优步也是差不多，基本上目标都是把实际产品跟后面的模型训练打通，最后完全这样的平衡和可视化的工作。这些东西说起来流程是这么简单，我在这里也没有画什么，为什么？因为现在越来越多的发现在以前互联网时代的技术，不管是数据库系统还是其他的能不能用在这些流程里面实现？好不好用？都是一个疑问。从一个用户信息抽出来的信息可能需要要做一些处理提取feature，这个东西又怎么存，数据库可能又不支持，作为一个文件存储可能可行，但是有没有更好的方式，我们并不知道。

所以现在面临新的挑战，今年四月份像斯坦福、谷歌、微软等等这些地方，提出了一个新的计算机方向，叫做“SysML”，可能是最近几年重点的一个问题。这是从我自己角度出发分享的技术架构的演化过程。

下边讲一下中间件，中间件无非从Frontend到Middleware，其实中间件的概念在国外很少有人提。当时很多朋友在国外问我，他们说最近阿里的跟他们聊，华为跟他们聊，都在问中间件该怎么设计，他说在国外确实没有听到过中间件，觉得中间件这个东西可能是阿里自己创造出来的。因为中间件的概念是早期2000年初JAVA提的这个概念，他们提了很多的创新思路，当时有这样的东西，但是现在这些东西没有人用了；但是阿里他把它继续用下去了，这是我自己的想法，不一定准确。

中台的登录系统或者地图是具体的业务需求，中台可能是技术也可能是管理非技术人员的，中台是一个对外的操作工具，比如说调整一些判断是不是异常发生，中台可以完成一部分的业务需求，Middleware只是一个工具，不完成任何的业务需求。整合方案都是某种技术工具。

早期的时候你要选好友，距离、年龄、姓名、性别，最后select一下，这是最早的时候选择好友的方式，还是可以用，创业公司完全可以用这个东西，没有问题。那人多了以后怎么弄？亚马逊的CTO说过一句话，很多人纠结数据库该用什么，你的用户达到100万之前你根本不用担心数据库的问题。对前面的问题，你选一万个出来存在缓存里面再随机挑选就行。世纪佳缘早期可能就是这样做的，所以经常有重复的东西出来。这种排序过于主观了，很多数字都是自己去设的，还有就是查询也没有什么灵活性。后来诞生了基于Lucene的反向排序搜索引擎像Solr和Elasticsearch等，这样可以把查询的工作放到专门的搜索引擎里面去，不再是通过数据库直接查，在缓存和搜索之间做到平衡。这大概是在2012年、2013年的方式，但是这种方式很慢，做好友搜索是可以，但是2014年之后滴滴出来，需要的是马上找到司机，而不是要等后台做排序，怎么做到近实时的，就引入了后面比较复杂的系统，目的在于使一些数据能够尽快地看到，以前可能等到后面去索引，现在马上通过kafka消息通知到Spark的任务，由Spark驱动去做实时的indexing。这是现在最流行的做法，很多的大数据系统就是这么做的，问题就是这个东西很乱，不清晰，不好看，大家就会思考这个数据到底怎么滚动的？

之后是机器学习，一般机器学习只管训练或者直接产生模型，因为机器学习的模型训练管一天两天没有问题，就把数据引入到DAG的概念里面。以前的数据是把用户请求发到后端，然后由人员来制定规则，调整比如数据查找的条件，这样数据和结果之间实际上是断裂的。而我们现在引入机器学习，则完成了数据从输入到反馈的完整闭环，从机器学习数据到数据库，驱动AI模型训练，最后反馈到业务逻辑，这是一个异步的结果，同时也完成了数据的单向流动，而不是混乱的一团。

我们可以看到，互联网中间件的趋势是数据的混乱和双向流动，慢慢变为类似DAG有向无环图那样的单向流动，数据滚动只能往一个方向走。数据一定是有入有出，但是不会同时有入有出，Spark是坚持这个概念，大多数神经网络也是DAG，此外还有像Reactive Programming也是推崇数据单向流动的概念。这是现在架构设计越来越明显的趋势。我的分享就差不多到这里，谢谢。

Q：腾讯内部有没有一种解决方案去处理多接口间调不通这个问题？

A：腾讯有很多的产品，微信、QQ等等，不同的团队解决方法都不一样，但是你提的问题是包括前后端的对接，互相不协调的问题。总体来说是一个技术方案和人员分工的综合问题，我觉得这个问题我稍微说一下。首先从技术方案来说，一是把协议的定义清晰写出来，所有公式写出来，这是一种；二是单元测试，国内应该对单元测试做得很不到位，很多人估计不写的，但是国外是强制要求，很多人会觉得这在测自己的代码，我觉得我自己的代码没有问题，其实不是的，单元测试是防止有改动破坏影响你的代码。

其次从分工上面来讲，不协调的事情是因为不同的组有不同的需求，但是同一个组就方便沟通，我们可以看到很多公司在5年前都有分工的，比如说后端组前端组，或者数据库组等等，但是现在在国外优步等新的公司里面，是按类别来分，比如说我们现在在美团，可能就是一个打车组，订单组或者夜宵组，把团队的结构是按照产品的需求来分，我不要管前端后端数据分析等等，你这个组就是负责晚上夜宵，包括前端后端等等都有，你把这个业务搞定，按照你的业务需求来做，就把相关的全组在一个组，减少协调和沟通成本。

Q：一是通过RPC的方式，二是单元测试，三是一些组织架构上面的人员按项目组的分配方式，他们都会有各自的问题。RPC虽然也比较火，但是远没有标准模式那么流行，前端成本也比较高，它可以生成一些代码确实省了一些工作量，但是归根到底还是要后端暴露一些函数出来给他们调用，如果一定有后端开发，有这个工作量的话一定会出现满足不了前端需求的情况，还是会有这样的情况。

A：因为腾讯是我现在的公司不好说，我说一个优步的例子，它的前端实际是一个数据流，整个组就负责这一块，但是第二个问题出来了，这个工作就很单一，把司机信息的传回来就完了，不用管前面怎么用，在我们使用数据流的时候就出现一个问题，他们自己要调整也是一样，司机的位置最少是四秒更新一次，接口什么都在调整，怎么去协调？他们有时候会在提交代码的时候为了避免单元测试破坏的情况，代码动过没有问题，但是不要动出问题，但是这种时候不可避免需要去跟他们交涉，通常会有一个总体的架构团队来负责比较核心的操作，他会通知昨天晚上我们某个组做了某个大的改动，你们今天全部检查一下全部的问题，所以不要指望全自动化，这是不现实的。我们现在很多东西在讲开发环境和开发流程，人们总是说要重视开发环境什么的，这个问题越来越受到人的注意，这个东西是要开发流程的工作，有的东西就是需要人去完成，工具是来减少人的操作，比如说怎么去统一代码，怎么去更新，但是遇到问题该有人去做还是要去做。

作者介绍：
张力柯，腾讯Turing Lab副总监。毕业于美国德克萨斯大学圣安东尼奥分校并获得计算机科学博士学位，曾先后在美国微软、BCG、Uber及硅谷其他创业公司担任过从研发工程师到项目负责人等多个岗位，2017年归国后在腾讯游戏品质管理部创建Turing Lab，负责探索前沿AI技术在游戏评测分析及相关领域的实际应用和产品研发。

本文转载自公众号云加社区（ID：QcloudCommunity）。

原文链接：

https://mp.weixin.qq.com/s/U4htId6IvjsXLqr4kAEEdw

创作场景

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