服务治理篇-应用架构的演变

应用架构的演变讲的文章很多了，但是我看这些文章，包括我自己之前写的两篇文章《美团分布式服务通信框架及服务治理系统OCTO》和《服务治理的技术血脉》，其实没有把概念讲得特别清楚。感觉乍一看是这么回事，仔细一想满脸问号。

Dubbo官网上有一个架构演进的介绍。并附有下面这张图。

内容参考地址：

​​https://dubbo.apache.org/zh/docs/v2.7/user/preface/background/​​

这段介绍代表了整个业界应用演进的大致方向，但不够全面，侧重于服务治理要解决的问题。本文整体采用

要素型逻辑结构，从不同方面深入对应用架构演变的认知。

单一应用架构

当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据库访问框架(ORM)是关键。

我在07年毕业的时候，基本上项目还是采用这种架构。08年我在日本给著名化妆品公司“资生堂”做项目。这个项目成本估算为300人月。光开发人员就几十个。代码全都写到一个应用中。

其中我记忆最深的功能是开店和闭店。每天上班要执行开店，就是要启动应用，启动耗时1小时。每天下班要执行闭店，就是关闭应用，关闭耗时1小时还多。这个应用在资生堂所有门店应用之后，门店的工作人员因这个应用要早上班1小时，晚下班1小时。

当时我们是和东芝合作的，也算是日本鼎鼎有名的企业了。这堪比蜗牛的运行速度放在现在简直不可想象。主要就是因为应用做的事情太多了。

那时候还没有代码静态检查、安全扫描、执行全量单元测试检查覆盖率这些常规保障措施。要是有，开发小哥哥更哭了。这些检查执行速度和代码量有很大关系。想想看，资生堂那个项目的话，提交代码到检查完成，按照现在一般的检查执行速度，七八个小时吧。可以想象，DevOps毫无用武之地。

前后端分离架构

为了解决上面图中四点问题，前后端分离架构应运而生。这种架构前端项目与后端项目是两个项目，放在两个不同的服务器，需要独立部署，两个不同的工程，两个不同的代码库，不同的开发人员。前后端工程师需要约定交互接口，实现并行开发，开发结束后需要进行独立部署。前端只需要关注页面的样式与动态数据的解析&渲染，而后端专注于具体业务逻辑。

这种架构对应对项目复杂性没有质的改善，最大的作用是开发人员不再需要是全栈工程师，人员分工有了初步的分工。在扩展和协同上的问题依然严峻。

垂直应用架构

当访问量主键增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的Web框架(MVC)是关键。

这里咱们来思考一个问题：什么是垂直领域？

09年时我入职人人网。那时人人网刚刚从校内网改名，被炒的很热，招的开发人员背景也都相当的好。那段时间，人人网的技术是经常和百度做比较的。结果却是昙花一现，那么多牛人没能把人人网做得更好。

后来很多人出来自己创业，创业时对人人网的失败做自省。很多人就提到要做垂直领域社交，这种普适性的社交缺少个性化优势。

所谓垂直领域就是专业领域。它是社会分工精细化的产物。前后端分离也是一种垂直拆分。

但是Dubbo官网上介绍应用架构的演变时提到的垂直应用架构并不完全是这个意思。它的垂直拆分更纯粹些，应用之间是完全独立的，很少有交互，就像上面图中的样子。比如微信和QQ。不然也不会说用于加速前端页面开发的Web框架(MVC)是关键。但是在业界说垂直领域、垂直应用都是按专业领域划分没有任何问题。以AKF扩展立方体里对Y轴的描述为准。

分布式服务架构

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速地响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架(RPC)是关键。

咱们来思考一个问题：什么是分布式？

其实分布式是分布式计算的简称。分布式系统就是采用分布式计算的系统。分布式计算是计算机科学中一个研究方向，它研究如何把一个需要非常巨大的计算能力才能解决的问题分成许多小的部分，然后把这些部分分配给多个计算机进行处理，最后把这些计算结果综合起来得到最终的结果。

白话来说：一个程序或系统，只要运行在不同的机器上，都可以叫做分布式。它是以缩短单个任务的执行时间来提升效率的。因为最终需要将结果综合起来，所以关键点在于通信。在这种架构趋势下，以RPC为核心的服务治理应运而生，Dubbo是其中的典型代表。

流动计算架构

当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA)是关键。

这段来自Dubbo官网的描述，我最初看到的表情是这样的：

资源调度和治理中心≈SOA吗？当然不是，SOA是面向服务的意思，Dubbo官网所说的服务专指服务治理平台。服务治理平台负责资源调度和治理中心。它和分布式服务架构的区别是分布式服务架构是应用服务之间彼此通信。而SOA是以服务治理平台为总线，进行统一管理。说白了是SOA的一个应用。

这里的流动计算架构按照刚才的分析就是面向服务治理的架构。两者是否能划等号呢？

流动计算架构按照英文Elastic Computing直译可叫做弹性计算架构，有动态的意思。简单的分布式计算，两两之间通过RPC调用，从一个节点的角度仅能看到其上下游，有点管中窥豹的意味。如果有一个中心节点，它可以站在更大的视角，就可以对整体的请求做动态分发路由了。这就包含将请求发往处理能力更强的节点，如果监控到整体处理能力不足，可以有动态添加节点或者限流熔断等一系列的能力。就是说面向服务治理的架构实现了流动计算。

云计算架构

按照Dubbo官网的描述方式，我斗胆给出流动计算架构下一代架构的描述：

当服务数量攀升、复杂性越来越高，由于通信引发的网络调用、限流、熔断和监控等问题需要让开发者不感知，无侵入性的实现。此时，用于服务间通信的基础设施层服务网格是关键。

像上面一样，咱们来探讨一下云计算架构和服务网格的关系。

云计算（cloud computing）是分布式计算的一种，指的是通过网络“云”将巨大的数据计算处理程序分解成无数个小程序，然后，通过多部服务器组成的系统进行处理和分析这些小程序得到结果并返回给用户。云重点突然一个多字，是服务数量激增量变引起的质变。

服务网格是云计算架构的解决方案。它是将服务治理平台这种PaaS层下沉到IaaS层成为对用户更加透明的基础设施。经常听说某某大厂在做自下而上的服务网格，本质上是将现在公司使用的服务治理不断下沉，让用户体验更加友好的过程。

总结

本篇文章用阅读理解的方式叙述了应用架构的演变。本质上除了文章中的论点，如之前的很多文章一样，暗线在讲技术学习方法：以提出问题为驱动，以解决问题为整合、用输出倒逼输入