别再增删改查了！后端的尽头是分布式

大家好，今天这篇文章和大家聊聊后端工程师的相关技术。

老实讲我已经好几年没有做过后端了，所以如果单纯只是讲技术的话，可能会有一些技术点已经落后时代了。但是整体的思路以及后端这个领域的特点还是可以讲讲的，所以今天这篇技术的硬干货可能较少，主要还是启发性为主。

什么是后端？

首先来聊聊什么是后端。

对于没有做过后端的同学来说，可能觉得后端就是服务器后台的开发，如果已经毕业了，在互联网公司工作过的小伙伴可能会了解清晰一些，后端整天都在做各种增删改查的操作，所以有些人觉得后端的工作就是增删改查。

如果从功能服务上来区分的话，后端负责的是网站、app所有后台响应的功能。我们日常可以见到的，比如淘宝、比如微信上所有大大小小的功能，所有的后台逻辑都是后端实现的。举个例子好了，比如淘宝购物，我们在手机上的操作只有下单付钱。但是这背后有一大串逻辑，比如说检查库存，检查你的账户余额，再比如进行转账，再比如提交订单，再比如提交和订单关联的发货单……我们看到的页面上只是简单显示下单成功了，但实际上后台执行了很长一段程序。

后端做的就是这些用户看不见，但是非常重要的功能。之前看过一个笑话，说的是有一个小公司由于做了菠菜软件，所以被警察抓了。但是警察不懂，所以只抓了所有的前端，因为觉得前端能看见页面，知道这个是一个菠菜软件，明知故犯。而警察觉得后端只是维护维护的，可能不知情就给放了。但其实所有的逻辑部分都在后端手上，后端肯定比前端还要清楚……

听起来好像还可以对吧，但在实际工作当中，后端的工作尤其是刚入门的就相对比较乏味了，往往就是一水的增删改查。这也不能怪，因为后端通常和数据库直接交互，对于数据库来说最直接的操作就是增删改查这四种。不知道会不会有同学看到这里觉得，那后端的工作是不是很简单呢？需要用到的技术也不多呢？

实际上又错了，后端这个岗位非常繁杂，涉及的技术也是出了名的多。说白了，增删改查虽然简单，但是想要把增删改查做好却并不容易。

后端有哪些技术？

如果这个问题问一个老后端，他掰掰手指可以给你罗列出一堆的名词来。比如设计模式、数据库优化、框架、JVM、网络编程、并发编程、锁设计……

这么多名词我们要是一个一个过估计得写成百科全书，所以我们简单一些。我把它简单总结了一下，大概可以分成三个部分。分别是语言、框架以及分布式。

语言

先从语言开始，这里的语言并不只是简单的Java、或者是Go这种语言基础，还会结合语言本身的特性涉及很多其他的东西。

以Java为例，除了需要了解和掌握Java常用的各种语言特性以及功能之外，还需要对Java这门语言本身的一些特点进行了解。比如说Java的GC（垃圾回收）原理，我们什么情况下会触发Java的GC，Java的GC又是如何操作的，它带来的影响又是什么？我们针对频繁GC的情况怎么优化？

再比如JVM，JVM当中都有哪些配置，这些配置会有哪些影响？我们什么时候需要修改JVM的配置？

再比如Java多态、抽象类、接口、泛型这些进阶的用法，再比如基于Java实现的设计模式……

你看，虽然都是围绕Java这一门语言展开的，但是涉及到的技术却一点也不少。这些可以说都是后端的基础，一个刚毕业的新人可能不懂，但是对于老法师而言，这些都是必会的技能。如果基础没打牢，在以后的职业发展当中很容易翻车。

框架

不管是什么语言，做后端几乎都会有一些自己的框架。

框架这个词是从英文framework翻译过来的，很多人理解不好。其实简单一些举个例子，如果把做一个完整的后台程序比喻成起房子，那么框架就相当于是毛坯房。显然相比于自己费心费力去打地基、造骨架，直接从别人那里把现成的毛坯房搬运过来要容易得多。落实到具体的内容上，如果我们从零开始实现一个后台程序的话，我们需要做很多事情，比如说通过socket监听网络端口，再比如多线程处理获取的请求，再比如组装前端需要的数据格式等等……

而框架当中已经替我们做好了这些事情，我们都只需要安装好框架，这些事情都可以省略。Java现在比较主流的框架是SSM框架，Spring + SpringMVC + MyBatis。这三个框架各有作用，组合在了一起可以很容易创建出功能强大代码简洁的后端程序。

正是由于框架非常重要，所以仅仅停留在会用上是不够的，老法师们还需要对框架的原理甚至是源码做更深入的了解。

分布式

分布式后端当中的一个大块，也是最重要的一大块，所以本文的标题才会说后端的尽头是分布式。

分布式在后端当中又可以分为两块，一块是分布式中间件，还有一块是系统设计。没做过后端的应该没有听说过，中间件对于后端来说非常重要，也是非常常用的工具。可以把中间件理解成通用服务或者是企业内的通用工具，我以消息系统举个例子。消息系统顾名思义主要是用来传递消息，可以简单看成是一个消息队列，可以根据程序员的需要将消息存储在队列当中，使用方可以根据自己的需要来进行读取。比如ABC三个team都需要使用某一份日志，有了消息系统之后，ABC只需要各自监听消息系统，进行消费即可。如果采用上游分发数据的做法，上游需要维护一个下游的分发list，而且数据也需要重复发送许多次，非常不优雅。

除了消息系统之外，还有很多其他的中间件，比如负责缓存、存储数据的分布式存储，再比如RPC框架等等。

另外一块是系统设计，因为后端本身就是基于分布式设计的，几乎没有人的后端程序只运行在一台机器上，往往都会有多台机器同时相应。多台机器和一台机器的区别并不仅仅是机器数量更多而已，会产生一系列数据一致性的问题。架构师们要做的就是根据业务的需要设计系统，使得可以在满足当前要求的前提下，还能保证未来方便拓展，并且保证不会出现不能容忍的错误。

浅谈一下分布式

分布式系统本身是一个非常宏大的概念，也非常困难，容易脱发的同学不建议挑战。我也没有这个能力吃透整个体系，只能说是略知一二。

我们都知道后端服务器做的数据请求最后往往都会抽象成增删改查这四种操作，增就是插入一条数据。比如我们用户注册的功能，本质上就是往注册用户的表当中新增一条从前没有过的记录。删也很好理解， 就是删除一条记录。比如我们注销用户的时候，就会删除一条记录。同理，改和查也都类似，改就是修改数据，查则是查询数据。

增删改查是后端服务器最基本也是最核心的操作，所以单核的服务器大概是下图这个样子。

单核的服务器显然无论是存储能力还是响应能力都是有限的，你能想象微信十几亿用户的所有数据都存在一台机器上吗？显然这是不可能的，没有机器能够承受这么大的数据，这么大规模的请求。

既然扛不住，那么就必须要拆分，这一拆分问题就出现了。我们假设拆分之后的集群里有ABC三台机器在响应请求，大概是下面这样。

这个看起来毫无问题对吧，我们来假设一个场景。假设我现在账户余额里有100块，现在充值话费50，然后再给张三转账100块。显然这是不行的，因为余额不足。但如果我们的这两个请求是落到两台不同的机器上同时处理呢？两台机器各自检查余额的时候都是满足的，但是同时一执行立刻就出现问题了。

那要如何解决这个问题呢？

这个时候一个比较好的策略就是不按照请求进行拆分，而是按照用户拆分，强制安排同一个用户的请求一定会落到同一台机器里，这样就可以保证不会出现同时被执行的情况。再比如我之前写过的关于微博的case，比如微博当中一些大V动辄几千万粉丝，有没有想过这些大V每次发推怎么提醒他们的粉丝？通过循环一个一个通知可行吗？如果不这样，又该怎么解决呢？

大家感兴趣的话，可以阅读一下下面这篇文章。

从头搭建一个“微博”有多难？

尾声

怎么样，大家把后端岗位所需要的技术都搞清楚了吗？

正所谓刚入门的后端做CURD，资深的后端搭框架，老后端设计系统。关于分布式这个部分，虽然很难，但也的确很有意思，很考验思维。但遗憾的是很多初学者做了一段时间CURD，就以为后端一直是CURD，还没有体会到乐趣就放弃成长了，不得不说也是很遗憾了。

完