服务架构模式演化

一、分布式和集群

在介绍分布式架构之前，先说一下单体架构，顾名思义，所谓单体架构，就是只有一台服务器，这台服务器负责所有的工作。

但是一台主机硬件资源是有上限的（CPU、内存、硬盘、网络……），如果业务进一步增长，用户量和数据量都水涨船高，一台主机难以应付的时候，就需要引入更多的主机，引入更多的硬件资源。况且随着业务场景越来越复杂，单体应用也会越来越大，这就会导致代码之间的耦合度过高，一个微小的问题就可能导致整个应用垮掉。

所以为了解决单体架构中的问题，引入了分布式和集群的概念：

集群： 就是引入更多的硬件服务器资源，每个服务器上都部署了完整的应用系统，这样多个服务器就可以通过负载均衡的调度方式完成任务。可以在水平方向（纵向）上缓解单体架构的压力。其中每一台服务器成为集群结点。

分布式： 就是将一个完整的系统，根据业务划分为不同的子系统，部署到多台服务器上。例如可以将应用服务和数据库服务分别部署到不同服务器上；对数据服务器进行读写分离，拆分为主数据库（master）服务器，从数据库（slave）服务器；对数据进行冷热分离，引入缓存服务器。

其实集群和分布式在概念上也并不难理解，下面总结一下他们之间的区别和联系：

1. 集群是多个计算机做同样的事，集群的每个结点功能是相同的，并且可以替代；分布式是多个计算机做不同的事，分布式是多个节点组成的系统。
2. 大多数情况下，分布式和集群都是相互配合使用的，分布式的某一个结点，可能由一个集群代替，所以实际上我们常常把分布式和集群统称为：分布式架构。

二、微服务架构

微服务就是微小的服务，就是将业务进行更细粒度的垂直拆分，可以将一个复杂的服务器，拆分成更多的，功能更单一，更小的服务器。每个更小的服务器就是一个 “微服务”。微服务之间可以采用REST和RPC协议进行通信。
比如说一个电商系统他有用户管理、商品管理、订单管理、物流管理，我们就可以把每一个部分单独拿出来拆分成一个微服务。
分布式架构强调的是压力的分散，服务器的分散化，而微服务更注重的是能力的分散，强调更加专业化和精细的分工。所以通常认为：微服务是一种经过良好架构设计的分布式架构方案。

微服务的优势：

1. 易开发和维护，每个微服务负责的业务比较清晰，体量小，开发和维护成本降低
2. 容错性高，一个服务发生故障，可以使故障隔离在单个服务中，不影响整体服务故障
3. 扩展性好，每个服务都是独立运行的，我们可以结合项目实际情况进行扩展，按需伸缩
4. 技术选型灵活，每个微服务都是单独的团队来运维，可以根据业务特点和团队特点，选择适合的技术栈

引入微服务的代价

1. 系统性能下降。应用服务器拆分之前，各功能模块之间在进程内调用即可，拆分之后就需要通过跨主机进行网络通信，而网络通信可能会比硬盘还慢，因此系统性能可能大大折扣。（幸运的是硬件技术的发展，使得现在万兆网卡的读取速度已经超过硬盘的读取速度，但是需要一定的成本代价）
2. 系统复杂程度提高，可用性受到影响，即系统出现问题的概率就更大了。此时就需要一系列的手段来保证系统的可用性，例如更丰富的监控报警，配套的运维人员等。
3. 开发和测试成本提高，随着服务的数量增多，服务之间的关系也会变得更加复杂，一个服务的更改，需要考虑对其他服务的影响，一个业务流程可能涉及多个微服务共同完成。

PS：我们常听说的 SpringCloud 其实就是分布式微服务架构的一站式解决方案，是微服务架构落地的多种技术的集合，或者说是一套解决微服务问题的规范。