最近在了解一些概念思想，如果有不对的地方欢迎指出。
系统演变过程：单机结构–主从(高可用、读写分离)–集群结构(负载均衡)–分布式(高并发)
单机结构
举例：一个清扫阿姨，可以打扫一间屋子。
项目应用场景：一个系统业务量很小，所有代码都放到一个项目中，部署在一台服务器上。整个项目都由这一台服务器提供，这就是单机结构。
缺点：处理能力有限，业务增长到一定程度，单机的硬件资源将无法满足业务需求，所以就演变出了集群模式。
主从结构
举例：有一天阿姨请假了，怎么办？再聘用一个阿姨，B是A的备份。
项目应用场景：主从结构，一主一从，从是主的备份。为了达到高可用，主负责写，从负责读，实现读写分离。
集群结构
举例：随着屋子增多，一个阿姨打扫搞不定了，又招来几个阿姨，一起打扫。
项目应用场景：单机处理达到瓶颈的时候，就把单机复制几份，这样就构成“集群”。集群中每台服务器就叫做这个集群的一个“节点”，所有节点构成一个集群。每个节点都提供相同的服务，那么这样系统的能力就提升了好几倍。但问题是用户请求究竟由哪个节点来处理呢？最好能够让此时此刻负载较小的节点来处理，这样使得每个节点的压力都比较平均。要实现这样的功能，就需要在所有的节点之前增加一个“调度者”的角色，用户的请求都先交给他，然后他根据当前所有节点的负载情况，决定将这个请求交给哪个节点处理。这个“调度者”就是【负载均衡服务器】。
优点：系统扩展非常容易，随着业务扩展，集群增加节点就好了，弹性扩容。
缺点：业务到达一定程度，不管如何增加节点都无法提升整个系统的性能。这个时候就引入了微服务结果了。
分布式
举例：请了很多工人，给他们分工，有清扫楼道卫生间的、有擦玻璃的、维修的……构成了保洁公司，大家为了一个目标，就是承包整个大厦的保洁工作。
改变服务要需要思考的点：从单机结构到集群结构，代码基本无需要做任何修改，仅仅是需要部署多台服务器，每台服务器上运行相同的代码就行。但是，当你要从集群结构演进到微服务结构的时候，之前的那套代码要发生较大的改动。所以对于新系统我们建议，系统设计之初就采用微服务架构，这样后期运维的成本更低。但如果老系统需要升级成微服务结构的话，那就得对代码进行大幅度的改造了。所以，对于老系统而言，究竟是继续保持集群模式，还是升级成微服务架构，需要深思熟虑，权衡投入产出比。
项目应用场景：分布式结构就是将一个完整的系统，按照业务功能，拆分成一个个独立的子系统，在分布式结构中，每个子系统就被称为“服务”。这些子系统能够独立运行在web容器中，它们之间通过RPC方式通信。
优点：
1、系统之间耦合度大大降低，可以实现独立开发、独立部署、独立测试，系统与系统之间的边界非常明确，排查错误定位准确，开发效率大大提升。
2、系统耦合度降低，更易于扩展。可以根据业务灵活的对每个服务的节点扩展。
3、服务的复用性更高。
微服务
优点：业务解耦方便扩容，模块重用，方便代码管理和优化。
缺点：系统之间的关系变得复杂，业务增多，底层的模块需要高可用和并发，需要分布式Session框架的支持，分层后也增加测试的复杂度（分布式服务框架要解决的问题）
所以分布式框架都会且不仅限于实现下列功能：
微服务发布（HTTP/RPC）
服务调用代理及客户端软负载
基于Token的安全认证框架
服务治理（服务注册/管理/配置推送等）
服务监控（调用链分析）
测试平台
分布式：不同模块部署在不同服务器上
作用：分布式解决网站高并发带来问题
集群：多台服务器部署相同应用构成一个集群
作用：通过负载均衡设备共同对外提供服务
SOA：业务系统分解为多个组件，让每个组件都独立提供离散，自治，可复用的服务能力，通过服务的组合和编排来实现上层的业务流程
作用：简化维护,降低整体风险,伸缩灵活
微服务：架构设计概念,各服务间隔离（分布式也是隔离）,自治（分布式依赖整体组合）其它特性(单一职责,边界,异步通信,独立部署)是分布式概念的跟严格执行SOA到微服务架构的演进过程
参考资料：https://www.zhihu.com/question/20004877
https://blog.csdn.net/heatdeath/article/details/79038795