因为这两天在啃一些理论知识，而现在最火的微服务，分布式，集群等等概念不可避免。然而这些东西其实没有一个明确的很容易理解的定义来解释。也查阅了很多帖子，网站，甚至问了群里的人，这三者 ，经常拿来一起说的，到底分别是什么？有什么区别和联系？
首先声明文章中的观点仅代表个人理解。如果有意见或者别的看法欢迎留言或者私信，不喜勿喷。
微服务
首先从概念上讲起，微服务是现在很流行的一个词。而且其实单独讲的话是很容易理解的，微就是小的意思。也就是小服务。举个例子：微信有聊天的功能，有朋友圈的功能，还有支付的功能。这里把功能用服务来理解：微信提供聊天的服务，提供查看和发表朋友圈的服务，还提供用户绑定银行卡支付或者收钱的服务。在传统意义上，这个微信本身是一个服务，但是如果我们用微服务来拆分，可以把微信这一个拆分成成一个个独立的服务。直接的表现是如果微信支付功能出问题了，暂时不能用了。但是并不影响聊天和朋友圈。这样把一个完整的服务拆分成一个个单一的服务就算是微服务项目。因为我是java开发，所以用java来简单直观的理解：就是一个project能搞定的项目拆分成多个project。拆分的基准：单一职责、轻量级通信(HTTP)、独立性并且进程隔离。
然后个人根据实际的理解就是没有绝对正确或者错误的拆分，其实每次拆分服务对我来说都是一个很头疼的问题。大概我学到和听到的对上面基准的通俗理解：
- 服务的功能要单一。
- 服务对应的数据库的表要明确而且最好只有一个左右主表。
- 服务要独立（所谓独立是此服务down了不影响别的服务的使用）。
其实我觉得说这么多，主要还是服务的粒度问题。
拿一个实际的例子做比喻（这个是当时我们顾问给我讲解的，在此借鉴一下）：
58同城，其实他主要的就是一个信息的发布和浏览的功能，现在又加了一些类似论坛的功能。我们如果拆分类似的服务，可以选择一种是根据功能拆分，也就是房产信息的发布和浏览是一个服务。招聘信息的发布和浏览是一个服务。论坛信息的发布和浏览是一个服务。这种是现在最常用的拆分方式。如果58同城以后想增加新功能，比如说增加一个婚恋信息的发布和浏览，那么可以在不更改原代码的基础上直接添加功能。这就是微服务的方便之处和流行的原因。不过这种方式的粒度是非常小的，一个58同城拆分成十几个甚至几十个服务。
如果发布浏览各种信息只是你所做项目的功能之一，这么拆分可能没必要又麻烦，可以换一种拆分方式了。那就是按照动作拆分，用户发布修改各种消息是一个服务，用户浏览各种消息是另一个服务。这么拆分虽然很奇怪而且理解不了（其实我个人也觉得奇怪，而且没这么用过），但是好处也是可见的。这样你可能暂时无法发布各种消息，会提示你种种原因。但是浏览起来是不受影响的，而且发布对应的是读写库，而浏览是只读。这样对数据库的规划也很明确而且可以提高性能。
以上的例子只是为了说明拆分的规则不是判断题，有对错之分。而且一个辩论题，只要你觉得合理，就可以考虑。而且不同的业务场景有不同的考虑点，这个没办法一一列举或者给出正确答案，只能自己一点点推敲琢磨和辨证考虑。
总体来说，微服务是一种架构设计。
分布式
接着说分布式，其实我个人觉得也是见名知意，分布分布，分别部署。分布式是一种系统部署方式。拿java比喻：一个项目是一个jar或者war，只能部署在一个服务器上（不考虑集群部署）。所以说分布式的前提是微服务。或者说分布式属于微服务。
其实分布式是一个必然的流程,我们做成微服务一方面是便于开发，便于扩展，但是我觉得便于提供更好的服务也是其中一个原因。
我们都知道12306是并发量最大的软件（业内一直这么说，淘宝京东的双11也比不上）。我们想想一种情形。一个买票的流程：
- 搜索某两地车票
- 判断有没有车，有没有票
- 某人选择某车票（硬座，无座，卧铺，高铁等）
- 提交身份证购票（判断身份证合法性）
- 支付（支付宝，微信，银行卡等）
其实完整一套流程下来，哪怕用户比较果断干脆，也是要处理一会的。如果12306是部署在一台服务器上就出现一种情况：登录完毕的用户和正在选票的用户和提交身份信息的用户和支付的用户都在同时访问这个服务器。这其中的庞大访问量，无论能不能处理都没必要这么处理！如果采用分布式，假如说用以上步骤操作微服务拆分，那么也可以每个服务单独部署一个服务器（我这里的拆分是有问题的，只不过我是为了突出分布式的好处，不要在意拆分细节）。这样的话查询车票的用户是一个服务器，正在提交身份信息的用户是一个服务器，正在支付的用户是一个服务器。我们就把用户的访问量分散到了不同的服务器中，相对而言对单个服务器的压力都小很多了。
这个就叫做分布式，而他的用处就是分别部署，提高服务器承压能力。
分布式设计架构
分布式好处
其实我看了只想笑笑，说句mmp。如果你把分布式的优点理解成这三条，你能告诉我微服务是干嘛的么？单纯的分布式，就是分别部署！而说到分布式设计或者说到分布式系统架构，才是包含了微服务拆分和分布式部署的一种完整的项目设计架构。才有以上的优点。
我觉得不把这个概念单独拿出来是让很多人懵逼的问题。因为网上随便一搜索分布式出来的都是分布式设计架构。其实是有区别的吧？这个问题反正当时是困扰我了，因为我当时理解微服务和分布式，字面意思都理解，但是看了分布式架构的概念后却不能理解微服务包含分布式是为什么。所以我单独列出来，因为分别部署本身不会很多人讲，所以可能默认的提起分布式就是分布式系统，分布式架构啥的。但是请记住分布式这三个字本身只是分别部署的意思！
分布式系统以及分布式系统架构的优缺点
这个是我看到的讲解分布式架构优点和缺点比较完整和容易理解的文章，如果有兴趣的同学可以点进去看看。
集群
下一个概念，集群。其实这个概念百度百科上也有，说起来高大上而且多么多好。但是我觉得实际上java部署上的使用就是一个服务对应多个节点：通俗讲，A服务部署在1，2，3三个服务器上。通过一些算法，例如轮询，权重轮询，ip_hash等等方法，在访问A服务的时候随机访问1.2.3服务器。这样多人同时访问可以把压力均分（均不均分看负载均衡算法）到多个服务器，减轻单个服务器的压力。而且还有一个好处就是如果1服务器down了，可以访问2.3服务器，不会影响A服务的调用。
如果不这样部署多个节点，单个服务器压力大不说，假如停个电断个网啥的，A服务就访问不到了。所以说集群一方面也是为了高并发减压的，和分布式有相同的作用。另一方面也是上一个保险。就跟我们重要事情要早起，可能定个手机闹钟，顶个闹表的闹钟，最后还让别人几点几点叫自己一样。就是多重保险。
集群的好处：
- 提高性能
- 降低成本
- 提高可扩展性
- 增强可靠性
分类
- 科学集群
科学集群是并行计算的基础。通常，科学集群涉及为集群开发的并行应用程序，以解决复杂的科学问题。科学集群对外就好像一个超级计算机，这种超级计算机内部由十至上万个独立处理器组成，并且在公共消息传递层上进行通信以运行并行应用程序。
- 负载均衡集群
负载均衡集群为企业需求提供了更实用的系统。负载均衡集群使负载可以在计算机集群中尽可能平均地分摊处理。负载通常包括应用程序处理负载和网络流量负载。这样的系统非常适合向使用同一组应用程序的大量用户提供服务。每个节点都可以承担一定的处理负载，并且可以实现处理负载在节点之间的动态分配，以实现负载均衡。对于网络流量负载,当网络服务程序接受了高入网流量，以致无法迅速处理，这时，网络流量就会发送给在其它节点上运行的网络服务程序。同时，还可以根据每个节点上不同的可用资源或网络的特殊环境来进行优化。与科学计算集群一样，负载均衡集群也在多节点之间分发计算处理负载。它们之间的最大区别在于缺少跨节点运行的单并行程序。大多数情况下，负载均衡集群中的每个节点都是运行单独软件的独立系统。
但是，不管是在节点之间进行直接通信，还是通过中央负载均衡服务器来控制每个节点的负载,在节点之间都有一种公共关系。通常，使用特定的算法来分发该负载。
- 高可用集群
当集群中的一个系统发生故障时，集群软件迅速做出反应，将该系统的任务分配到集群中其它正在工作的系统上执行。考虑到计算机硬件和软件的易错性，高可用性集群的主要目的是为了使集群的整体服务尽可能可用。如果高可用性集群中的主节点发生了故障，那么这段时间内将由次节点代替它。次节点通常是主节点的镜像。当它代替主节点时，它可以完全接管其身份，因此使系统环境对于用户是一致的。
高可用性集群使服务器系统的运行速度和响应速度尽可能快。它们经常利用在多台机器上运行的冗余节点和服务，用来相互跟踪。如果某个节点失败，它的替补者将在几秒钟或更短时间内接管它的职责。因此，对于用户而言,集群永远不会停机。
参考集群技术—百度百科
其实我反正目前集群的使用上，几乎都是为了防止单服务down机，负载均衡只能算是添头吧。然后最后一句通俗讲解：java开发中常用的集群就是一个服务部署到多个服务器防止宕机和缓解并发压力。
SOA （面向服务的架构）
其实这个概念，我也是不久前才理解的。而且可能比较浅薄，但是真的查阅了很多资料和问了很多人，才总结出来的，如果说错了欢迎指出！
首先，这是一个架构，是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互（出自百度百科）。
然后我个人理解这句话的意思：soa是一种思想，一种方法论，也可以理解为他是一个规范。熟悉java的人应该知道规范是什么。jdbc是规范，我们通过jdbc可以用java连接各种数据库。而soa也是规范，只不过他不是java的，而是面向所有的。只要遵循它定义的标准，可以任意两个语言连接。我用java写了一个接口，然后用php调用是可以。用c++写了一个接口，用python调用也是可以的。soa主张的就是我不管你是谁，只要你接口和契约是对的，就可以调用。用一个例子比喻：我们存取东西的时候，存的时候获得一张小票。取得时候用这个小票就可以取到了。不管存的人是男是女，也不管取的人是男是女。更不管这两个人是什么关系认不认识，只要你有票就可以。soa和这个类似，不管提供接口和调用接口的是什么，只要符合条件就可以。
我感觉这个就是SOA最本质的理解。只不过因为SOA提到的多服务，提供和调用等。就意味着它不会是一个服务。所以soa要用于多服务的情境下。然后说到多服务又要不可避免的微服务分布式系统，集群之类的。这才使得这些概念混肴在一起了。
现在很多时候，我们会听到一些很可笑或者说不正规的语句和要求：比如说soa的单点登录和token认证。你能告诉我soa的单点登录和token认证和普通分布式系统的单点登录token验证有什么区别么？无论是我知识浅薄还是见识浅短。反正我是觉得没有区别！只不过是把一个理念带进去了显得这句话高大上了而已（我当时因为这个问题真的纠结了好久，自己怎么想也想不明白，然后问人，问群，贴吧也发帖子问。最后得到的回答总结起来是没区别）。
在百度百科都有明确的回答。soa只是思想，方法论。甚至是一种设计模式。你问我一个设计模式的单点登录怎么做？反正各种吐槽吧~~现在真的有的人随便知道点名词就要一直瞎用。
然后这个帖子我觉得把我自己的理解都说出来了。如果有不同的意见欢迎提出来。再最后说一遍几个名词的概念理解：
微服务：一个主项目拆分成不同的小服务。
java常用的dubbo，cloud框架就是微服务框架。核心是有一个注册中心。
好处是每个服务可独立开发测试部署。维护性和扩展性强。
分布式：分开部署，一个主项目部署到不同的服务器。基于微服务实现。
把一个完整项目部署到多台服务器上，减少服务器压力而且有一定的容错性。比如消息发布和消息浏览分开部署，这样消息发布的服务器宕机不影响消息浏览。
分布式系统/架构：使用微服务和分布式的一种架构设计。
集群：一个服务分别部署在多台服务器，通过负载均衡算法访问。
soa（Service-Oriented Architecture）：一种思想，也可以理解为规范。有点类似于设计模式的桥接。
好了，就总结到这里，然后全文手打，如果对你有帮助请点个关注和喜欢~~然后全文是我自己的观点，有不同意见欢迎留言或者私信。
网友评论