分布式架构的演变过程之单体架构

无论何种技术实现，其学习过程往往都是枯燥无味的，学的越深就越发如是，IT行业更是如此。需要去实现技术是小部分人的工作，如何让不直接接触技术的人知道我们在做什么、怎么做、为什么这么做就显得有那么点意义了。

开始接触分布式和微服务这两个名词的时候分不清谁是谁，慢慢才知道这些根本不重要，无论是说分布式思想或架构还是微服务思想或架构都能表达出意思。按我的理解，微服务是属于分治思想的一种，而分布式架构是基于微服务思想来实现的更高效率支持无限扩展的超大型项目框架。

PS：分治思想（顾名思义，分而治之，此思想贯穿整个计算机底层至屏幕呈现图像实现过程，从算法到架构。最直接的理解就是牺牲部分存储空间，换取一定的运行效率。通俗点的例子：原本电脑桌面有一堆未命名文件，我每次要找到想要的文件必须每个文件都打开看一遍，直到有一天我学会了命名文件，再把同种文件归类到同个文件夹，再把同类文件夹归类到同个盘，以后就不需要每次都去翻一遍全部文件，而且有新文件类型的话也可以支持扩展文件夹。从全量操作转为分量操作）

单体服务架构

最开始，我们只是让数据库中的数据按照一定设计想法显示在屏幕（客户端）上呈现给用户操作。用户通过客户端发送指令，经过服务器处理后，在数据库中操作数据返回后再渲染给客户端无限反复的过程。

经过这么一系列搭建，网站就具备最基本的数据呈现和交互功能。这时候只需要输入IP地址 +端口号（例如127.0.0.1/8080）就可以访问网站了。而绝大部分人输入网址时候都是例如www.xxxx.com等等地址，这个就需要在客户端和服务器之间加入中间件nginx，实现通过域名来代理原本的数字地址，既可便于记忆，也防止直接暴露出地址。

此时需要脑海里模拟一下公司发展过程。随着时间推移，公司越发壮大，客户越来越多，数据库性能慢慢地到达了瓶颈，经常要处理大量的读写操作，已经不堪重负了，一到高峰期客户一个个投诉：“你们网站怎么这么卡？每点一下就要等几秒才有反应”。经过一系列排查确保非人为导致，为了解决这个问题，就必需要缓解数据库部分压力，第一加入缓存中间件redis，把不会经常被改变且会经常被读的数据放到redis里，从而减轻这部分数据访问给数据库带来的压力，第二将数据库读写分离，一个主要负责读操作，一个主要负责写操作（分治），需要用到数据库中间件mycat负责协调。（前后端分离同理，将页面模块交给前端，后端更专注于数据）

PS：后续会基于本文持续更新mysql数据库和redis缓存底层实现、演变和优化。纵观大略，由浅及深。

至此，单体架构的性能基本到达天花板。但是，客户一天天增多，终有一天会重复以前发生的反应变慢的问题。单体架构要突破瓶颈的方法只能做集群，一套架构不行，复制完再加一套，数据库不行了再加一个数据库，服务器集群、redis集群、数据库集群等等都是这个理。
以服务器集群为图例：

集群前期效果明显，后期性能越发乏力，投入成本与效率提升比例加速变大，直到发现无论怎么增加但效果都一般的时候，分布式架构应运而生。

PS：以上是单体服务演变大致全程了，由于分布式架构中间件数量太多了，下一篇再整理springcloud和主要中间件。

题外话：本文多次提到的分治思想，如何做到让专业的人负责对应的事，大幅提升效率的同时还能便于后续维护扩展，在很多领域都是通用的。例如，大公司把不擅长的非核心领域外包给擅长此领域的公司或团队，蔚来公司考虑到电动汽车的电池寿命会拉低整体汽车价值，让电池实现可拆换，从而用户不需要每次花大量时间把整部汽车拖去维修，还有时下处于风口的华为公司，万物互联所用的芯片设计也是基于此思想，做到了芯片上每块单元都可以拆卸更换升级。