1.分布式



　　 微服务和分布式的区别
将一个大的系统划分为多个业务模块，业务模块分别部署到不同的机器上，各个业务模块之间通过接口进行数据交互。区别分布式的方式是根据不同机器不同业务。
上面：service A、B、C、D 分别是业务组件，通过API Geteway进行业务访问。
注：分布式需要做好事务管理。
2.分布式是否属于微服务？
答案是肯定的。微服务的意思也就是将模块拆分成一个独立的服务单元通过接口来实现数据的交互。
3.微服务架构
微服务的设计是为了不因为某个模块的升级和BUG影响现有的系统业务。微服务与分布式的细微差别是，微服务的应用不一定是分散在多个服务器上，他也可以是同一个服务器。



　 微服务和分布式的区别
分布式和微服的架构很相似，只是部署的方式不一样而已。
分布式服务架构与微服务架构概念的区别与联系是怎样的
分布式：分散压力。
微服务：分散能力。
当下理解
分布式：
不同模块部署在不同服务器上;
作用：分布式解决网站高并发带来问题;
集群：相同的服务;
多台服务器部署相同应用构成一个集群;
作用：通过负载均衡设备共同对外提供服务;
SOA［组装服务/ESB企业服务总线］;
业务系统分解为多个组件，让每个组件都独立提供离散，自治，可复用的服务能力;
通过服务的组合和编排来实现上层的业务流程;
作用：简化维护，降低整体风险，伸缩灵活;
微服务［找到服务/微服务网关open API］;
架构设计概念，各服务间隔离（分布式也是隔离），自治（分布式依赖整体组合）其它特性（单一职责，边界，异步通信，独立部署）是分布式概念的跟严格执行;
SOA到微服务架构的演进过程;
作用：各服务可独立应用，组合服务也可系统应用（巨石应用［monolith］的简化实现策略-平台思想）.

	

-     单体架构     -
什么是单体架构
一个归档包(例如war格式或者Jar格式)包含了应用所有功能的应用程序，我们通常称之为单体应用。架构单体应用的方法论，我们称之为单体应用架构，这是一种比较传统的架构风格。
单体架构示例图
-     单体架构的缺陷     -1.复杂性高
整个项目包含的模块非常多，模块的边界模糊，依赖关系不清晰，代码质量参差不齐,整个项目非常复杂。每次修改代码都心惊胆战，甚至添加一个简单的功能，或者修改一个BUG都会造成隐含的缺陷。2.技术债务逐渐上升
随着时间推移、需求变更和人员更迭，会逐渐形成应用程序的技术债务，并且越积越多。已使用的系统设计或代码难以修改，因为应用程序的其他模块可能会以意料之外的方式使用它。3.部署速度逐渐变慢
随着代码的增加，构建和部署的时间也会增加。而在单体应用中，每次功能的变更或缺陷的修复都会导致我们需要重新部署整个应用。全量部署的方式耗时长、影响范围大、风险高，这使得单体应用项目上线部署的频率较低，从而又导致两次发布之间会有大量功能变更和缺陷修复，出错概率较高。4.扩展能力受限，无法按需伸缩
单体应用只能作为一个整体进行扩展，无法结合业务模块的特点进行伸缩。5.阻碍技术创新
单体应用往往使用统一的技术平台或方案解决所有问题，团队的每个成员都必须使用相同的开发语言和架构，想要引入新的框架或技术平台非常困难。由于单体架构的缺陷日益明显，所以越来越多的公司采用微服务架构解决上面提到的单体架构中的问题。不同于构建单一、庞大的应用，微服务架构将应用拆分为一套小且互相关联的服务。-     SOA架构     -SOA是Service-Oriented Architecture的英文缩写，就是面向服务的架构。这里的服务可以理解为service层业务服务。-     单一应用架构     -当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。-     垂直应用架构     -当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。-     分布式服务架构     -当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。-     流动计算架构     -当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的SOA服务治理方案是关键。Dubbo就是SOA服务治理方案的核心框架。总结：dubbo不仅可以对服务进行治理，而且还可以对服务进行调用。-     微服务架构     -简而言之，微服务架构风格的开发方法，是以开发一组小型服务的方式来开发一个独立的应用系统的。其中每个小型服务都运行在自己的进程中，并经常采用HTTP资源API轻量的机制来相互通信。这些服务围绕业务功能进行构建，并能通过全自动的部署机制来进行独立部署。这些微服务可以使用不同的语言来编写，并且可以使用不同的数据存储技术。对这些微服务我们仅做最低限度的集中管理。
微服务架构示例图
微服务架构的特性
每个微服务可独立运行在自己的进程里，一系列独立运行的微服务共同构建起整个系统。每个服务为独立的业务开发，一个微服务只关注某个特定的功能，如订单管理、用户管理等。微服务之间通过一些轻量的通信机制进行通信，如REST API接口进行调用，可以使用不同的语言与存储技术
全自动的部署机制
微服务架构的优势
1.易于开发和维护
一个微服务只关注一个特定的业务功能，所以它的业务清晰、代码量较少。开发和维护单个微服务相对比较简单，整个应用是由若干个微服务构建而成，所以整个应用也会维持在可控状态；2.单个微服务启动较快
单个微服务代码量较少，所以启动会比较快；3.局部修改容易部署
单体应用只要有修改，就要重新部署整个应用，微服务解决了这样的问题。一般来说，对某个微服务进行修改，只需要重新部署这个服务即可；4.技术栈不受限
在微服务中，我们可以结合项目业务及团队的特点，合理地选择技术栈5.按需伸缩
微服务架构的挑战
1.运维要求较高
更多的服务意味着更多的运维投入。在单体架构中只需要保证一个应用的正常运行；而在微服务中，需要保证几十甚至几百个服务的正常运行与协作，带来了巨大的挑战；2.分布式固有的复杂性
使用微服务构建的是分布式系统。对于一个分布式系统，系统容错、网络延迟、分布式事务等都带来了巨大的挑战；3.接口调整成本高
微服务之间通过接口进行通信。如果修改某个微服务的API，可能所有使用了该接口的微服务都需要做调整；4.重复劳动
很多服务可能都会使用到相同的功能。而这个功能并没有达到分解为一个微服务的程度，这个时候，可能各个服务都会开发这一功能，导致代码重复。
微服务设计原则
单一职责原则
服务自治原则
轻量级通信原则
接口明确原则-     微服务架构和SOA的区别     -微服务架构强调的第一个重点就是业务系统需要彻底的组件化和服务化微服务不再强调传统SOA架构里面比较重的ESB企业服务总线，同时SOA的思想进入到单个业务系统内部实现真正的组件化。
分布式-微服务-集群的区别
service A、B、C、D 分别是业务组件，通过API Geteway进行业务访问。将一个大的系统划分为多个业务模块，业务模块分别部署到不同的机器上，各个业务模块之间通过接口进行数据交互。
区别分布式的方式是根据不同机器不同业务。
注：分布式需要做好事务管理。
集群模式
集群模式是不同服务器部署同一套服务对外访问，实现服务的负载均衡。
区别集群的方式是根据部署多台服务器业务是否相同。
注：集群模式需要做好session共享，确保在不同服务器切换的过程中不会因为没有获取到session而中止退出服务。一般配置Nginx*的负载容器实现：静态资源缓存、Session共享可以附带实现，Nginx支持5000个并发量。
分布式是否属于微服务?
答案是肯定的。微服务的意思也就是将模块拆分成一个独立的服务单元通过接口来实现数据的交互。
微服务架构
微服务的设计是为了不因为某个模块的升级和BUG影响现有的系统业务。
微服务与分布式的细微差别是，微服务的应用不一定是分散在多个服务器上，他也可以是同一个服务器。
分布式和微服的架构很相似，只是部署的方式不一样而已。转载源：意识流丶

	

一、需要的环境如下：
IDEA,JDK8,Maven,SpringBoot基础，linux(centos7),dubbo(2.7.0)
virtualbox(用来装虚拟机，和模拟分布式的环境)。
二、传统互联网架构到微服务分布式架构的演变的过程：
简介：单机应用和分布式应用架构演进基础知识
     互联网时代演变过程
           pc时代-->移动互联网时代-->物联网时代
①、传统单体架构
如果程序扛不住了，可以这时加一个缓存，就可以很好的解决相应的问题。
而且这个应用程序是部署到单台的机器上去的。随着用户量的增长。就会
变成下面的图
缺点：系统耦合度高，开发效率随着时间的增长而减低，启动应用的时间长。
依赖庞大等等。
适用场景：初创公司，业务场景简单，功能单一，研发人员较少。
②、传统单体架构的扩展
保证应用程序部署在多台的服务器上面，通过相应的负载均衡的工具来把用户的请求去负载均衡( 比如nginx)到不同到不同的应用程序上面去，然后再对相应的数据进行一个保存。这时就会能够承受更高的并发。
但是随着业务的增长，整个程序的开发变的比较麻烦。这时就有了下面的图：
③、单体架构解耦
在水平上进行一个拆分，最主要的是把原先的一个单体的应用分成了网关层(用于用户的鉴权)，业务逻辑层(处理业务)，数据访问层(访问数据/对数据进行持久化)。
为了提高更高的并发量，就引入了下面的图:
④、异步架构
用户的请求来到nginx,然后去到相应的网关层，然后通过MQ进行异步的解耦，然后到业务逻辑层，然后到数据访问层，最终到数据库。这就是简单的异步架构。
随着用户的急剧的增长，这时就到了soa的架构
⑤、soa架构
soa架构就是对服务进行了拆分，而且引入了服务配置和服务治理。soa是比较依赖企业服务总线的。
⑥、微服务架构
微服务和soa架构是非常相似的，很多思想是从soa架构借鉴过来的。但是在微服务架构中去掉了ESB。这就是两者的最大的区别。
优点：易开发， 理解，维护
          独立部署和启动
缺点：需要管理多个服务，在架构的层面变的复杂。
          服务切分之后，服务之间的调用可能需要去解决分布式事务的问题

微服务是架构设计方式，分布式是系统部署方式
微服务：
就是将一个软件的功能进行拆分，比如某个功能经常使用或经常不使用，可以将该功能单独的设计为一个微服务。通过RPC（远程接口调用，一般通过网络进行调用不是部署在同一台机器的）对该功能进行调用（该句的内容包含了分布式的内容）。微服务之间可以使用不同的语言进行书写。只要按照约定的规范发送请求和接收数据。
微服务架构：
在做架构设计的时候，先做逻辑架构，再做物理架构，当你拿到需求后，估算过最大用户量和并发量后，计算单个应用服务器能否满足需求，如果用户量只有几百人的小应用，单体应用就能搞定，即所有应用部署在一个应用服务器里，如果是很大用户量，且某些功能会被频繁访问，或者某些功能计算量很大，建议将应用拆解为多个子系统，各自负责各自功能，这就是微服务架构。
分布式：
分布式的意思分为两种，一种是将不同微服务进行部署，用以完成某个项目或应用。第二种意思是对同一个应用或功能部署在多台机器上，比如zookeeper就是一个分布式的应用。还有就是该应用或服务的访问量特别的大，一台服务器可能无法承受该数量的访问，可以将同样的应用或服务部署到多个服务器上，再部署一个带有负载均衡算法的服务，就可以将访问的压力分布在各个服务器上，达到提高应用或服务系统抗压的能力。
微服务框架SpringCloud与Dubbo的区别
相同点：

SpringCloud 和Dubbo可以实现RPC远程调用框架，可以实现服务治理。

从更新迭代速度分析

Dubbo目前更新速度没有SpringCloud快，到SpringCloud2.0后SpringCloud会越来完善和稳定。

从开发背景角度分析

Dubbo的开发背景是阿里巴巴， 在中国也推出了非常多的优秀的开源框架

但是在SpringCloud的背景是Spring家族，Spring是专注于企业级开源框架开发，在中国，或者在整个世界上Spring框架都应用的非常广泛。所有相对来说SpringCloud的背景比Dubbo更加强大。

个人理解

由于SpringCloud是spring全家桶中的一员，所以他与spring的其他框架具有更加好的兼容性，且SpringCloud与其他应用的适配做的比较好，能够非常简单的就能与其它应用进行融合。Dubbo只是一个开发好的微服务框架，如需与其他应用进行相应的组合或协作需要自己进行相应的开发和修改，对使用者的水平要求较高。
参考文章：https://blog.csdn.net/zhonglunsheng/article/details/83153451