一、分布式和微服务架构的定义
分布式应用场景涵盖的面非常广，我理解的部分：
不同进程之间的互相通信，
不同主机的分布式对象之间调用，
用于大数据存储的分布式文件系统，
用于网络之间相互识别的命名服务，
集群中计算或存储的无中心对等模型，
分布式事务，
数据副本在分布式环境中的复制，
云计算服务，
音视频在网络中的点播和传输
....
微服务架构的目的是对原来过于大而重的云应用服务进行解耦，手段是进行比较合理的业务模块拆解，拆解的粒度往往由架构师掌握，实现细粒度的服务，服务在云端形成分布式状态。
那么微服务就具有了分布式的一些应用场景，比如：不同主机的分布式对象之间调用，以前EJB用RMI（远程方法调用），现在微服务常用RPC（远程过程调用）；再比如：用于网络之间相互识别的命名服务，以前EJB是JNDI命名服务，现在SpringCloud的Euraka用于微服务的注册和发现，也是分布式是命名服务。
如何通俗地理解「分布式系统」，它解决了哪些问题，有什么优缺点？
理解「分布式系统」曾经发生的事情
上面是我另外一个回答，里面比较详细地描述了历史上过去EJB和Spring的比较，也是分布式与单体应用的比较。那时候EJB代表分布式服务，而spring代表单体服务。
上面的图简单的描绘了一种最简单的单体服务向微服务拆解的过程。当然微服务面临的挑战不仅仅这么简单，这只是微服务的一种比较初始的状态。
二、分布式和微服务这两者解决了什么问题分布式是计算、服务、存储在网络中互相交流与协作的形式和状态
分布式到底解决了什么？
上图就是典型的分布式计算，一个大文件被切分成四份，MapReduce分成四个任务（进程），然后在同一主机不同进程，或不同主机上进行数据处理，最终再通过网络汇聚到一个合并任务。那么这个时候到分布式就是任务并行，解决了单任务的效率问题。
上图是个典型的分布式状态协调管理图，是Hadoop HDFS集群的HA高可用架构，主副两个Namonode节点，必须活着一个，当判断主的挂了，必须让副的顶上去，这个时候，三个ZK（zookeeper）组成的集群就是作为主副节点的协调者，通过ZKFC进程实现对Namoenode节点的心跳监控和切换命令下发。
另外三个Journalnode节点形成的集群又是namonode分布式状态数据保存的地方，当主namonode挂了，所有的状态必须快速的恢复到副namenode的上面，所以Journalnode必须持续同步状态，满足hdfs集群状态的快速恢复
那么分布式中非常关键的一个应用场景——集群，上述的Hadoop hdfs集群，就需要有一个或几个角色(zookeeper，Journalnode)，作为集群状态的协调者和管理者。有时候这种状态管理是对等的(GlusterFS)，有时候这种状态管理是集中的（Hadoop就是这样）。
微服务又解决了什么问题呢？
如果这时候在提微服务的分布式优势，就不是目的，而是手段了。微服务只是借助了分布式架构，达到了自己的目的。所以微服务不是基础技术架构的问题，而是上层应用的架构问题。
上面的例子是个简单的互联网医疗服务单体应用，这时候问诊、药品、订单、即时消息都是互联网医疗最核心的业务，信息推送目的是将互联网医疗平台的各类信息进行互联网信息服务平台的推送、发布和交流，达到自我推广的目的。
可恰恰信息推送服务的更新程度很高，因为需要对外连接的互联网服务平台情况复杂，也会有新的服务平台纳入到模块范围，那么作为单体应用就存在这样一个部署问题，每次更新一个新的信息推送功能，就要整体服务重新部署一次，那么这种影响对于核心服务就造成了很大的困扰，这时候的患者、医生、医院的业务影响都是大规模的。