摘要：互联网技术架构的演变的节点：单体架构-->集群架构-->分布式架构-->微服务架构，最终才到了现在的比较火的微服务架构。
话说最近几年微服务可谓是生龙活虎，不亚于任何网红明星(IT圈)，从各大互联网公司都在相继建设微服务，到现在就连几个人的小公司也动不动就微服务，仿佛现在不搞点微服务相关的技术，就显得很low了。
为了不让广大程序猿不被人看不起，能做一个可以昂首挺胸的程序猿，今天咱们就来谈一谈微服务。
互联网技术架构演变
为了让大家能够更好的了解什么是微服务架构，那就得先了解下微服务的前世今生。
其实互联网发展到今天的状态，也是经历了很多次迭代，从最初的单体架构到微服务架构其实是一个很漫长的旅程。
有几次比较重要互联网技术架构的演变的节点：单体架构-->集群架构-->分布式架构-->微服务架构，最终才到了现在的比较火的微服务架构。每一种技术架构的演进都伴随着互联网行业的发展，以及用户数量的增加，同时也促进了技术的快速更新迭代。这其实也是一部互联网的发展史。
单体架构
首先，咱们先来说下什么是单体架构。顾名思义，单体就是一个独立的个体，也就是一个项目的所有的功能模块(比如订单模块，用户模块，商品模块等)都集中一个项目当中，最终打成一个war包，可以直接部署上线。
看似简单粗暴，但是对于那个处于草莽时代的互联网来说，这种可以快速上线满足业务需求的方式无疑也是最高好的方式。因为在这个时期的用户量很少，一个服务器就足撑起整个网站。
集群架构
如果说单体架构是一对一的单挑，那集群架构就是打群架了。因为随着用户量的增加，此时单一的服务器已经无法支撑起用户的访问，动不动就挂掉的网站肯定是没有人愿意使用的。
所以此时为了解决这个问题，人们就开始想办法，一个服务器撑不了，那我就搞一对；一对还不行，我就搞两对...最终我们把同一个war包，同时部署到多个服务器上，终于搞定了，这就是我们的集群架构时代。
分布式架构
我们搞定的集群架构的项目终于可以支撑起当前用户量了，但没想到就在这个时期，也正是互联网大爆发的时刻，用户数呈指数级增长，原来的集群又面临着挑战。
这个已经不是简单的增加服务器那么简单的事儿了，因为这个时期，互联网业务已经变的极其复杂。所以这次互联网技术架构的演进是有了本质上的改变，即分布式架构：分布式结构就是将一个完整的系统，按照业务功能，拆分成一个个独立的子系统。
在分布式结构中，每个子系统就被称为“服务”。这些子系统能够独立运行在web容器中，它们之间通过RPC方式通信(阿里开源Dubbo框架)。说人话就是将订单模块单独部署到一个服务器，用户模块单独部署到一个服务器上，商品模块也可以单独部署到一个服务器上。
不仅如此，每一个模块又可以进行集群部署，如下图。此时的分布式架构是可以满足现在的业务需求的。而各个模块之间的是通过RPC(远程服务调用)的方式来通信。
微服务架构
我们刚才说了，分布式架构是可以满足现在大型互联网的业务需求的，那为什么我们还要一个劲儿的非要搞什么微服务呢，所以我们不禁要这样几个问题：
什么是微服务？
为什么要用微服务？
它有什么好处？
什么是微服务
微服务的概念源于2014年3月Martin Fowler（微服务的提出者）所写的一篇文章Microservices。
微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。
上图中每一个色块都是一个服务，翻译一下就是微服务架构是一种架构的风格，可以让我们的业务模块更加的细化。
如：商品模块我们可以在细粒度的拆分，直到不可以拆分为止，那到底拆分的力度有多细，要根据自己的业务情况和团队实力来评估。
这样做的好处：
·不会牵一发动全身
可以对微服务架构中的每个组件服务进行开发、部署、运营和扩展，而不影响其他服务的功能。
这些服务不需要与其他服务共享任何代码或实施。各个组件之间的任何通信都是通过明确定义的API进行的。
·各司其职每项服务都是针对一组功能而设计的，并专注于解决特定的问题(支付模块就解决支付的问题)。
为什么要引入微服务
从生产力和系统的复杂性这两个方面来看。公司一开始的时候，业务复杂性不高，这时候是验证商业模式的时候，业务简单，用单体服务反而生产力很高。
随着公司的发展，业务复杂性慢慢提高，这时候就可以采用微服务来提升生产力了。而事实证明，微服务架构虽然对开发人员的要求提高了，但是从企业长久发展来看，无论从系统层面还是从成本控制都是非常有利的，这也为什么现在无论大小公司都是直接上微服务。
微服务有什么好处？
1.敏捷快速迭代
微服务让若干小型独立团队形成一个组织，这些团队负责自己的服务。并且可以更独立、更快速地工作。缩短开发周期。
2.灵活扩展
通过微服务，您可以独立扩展各项服务以满足其支持的系统功能的需求。这使团队能够快速调整，准确功能成本，并在服务需求激增时保持可用
3.可重复使用的代码
将软件划分为小型且明确定义的模块，让团队可以将功能用于多种目的。专为某项功能编写的服务可以用作另一项功能的构建块。这样应用程序就可以自行引导，因为开发人员可以创建新功能，而无需从头开始编写代码。
这次主要是从互联网技术架构的演进规律来给大家介绍了微服务的概念：
单体架构的演进
集群架构的演进
分布式架构的演进
微服务架构
大家可以理解成单体架构-->集群架构是一个聚合的过程，就是通过增加服务器等设备来解决问题。
而从集群-->分布式-->微服务是一个拆的过程，就是把原来的很多的模块从一个大的项目中拆分出来，独立部署。
所以其实微服务架构就是一种把业务功能模块进行细粒度拆分的架构风格。