【20211008】为什么分布式服务框架越来越火

时间：2021年10月08日

作者：小蒋聊技术

大家好，欢迎来到小蒋聊技术。小蒋准备和大家一起聊聊技术的那些事。

通过上次的分享，小蒋又重新复习一遍了“单例模式”。一个看似普普通通的“单例模式”，真正要弄得明白，却要在知识、技巧、意愿这三方面持续不断地交替努力，而且还是反复循环才行。

为什么要这样呢？因为，在持续学习的过程中，小蒋开始慢慢理解什么是真正的技术人，技术在他们那里已不再只是知识，技术已经变成他们的自身的思维模式与习惯了。

这种思维模式与习惯的养成和建立，恰恰也是小蒋一直在持续分享的核心内容。小蒋上学的时候，就非常喜欢物理。物理学原理就是物质不会凭空出现，也不会凭空消失。技术其实也是如此， 我们现在生活在互联网时代，我们现在生活的这个时代知识过于碎片化，而且信息爆炸，技术的学习难度变得越来越大，在这种环境下，已近很难再保证你能学习到完整的知识体系了。你需要靠自己的主观能动性，在各种技术信息中穿梭，汇聚，甚至提炼成自己的体系。

有很多技术，我们在学的时候其实就已经过时了，学习仅仅是为了应付考试而已，现实当中几乎没有一点用处。大学阶段的课程中，很多内容都处于这种状态。

我们大家一开始明明都是普通人，每个人一天最原始的资源就是每天24小时。但，为什么有些人就走到了技术的最前沿，不断引领时代的发展。而大多数人则是碌碌无为，一无是处。

小蒋个人理解，这就是互联网这个时代的特点。这个时代不缺少资源，反倒是信息爆炸。所以，如果你想取得某一方面的优势，就必须要聚焦在某几个确切的目标上，并将全部精力都聚焦于选定的目标之上。这种学习方法也正是小蒋一直在坚持与实践的。

今天，小蒋将和大家一起来看看，为什么分布式服务框架最近这两年变得越来越火？

小蒋最近很长时间的工作一直都是围绕着“云”开展的。一个典型的案例就是，为了满足生产需要，业务不断地进行迭代升级，公司内部的系统开始一批接着一批的“微服务化”（Microservices）并迁移上云。

简单的说就是公司里原来的大型复杂系统，开始被一个一个的分解。把一个巨型复杂的系统，拆解成一个又一个的微服务。这些微服务根据业务实际访问量被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。

这些大型而又复杂的系统，你可以把他们看成是一个怪兽。这些怪兽系统的年龄估计有10多岁了，有的甚至更大。 这些怪兽们就是小蒋这代程序员们最早开发的单体型应用，虽然开发和部署比较方便，但后期随着业务的不断增加，开发迭代和性能瓶颈等问题，将会越来越困扰开发团队。

1.咱先看，单体应用框架（ORM）：

2010年是电商行业标志性的年份，第一家B2C电商麦考林在美国上市了。一下子数10亿美元开始涌入这个行业，2010年12月当当网也上市了。

当时网站的流量并不大，只需要一个应用，就可以将所有功能部署在一起。如，下单、支付、后台管理等。这种单体应用可以减少部署节点和成本。

缺点：单体应用架构，随着业务的发展，占用的资源开始越来越多，随着时间的发展和流量的增加系统变得越来越难以维护。

 2.垂直应用框架（MVC）：

随着单体应用的缺点变得越来越突出，垂直应用架构的出现成为了必然。因为垂直应用架构就是为了解决单体应用架构所面临的扩容问题，垂直架构的出现使得流量能够分散到各个子系统当中，且各个子系统的体积可控。在一定程度上降低了开发人员之间协同以及维护的成本，提升了开发效率。

缺点：垂直应用架构中相同逻辑的代码不能复用，代码需要不断地复制。

 

3.分布式应用架构（RPC）

当垂直应用越来越多，应用之间交互变得不可避免。系统分久必合，核心业务抽取就变得随理成章了。这些被抽取出来的核心业务，逐渐形成稳定的服务中心。

 

4.面向服务的体系架构（SOA）

这两年电商业务的发展也逐渐趋于稳定，服务化程度变得也是越是越来越高。所以，服务之间的调用和依赖关系也就逐渐变得越来越清晰。面向服务的体系架构（SOA）也就逐渐成为主流。也因此衍生出了一些列相应的技术，如注册中心、服务调用、连接处理、通信协议、序列化方式、服务发现、服务路由等一系列服务相关框架。

以上是小蒋所在的电商行业系统，这10多年的架构演变过程：

 

• 单体应用架构
  • 初期网站流量有限，应用只需要一个即可。将所有功能部署在一起，部署节点和成本可控。
  • 单体应用架构阶段，主要业务以简单的增删改查为主，数据访问框架（ORM）是关键。

• 垂直应用架构
  • 随着业务的发展，系统的访问量逐渐增大，单体应用靠增加物理硬件带来的性能提升能力变得越来越小。所以，将应用拆分成几个互不相干的应用，以便提升效率，同时也分散流量。
  • 垂直应用架构阶段，主要以拆分应用为主线，使用WEB应用框架（MVC）构建应用是关键。同时还会使用“前后分离”、“动静分离”、“CDN加速”等技术，这些技术都能极大的提升网站性能。

• 分布式服务架构
  • 当垂直应用越来越多时，应用之间的交互就变得不可避免。分久必合肯定是大势所趋，独立的应用之间相同的业务，将会被抽取出来，作为独立的服务，逐渐形成稳定的服务中心，这样前端应用的负担将会减轻，从而有更多的资源响应快速多变的市场需求。
  • 分布式服务架构阶段，在这个阶段，为了提升垂直应用或同类应用的负载能力，强调的是将相同的业务逻辑，抽取为公共服务并分散部署在不同的机器上。分布式服务框架（RPC）是关键。

• 面向服务的体系架构
  • 当服务越来越多，容量的评估、资源的调度、服务的治理等问题逐渐凸显。此时需要有一个专门的调度中心或者叫管理中心基于负载压力实时管理集群的容量，以便提高集群利用率。
  • 面向服务的体系架构阶段，在这个阶段，服务的管理、资源调度、服务治理（SOA）是关键。

文章题目里“最近这几年分布式服务框架越来越火”，这里特指的就是开源的这几个RPC框架，Dubbo、Spring Cloud、Motan、Thrift等。

远程过程调用（RPC）技术，也正是因为互联网时代的高速发展，上网的用户数和可使用的服务数都在快速的增长而产生的。小蒋简单的来解释一下RPC技术，我们在公司里，两个人有事要沟通，叫到会议室面对面谈一下就可以了。但是，公司发展越来越大，在全世界都成立了分公司，要沟通的那个人人家在美国公司里。这时候要沟通，就得打电话了。RPC技术和打电话沟通其实就是一个意思。

我们有两台服务器A、B。分别部署着订单服务和支付服务，当A服务器上的订单服务想要调用B服务器上的支付服务时，由于不在一个内存空间里，他们是无法直接调用的，  需要通过网络来表达调用的语义调用的数据。

说白了，就是你在电脑里有一段代码，我在我的电脑里是无法直接调用的，这个时候就出现了一个远程服务调用的概念，也叫做RPC。

小蒋通过对技术使用的复盘，弄明白了为什么最近分布式服务框架变得越来越火。因为分布式服务框架这个技术符合业务发展趋势。

小蒋我作为一名技术人员，往往只会往前看。换句话说一看到新技术，眼睛就放光，就盯着前沿趋势和技术新版本。对于旧版本，通常提不起什么兴趣。在实际工作中也往往会向前看——而不是向后看——做决定，然后继续前进。

后来，我遇到了一位优秀的架构师同事。我们在聊天的时候，他告诉我，如果我想成为一名优秀的架构师，就必须化时间对过去的经历进行反思，并且从中学习。

如果愿意，过去你所经历的每一次成功和失败都可以成为信息和智慧的宝库。成功让你明白自己擅长做什么，使你充满自信。而失败则可以让你懂得更多。失败可以说明你计划错误、性格缺陷、判断失误或者执行手段不高明等问题。最开始小蒋非常憎恶失败，因此遭遇失败后就想方设法把失败掩盖起来而不是分析失败、从中学习。

后来，当小蒋自己成为了一名架构师后却发现，如果不能从错误中不断总结经验，你将一次又一次的遭遇相同的失败。

写在最后

市面上有很多教人技术速成的书或者视频教程，这类书或者教程小蒋个人非常不推荐，因为这类资料反而背离了学习的本质。如果学习你都要急功近利，这种性格很难通过积累，实现成功。就像天天吃快餐，肯定对健康不利，技术知识也是一样，天天看速成的东西，最终结果就是你越来越懒得思考。

今天分享的内容就到这里。

年龄的增长不可怕，可怕的是从未成长！

感谢大家支持小蒋，小蒋希望和大家共同成长，谢谢。

喜马拉雅音频地址：https://www.ximalaya.com/keji/51588599/460397156https://www.ximalaya.com/keji/51588599/460397156