分布式和微服务目前已经成为了web业界最主流的开发模式，不论是互联网产品还是传统企业级应用，为了提高产品的开发效率，开发成本，以及访问效率等，分布式和微服务联合都是不二选择。
今天就来简单了解一下微服务，分布式，集群的相关理念。
首先来了解一下计算机软件发展史
通过上图，可以看出计算机软件主要经历了3个发展阶段。
1、c/s阶段： 这是一种客户端自定义方案，一般我们看到的qq、迅雷、暴风等都是c/s架构模式的产品。
2、web1.0阶段： 提供一些静态的网页供用户浏览，网页信息都是少数人发布，缺少和用户交互。传统的3大门户就是在这个阶段诞生的 搜狐/新浪/网页
3、web2.0阶段： 注重和用户的交互，每个人都可以是信息内容的发布者。
案例： 电商，头条，博客，微博，抖音，共享资源等等。
在web2.0阶段之后，由于每个人都是信息内容的发布者，这就会直接导致一个现象：那就是数据量极度膨胀，而且是指数式膨胀，用户倍增，访问量难以估计。
最突出的案例就是12306,据说12306网上购票平台刚被推出的时候，当时的系统首席架构师对该系统的并发访问量做了最大预估，可以达到100万的并发访问量，这么大的并发量不可能出现问题。但是实际的情况却让人难以相信，那年春运访问高峰时，仅仅几分钟并发量最高时达到1000万，服务器直接脱机。
面临现阶段并发量如此之高，数据量如此之大的互联网各种系统，如何解决这个问题，阿里巴巴一路走过来，从最开始的ibm小型机到2007年后因为数据量过于庞大改成分布式集群。并且这种模式一直延续至今已经给了我们最好的答案。
什么是集群和分布式
经常会在各种博客论坛上看到，集群，分布式，负载均衡之类的字眼，那么到底什么是集群呢，集群和分布式又有什么区别，看看下面的图。
从图中可以看出，
1、最左边是一个单机一体的系统，所有的业务相关的服务都放在在一台服务器上，这也是最传统的web项目部署方案。但是这种部署方案不好的地方就是：一旦数据量过大，访问量过大，服务器很容易出现崩溃问题，对于用户来说，这是不可接受的。
2、右上方是一种集群多实例方案，就是将单机一体的系统复制成多个一模一样的系统部署在不同的机器上。并且提供一个负载均衡点，以保证客户端访问的多个服务器受到的访问量可以达到一个平衡。
集群的好处: 可以大大减轻系统并发量过大，线程数不够产生的问题。
3、右下方就是分布式理念了，我们知道集群方案可以解决访问量过大产生的问题，但是集群也有不好的地方。
就拿上图来说，现在订单Service负载过大，服务器压力过大，需要添加机器，但是用户和商品Service都处于平稳状态，如果采用集群，那么又要重新将用户、商品、订单都重新部署，这就是对资源的一种浪费。我们为什么不将订单服务单独拿出来部署在一个服务器上面，如果不够在进行拆分呢。
所以分布式方案的概念：简单的说，就是将一些可以单独拿出来的service独立出来，部署在独立的服务器上，以达到普通机器完成不了的计算任务。
什么是微服务
很多人都会将微服务和分布式的概念混淆，其实微服务和分布式有相似的地方，也有不同的地方。
首先他们都是将同一个大系统中不同的子模块进行分开部署。已达到一个低耦合，提高并发量，提高系统可以水平伸缩的能力，同时它们和其他模块之间通讯也都是基于rpc进行通讯调用。
不同的地方在于，微服务它是一个单独的服务，它包含了一个服务从控制层到业务层到持久层该有的东西它都必须要有，甚至前端代码它也可以是自己提供的，并且微服务的持久层数据库是私有的，并不会对其他服务共享。可以用一句简单的话来概括：麻雀虽小，五脏俱全。
而分布式，它可以仅仅只有控制层和业务层，他可以不需要自己的数据库和前端，它可以和其他模块共享一个数据库。
前后端分离，高效开发，分开部署
以前开发web项目，使用java开发都是基于servlet和jsp进行开发，这也是所谓的全栈式开发。这种开发模式有一种非常不好的地方，随着现在前端技术越来越庞杂，后端技术也越来越复杂多变，这就导致程序员需要学习的东西会越来越多，根本无法去集中精力去针对一块进行深入研究，开发。
而且软件本身就是一种多变的不稳定的东西，一个人包揽整个项目的前后端开发，不和其他人进行探讨沟通，很容易会出现功能上或者需求上使用上的疏漏。遇到一些技术问题时，也会很耽误项目的研发进度。
为了解决这个问题，现在各大互联网公司，或者新型的软件企业都非常注重前后端分离开发。现在比较流行的各种mvvm前端框架，如nodejs+vue等。就是一种方式，使用nodejs部署前端资源静态访问服务器。进入指定的html页面，请求ajax访问后端，返回json串格式，或者文件供前端自己解析。
这是一种目前市面上主流的开发模式。