分布式

单系统

所有的代码都在一个工程里，最多可能就是通过maven等构件工具拆分了一下代码工程模块，不同的模块可以放在不同的工程代码里。

在部署的时候，可能就是直接在线上的几台机器里直接放到里面的tomcat下来运行。很多流量很小的企业内部系统，比如OA、CRM、财务等系统，甚至可能就直接在一台机器的tomcat下部署一下。然后直接配置一下域名解析，就可以让这个系统的可能几十个，或者几百个用户通过访问域名来使用这个软件了。

只不过为了所谓的“高可用”，可能一般会部署两台机器，前面加一层负载均衡设备，这样其中一个机器挂了，另外一个机器上还有一个系统可以用。

但是团队越来越大，业务越来越复杂, 小团队你搞一个代码仓库，然后就一份代码，每个人都在自己本地写代码，最后把代码合并一下，做做测试，然后就直接部署基于Tomcat来就可以了。几十个人维护一个单块系统，大家在一个工程里写代码，大量的冲突以及代码合并都会让人崩溃。比如某个功能模块要上线了，但是他必须得把整个单块系统所有的功能都回归测试一遍才敢上线. 因为`大家的代码都在一个工程里，都是耦合在一起的，你修改了代码，必须全部测试一遍才能保证系统正常。

分布式系统

因此分布式出现：庞大系统分而治之

这个时候就可以尝试把一个大的系统拆分为很多小的系统，甚至很多小的服务，然后几个人组成一个小组就专门维护其中一个小系统，或者每个人维护一个小服务。简单来说，就是分而治之，这样每个人可以专注维护自己的代码。

不同的小系统自己开发、测试和上线，都不会跟别人耦合在一起，可以自己独立进行，非常的方便，大大简化了大规模系统的开发成本。

不同的子系统之间，就是通过接口互相来回调用，每个子系统都有自己的数据库，大家看下面的图。

分布式系统所带来的技术问题

你的系统一旦分布式了之后，通信、缓存、消息、事务、锁、配置、日志、监控、会话，等等各种原来单块系统场景下很容易解决的问题，都会变得很复杂，需要引入大量外部的技术。

• (1)分布式服务框架

  你如果要让不同的子系统或者服务之间互相通信，首先必须有一套分布式服务框架。也就是各个服务可以互相感知到对方在哪里，可以发送请求过去，可以通过HTTP或者RPC的方式。在这里，最常见的技术就是dubbo以及spring cloud，当然大厂一般都是自己有服务框架

• (2)分布式事务

  一旦你的系统拆分为了多个子系统之后，那么一个贯穿全局的分布式事务应该怎么来实现? 这个你需要了解TCC、最终一致性、2PC等分布式事务的实现方案和开源技术。

• (3)分布式锁

  不同的系统之间如果需要在全局加锁获取某个资源的锁定，此时应该怎么来做? 毕竟大家不是在一个JVM里了，不可能用synchronized来在多个子系统之间实现锁

• (4)分布式缓存

  如果你原来就是个单块系统，那么你其实是可以在单个JVM里进行本地缓存就可以了，比如搞一个HashMap来缓存一些数据。但是现在你有很多个子系统，他们如果要共享一个缓存，你应该怎么办?是不是需要引入Redis等缓存系统?

• (5)分布式消息系统

  在单块系统内，就一个JVM进程内部，你可以用类似LinkedList之类的数据结构作为一个本地内存里的队列。

  但是多个子系统之间要进行消息队列的传递呢?那是不是要引入类似RabbitMQ之类的分布式消息中间件?

• (6)分布式搜索系统

  如果在单块系统内，你可以比如在本地就基于Lucene来开发一个全文检索模块，但是如果是分布式系统下的很多子系统，你还能直接基于Lucene吗?　明显不行，你需要在系统里引入一个外部的分布式搜索系统，比如Elasticsearch。

• (7)其他很多的技术

  比如说分布式配置中心、分布式日志中心、分布式监控告警中心、分布式会话，等等，都是分布式系统场景下你需要使用和了解的一些技术。因为沿用单块系统时代的那些技术已经不行了，比如说你单块系统的时候，直接在本地用一个properties文件存放自己的配置即可，日志也写到本地即可。