微服务是架构设计方式，分布式是系统部署方式程序员
概念
微服务web
简单来讲微服务就是很小的服务，小到一个服务只对应一个单一的功能，只作一件事。这个服务能够单独部署运行，服务之间能够经过RPC来相互交互，每一个微服务都是由独立的小团队开发，测试，部署，上线，负责它的整个生命周期。算法
微服务架构浏览器
在作架构设计的时候，先作逻辑架构，再作物理架构，当你拿到需求后，估算过最大用户量和并发量后，计算单个应用服务器可否知足需求，若是用户量只有几百人的小应用，单体应用就能搞定，即全部应用部署在一个应用服务器里，若是是很大用户量，且某些功能会被频繁访问，或者某些功能计算量很大，建议将应用拆解为多个子系统，各自负责各自功能，这就是微服务架构。缓存
分布式服务器
分布式服务顾名思义服务是分散部署在不一样的机器上，一个服务可能负责几个功能，是一种面向SOA架构的，服务之间也是经过rpc来交互或者是webservice来交互的。cookie
逻辑架构设计完后就该作物理架构设计，系统应用部署在超过一台服务器或虚拟机上，且各分开部署的部分彼此经过各类通信协议交互信息，就可算做分布式部署，生产环境下的微服务确定是分布式部署的，分布式部署的应用不必定是微服务架构的，好比集群部署，它是把相同应用复制到不一样服务器上，可是逻辑功能上仍是单体应用。
微服务相比分布式服务来讲，它的粒度更小，服务之间耦合度更低，因为每一个微服务都由独立的小团队负责，所以它敏捷性更高，分布式服务最后都会向微服务架构演化，这是一种趋势， 不过服务微服务化后带来的挑战也是显而易见的，例如服务粒度小，数量大，后期运维将会很难.
网络
示例讲解
分布式session
小马正在经营一个在线购物网站，名叫TT猫，有商品管理、订单管理、用户管理、支付管理、购物车等模块，每一个模块部署到独立的云服务主机。架构
如今，程序员小明同窗浏览TT猫，想买一款牛逼的cherry机械键盘来提高本身的工做效率。因而他打开TT猫首页、搜索商品、浏览详情以及评论、添加购物车、下单、支付等一系列操做。小明同窗一鼓作气，流畅地完成了购物，固然也花费了很多银子。
但系统又是如何进行这一系列操做，以下图错综复杂的调用关系(自行忽略部分细节)。用户看不见、摸不着，但整个下单过程却行走在网络之间。
集群
TT猫，每一年都会搞一些活动，好比女生最爱的光棍节(双11)，夜深人静的时候会瞬间涌入大量用户，指不定就会把某个服务打趴下。
这时候，问题来了用户下单超时，或者直接500错误，如何去解决?
负载均衡集群
这种事情怎么能够在如此重要的活动中出现?其实马爸爸提早购买了多台服务器，工程师们已分别把各个业务功能模块复制部署了多份。
每一个相同功能的模块，它们构成了一个组，并以单一系统的模式加以管理。当妹子进行下单操做时，其实是跟一个集群组发生关系，但系统会确保只跟其中一个发生了关系，具体跟谁，集群组有本身的调度算法，不要担忧跟妹子发生不了关系。
高可用集群
既然是集群，就不可以出现单点故障，若是你们关注云服务，可能会接触到如下词汇，“双机热备”，“两地三中心”等等词汇。
双机热备是高可用的一种体现形式，如上图所示，生产环境中咱们存在两个负载均衡节点，主节点处于激活状态，另外一个节点处于备用状态，当主节点意外宕机，能够经过keepalived检测并迅速切换到备用服务，保障业务正常运转。
至于两地三中心，下图可能会让你们理解得更加透彻，图片源于网络。
扩展：负载均衡
负载均衡器
生产环境中咱们都用什么作负载均衡器?
财大气粗的用硬件F5
不差钱的使用DNS负载均衡
技术牛逼的用LVS
苦逼的创业型小公司只能使用Nginx
固然，负载均衡器不止以上几种，有兴趣的同窗自行谷歌了解。
七层网络模型：
TCP/IP五层模型
DNS负载均衡
DNS负载均衡的控制权在域名服务商手里，NDS存在多级解析，缓存A记录的问题，以及网站自身没法作更多的管理。这样致使了通常中小公司不多使用。
自身实力够硬，DNS负载均衡也是个不错的选择。下图是检测TT猫域名的A记录获得的部分信息，仅供参考。
弹性云
小马哥为了准备双十一，购置了大量服务器，但活动一过，平时的用户访问量并不能知足服务器的接客能力，致使大量服务器处于空窗期。
这还了得，不能闲着啊，精明的小马哥一拍脑壳，组建了TT云团队。经过多年的努力开发了按量付费云、弹性IP、共享带宽等等产品为中小企业开源节流。
ps:云计算相关概念（基础设施（infrastructure）、平台（platform）和软件（software））
故障转移
小明同窗以为这款键盘不错，美滋滋的点击购买按钮，忽然跳到了登录页面。
什么鬼，裤子我都脱了，你就给我看这个?普通用户可能不会以为有什么问题，从新登录一次就是了。但小明做为一只严谨的程序猿，他想弄明白其中到底发生了什么。
通过仔细的查阅资料分析，小明得出了如下结论：
发生以上故障，小明觉得本身下单的那台服务挂机了，请求被分发到另外一台服务上，但为何会跳到登录页面呢?做为一名程序员，小明清楚的知道服务分为有状态和无状态的，尽管咱们平时的HTTP请求是无状态的，可是通常会经过cookie或者session来肯定用户状态。
到这里，各位看官应该明白究竟是个什么鬼了吧。就拿咱们比较熟悉的Tomcat来讲，咱们的用户信息通常存储在session中，而session存储在Tomcat内存中。浏览器经过cookie中的JSESSIONID来与服务器进行认证。
然而服务器挂了，下单请求被分发到另外一台服务，天然小明再也找不到他的session了。
小明同窗把问题反馈给了TT猫，小马哥一看这还得了，集群都作了还差这点，因而赶忙叫工程师们拿出解决方案。
工程师最终提出了两种方案：
服务器用户状态复制(成本大，须要软硬件支持，有延迟，存在失败的风险)
统一存储用户状态(我不说话，我就笑笑)
最终，工程师们采用第二种方案，使用Redis存储用户状态数据。
TT猫的负载均衡实现：参考下面文章相关部分
参考文章