分布式概念还是简单的吧，主要是理解为什么要分布式，和分布式主要做什么。
首先分布式的主要作用有以下几点：
1、提高应用的可用性：服务器要保持长时间能够有效的使用，但是现实情况又是很不稳定的，例如电脑会死机，会断电，硬件设备会损坏，使用分布式可以一定程度的解决这些问题。
2、分散服务器运行压力，这本身也是提高应用可用性的一个方面，例如你的应用功能很多，逻辑很复杂，或者操作的数据量较大，单个应用或者机器难以甚至无法处理你的业务，那么就需要使用分布式。
分布式的概念其实也很简单，就是一个应用做不了或者难以做的事情，让多个应用去做，这就好比让一个人去完成的事情让多个人去完成，举个现实中很简单的例子，例如造车，造车这个工作本身一个造车厂可以完成这个任务，只是一个工厂造车，成本、技术、人员等等都会提高制作成本，而且因为技术过于驳杂，一个厂能造，但是成本和难度都会增加，但是拆分给多个厂来造车，例如一个厂造发动机，一个厂造底盘，一个厂造外壳，一个厂做电子仪表盘等等，把各个配件分散给不同的厂制作，这样每个厂专心做自己更专业的事情，这样既降低了成本，有提高了工作效率。
回到我们的web应用，一般来说，一个系统就是一个应用，系统里面有各种功能，例如学生信息管理系统，系统里面包含各种功能，例如用户登录和认证、权限配置和授权、学生信息的管理、学生的入学管理、学生的毕业管理、校友信息管理等等各种功能，但是当学生的数量特别多，内部业务逻辑特别复杂的时候，一个应用可能不能够承担起这个系统的正常运转，那么就可以考虑分布式，来使用多个应用完成这个系统的功能，例如做一个应用负责登录认证模块，一个应用处理授权的功能，另外一个应用处理学生信息的内容等等。
总结分布式，其实就是一个应用的事情让多个应用来解决，分布式是应用级别的分工，在一台机器的多个应用，我们叫垂直分布式，在多台机器上的分布式叫水平分布式，在一台机器的分布式实现起来比较简单，只需要实现应用之间的内存数据共享即可，内存数据共享方式很多，可以使用共享文件等等方式，多台机器的分布式就需要借助网络通信来共享数据，如果是通语言同技术的应用，可以直接共享内存数据，如果是不同语言的分布式应用，就需要参照一些通用传输协议的数据，例如xml json。
2020年火的
分布式和集群的概念和区别：分布式系统是当前比较热门的话题，说到分布式就不得不提集群和单机，如果要学习分布式就要先对他的概念和功能有所了解一、单机：单机就是把做的系统部署到一台服务器上，，所有的请求业务都由这台服务器处理。显然，当业务增长到一定程度的时候，服务器的硬件会无法满足业务需求。很多人就会想到多部署几台服务器，这就是集群。
二、集群：集群就是单机的多实例，在多个服务器上部署多个服务，每个服务就是一个节点，部署N个节点，处理业务的能力就提升_倍（大约），这些节点的集合就叫做集群。优点：操作简单，容易部署；缺点：每个节点负载相同（耦合度高），每个具体业务的访问量可能差异很大，比如美团外卖美食外卖的访问量一定大于鲜花外卖的访问量，这就造成了资源浪费
三、分布式（微服务）分布式结构就是将一个完整的系统，按照业务功能，拆分成一个个独立的子系统，在分布式结构中，每个子系统就被称为“服务”。这些子系统能够独立运行在web容器中，它们之间通过RPC方式通信。优点：资源利用率高，缺点：安全性低，如果一台服务器出现问题整个系统就会崩塌
四、总结：所以好的设计应该是分布式和集群的结合，先分布式再集群，具体实现就是业务拆分成很多子业务，然后针对每个子业务进行集群部署，这样每个子业务如果出了问题，整个系统完全不会受影响。微服务的设计是为了不因为某个模块的升级和BUG影响现有的系统业务。微服务与分布式的细微差别是，微服务的应用不一定是分散在多个服务器上，他也可以是同一个服务器。
微服务架构是一种软件设计方法，它将应用程序分解为通过定义明确的 API 进行通信的小型独立服务。由于每个服务都可以由自治团队开发和维护，因此它是最具可扩展性的软件开发方法。
微服务设计与单体开发截然相反。单体是一个实现所有功能的大型代码库（“厨房水槽”）。一切都在一个地方，没有一个组件可以孤立地工作。这意味着应用程序必须作为一个整体进行测试。
从好的方面来说，单体应用很容易启动和运行。由于单体架构不同部分之间的关系是透明的，因此进行广泛的更改很容易。
然而，随着公司的发展和团队规模的扩大，单体开发变得更加困难。很快，系统就不能再装在一个头上了——移动部件太多了，所以事情变慢了。
微服务使公司能够保持团队规模小而敏捷。这个想法是将应用程序分解为可以由紧密结合的团队自主开发和部署的小型服务。
公司采用微服务的主要原因是 可扩展性 。服务可以独立开发和发布，无需在组织内安排大规模的协调工作。
拥有分布式系统的一个好处是能够避免单个故障点。您可以使用支持云的技术在不同的可用区部署微服务，确保您的用户永远不会遇到中断。
使用微服务，开发团队可以保持小而有凝聚力。小组越小，沟通开销越少，协作越好。
亚马逊通过他们的两个披萨团队将团队规模发挥到了极致。这意味着一个团队应该足够小，可以吃两个比萨饼。
对于单体应用，语言和技术堆栈选项几乎从一开始就设置好了。新开发人员必须适应过去做出的任何选择。
相比之下，每个微服务都可以使用最适合解决手头任务的技术堆栈。因此，团队可以为工作和他们的技能选择最佳工具。例如，您可以使用 Go 或 C 实现高性能服务，并使用 Erlang 或 Elixir 实现高容错微服务。
随着小团队迭代速度更快，开发和测试周期更短。而且，由于他们还可以随时部署更新，微服务的部署频率比单体应用要高得多。
有这么多好处，似乎为新项目选择微服务是一件轻而易举的事。但是微服务设计也带来了一些严峻的挑战：
你怎么知道你是否在做正确的微服务设计？如果您的团队可以在不与其他团队协调的情况下随时部署更新，并且如果其他团队可以类似地部署他们的更改而不影响您，那么恭喜您，您掌握了微服务的诀窍。
失去微服务提供的好处的最可靠方法是不遵守解耦规则。如果我们仔细观察，我们会发现微服务都是关于自治的。当这种自主权丧失时，团队必须在开发和部署期间进行协调。需要完美的集成测试来确保所有微服务协同工作。
即便如此，详尽的测试也无法捕捉到所有问题。当出现问题时，耦合服务是很难调试的。当问题被发现时，修复它并不总是像回滚更新那么容易。
紧密的服务依赖关系创建团队依赖关系。
这些都是分布式计算带来的问题。如果您曾经使用过云服务，您就会知道将服务或机器分布在多个地理位置与在同一站点上运行所有内容不同。分布式系统具有更高的延迟，可能存在同步问题，并且更难管理和调试。这种高度耦合的服务架构实际上是一个 分布式单体 架构，具有两全其美的优点，也没有微服务应该带来的任何好处。
如果您在不与其他团队协调或依赖其他微服务的特定版本来部署您的微服务的情况下无法进行部署，那么您只是在分发您的单体应用。
微服务并没有 取代 单体。两者都是有效的方法。事实上，当团队仍在 探索 他们正在构建的东西时，单体应用可能是最佳选择。
单体应用就像是项目的自然起点，因为它易于开发、快速迭代、快速部署、易于调试，并且更能容忍设计错误。在可扩展性成为问题之前，单体应用可以让您走得更远。
微服务是我们开发软件的最具可扩展性的方式。但它们不是免费的午餐。如果您不小心，它们会带来一些很容易发生冲突的风险。当团队正在成长并且您需要保持快速和敏捷时，它们非常有用。但是你需要对要解决的问题有一个很好的理解，否则你最终会得到一个分布式的单体。
什么是微服务
微服务架构的系统是一个分布式的系统，按业务进行划分为独立的服务单元，解决单体系统的不足，同时也满足越来越复杂的业务需求。
一.单体架构
1.1什么是单体架构
在软件设计的时候经常提到和使用经典的3层模型，即表现层，业务逻辑层，数据访问层。虽然在软件设计中划分了3层模型，但是对业务场景没有划分，一个典型的单体架构就是将所有的业务场景的表现层，业务逻辑层，数据访问层放在一个工程中最终经过编译，打包，部署在一台服务器上。此时服务架构如图：
1.2单体架构存在的不足
在小型应用的初期，访问量小的时候这种架构的性价比还是比较高的，开发速度快，成本低，但是随着业务的发展，逻辑越来越复杂，代码量越来越大，代码得可读性和可维护性越来越低。用户的增加，访问量越来越多单体架构的应用并发能力十分有限。可能会有人想到将单体应用进行集群部署，并增加负载均衡服务器，再来个缓存服务器和文件服务器，数据库再搞个读写分离。这种架构如图：
这种架构虽然有一定的并发能力，及应对一定复杂业务，但是依然没有改变系统为单体架构的事实。大量的业务必然会有大量的代码，代码得可读性和可维护性依然很差。如果面对海量的用户，它的并发能力依然不够。基于以上单体架构系统的不足，提出了微服务架构。
二.微服务
2.1什么是微服务
说了这么多现在来看看到底什么是微服务。微服务最初是由Martin Fowler提出来的他的理解如下：
微服务架构就是将单一程序开发成一个微服务，每个微服务运行在自己的进程中，并使用轻量级的机制通信，通常是HTTP RESTFUL API。这些服务围绕业务能力来划分，并通过自动化部署机制来独立部署。这些服务可以使用不同的编程语言，不同数据库，以保证最低限度的集中式管理。
1
总结起来微服务就是将一个单体架构的应用按业务划分为一个个的独立运行的程序即服务，它们之间通过HTTP协议进行通信（也可以采用消息队列来通信，如RoocketMQ，Kafaka等），可以采用不同的编程语言，使用不同的存储技术，自动化部署（如Jenkins）减少人为控制，降低出错概率。服务数量越多，管理起来越复杂，因此采用集中化管理。例如Eureka，Zookeeper等都是比较常见的服务集中化管理框架。
2.2微服务的优势
1）将复杂的业务拆分成多个小的业务，每个业务拆分成一个服务，将复杂的问题简单化。利于分工，降低新人的学习成本。
2）微服务系统是分布式系统，业务与业务之间完全解耦，随着业务的增加可以根据业务再拆分，具有极强的横向扩展能力。面对搞并发的场景可以将服务集群化部署，加强系统负载能力。
3）服务间采用HTTP协议通信，服务与服务之间完全独立。每个服务可以根据业务场景选取合适的编程语言和数据库。
4）微服务每个服务都是独立部署的，每个服务的修改和部署对其他服务没有影响。
2.3微服务和SOA的关系
SOA即面向服务的架构，SOA是根据企业服务总线（ESB）模式来整合集成大量单一庞大的系统，微服务可以说是SOA的一种实现，将复杂的业务组件化。但它比ESB实现的SOA更加的轻便敏捷和简单。
随着互联网的不断发展，我们在进行服务器开发组织架构上通常会采用分布式架构方法来进行设计。今天，我们就一起来了解一下，微服务架构都有哪些特点。
InfoQ:你近的QConSanFrancisco提出的一个关键前提是，组织如果要从单体大型应用转变为基于微服务的体系结构就得要打破它们的庞大的整体流程。你能再进一步解释一下吗
RafaelSchloming:对于转变为微服务本身，人们实际上并不怎么关心，他们真正关心的是提升特性的完成速度。为了提升特征的完成速度就必需做出改变，而微服务只是这种改变所产生的一个附属物罢了。
对于组织来说非常常见的一种情况是，当他们发展到一个临界点，增加再多的人也不会提升特性的完成速度。当这种情况发生时，通常是因为组织用于产出特性的结构和/或过程成为了瓶颈，而不是人员的数量。
当一个组织遇到这种障碍，开始调查为什么这些特性似乎花费的时间远远超出了合理的资源，答案往往是，每个特性都需要太多不同团队的协调。
这会发生在两个不同的维度上。你的人员可以按职能划分为团队：产品与开发、质保与运维。你的人员也可以按组件划分:例如，前端与领域模型、搜索索引和消息通知。当单个特性需要跨多个不同的团队进行协调时，交付特性的控制因素是不同团队之间的沟通速度和效率。像这样组织结构的组织实际上是被一个庞大的整体过程所阻碍的，这个过程要求每个特性(在某种程度上)要有许多许多的组织来理解它。
InfoQ:那么如何解决这个问题呢
Schloming:为了把很多人用在一个问题上，你需要把他们分成团队，因为人们不能在非常大的群体中有效地沟通。你这么做的时候，其实就是在做出一系列的权衡。你所营造的是每支团队内部具有高保真的沟通和协调，而团队之间是低保真和相对较差的协调。
为改进一个组织内的特性完成速度，您可以将你的人组织成独立的、跨职能的、自给自足的特性团队，可以从头到尾自主掌控一个完整的特性。这将以两种方式提高特性的完成速度。先，由于不同的职能(产品、开发、质保和运维)都圈定于一个特性内，你就可以自定义该特性区域的流程了，例如，IT培训分享对于一个没有人正在使用的新特性，你的流程就不需要优先考虑其稳定性了。其次，由于该特性所需的所有组件都由同一个团队拥有，因此，要想赶紧推出一个特性，就可以进行更快速有效的沟通和协调。
服务器集群：
服务器集群就是指将很多服务器集中起来一起进行同一种服务，在客户端看来就像是只有一个服务器。集群可以利用多个计算机进行并行计算从而获得很高的计算速度，也可以用多个计算机做备份，从而使得任何一个机器坏了整个系统还是能正常运行。
服务器负载均衡：
负载均衡
（Load
Balancing）
建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。
分布式服务器：
所谓分布式资源共享服务器就是指数据和程序可以不位于一个服务器上，而是分散到多个服务器，以网络上分散分布的地理信息数据及受其影响的数据库操作为研究对象的一种理论计算模型服务器形式。分布式有利于任务在整个计算机系统上进行分配与优化，克服了传统集中式系统会导致中心主机资源紧张与响应瓶颈的缺陷，解决了网络GIS
中存在的数据异构、数据共享、运算复杂等问题，是地理信息系统技术的一大进步。
这个三种架构都是常见的服务器架构，集群的主要是IT公司在做，可以保障重要数据安全；负载均衡主要是为了分担访问量，避免临时的网络堵塞，主要用于电子商务类型的网站；分布式服务器主要是解决跨区域，多个单个节点达到高速访问的目前，一般是类似CDN的用途的话，会采用分布式服务器。
纯手工打字，希望可以帮的到你！
前言
我们已经 设计和构建 了十多年的软件，大部分时间我们一直在使用优秀的 Symfony 框架来实现这一目标。 Symfony 是一个传统的单体 PHP 构件集，受 Java Spring 的启发，我们发现它非常适合 企业 Web 应用程序 和 数字产品 的快速开发，而这些正是我们主要经济来源。
然而，去年发布的 Symfony 4 代表了该框架的重点逐渐变化 ; 这变化体现在其远离单体架构和向 微服务 靠拢，这种变化背后的方法论在过去几年中越来越受欢迎。
为了说明这一转变，新版本在默认情况下使用了微内核（micro by default), Symfony 组织大力宣传其新的微内核设计，声称与 Symfony 3 相比，编写应用程序所需的代码减少了 70%。
除了这些优点外，这一变化意味着运行单个应用程序的开销要小得多，这使得 Symfony 对于微服务体系结构的使用更具吸引力。
什么是单体应用和微服务
微服务设计基于将大型传统（单体）应用程序拆分为几个小型、不同的应用程序的概念。这些应用程序将处理单个业务功能领域，并与其他组件协作，就像它们是第三方应用程序一样
这真的是一个新事物吗，或者这只是一个具有时髦名字的面向服务体架构（SOA)我们不会在这里进行辩论，毕竟你可以到 Slashdot 和 Hacker News 上讨论这个问题。不过，我们要说的是，微服务方法 ( 或者随便你怎么称呼它 ) 主要对大型组织有益。这是因为非常大的应用程序可以被分割成几个不同的服务，每个服务由各自独立的开发团队管理。
微服务体系结构的另一个好处是允许灵活地扩展一个特定组件的数量，而不是整个应用程序。这特性非常适合应用在 弹性云计算 ，但在大多数情况下，我认为这种效率提高会被一个大而突出的问题所淹没。
你真的需要微服务
我的观点是，除非你在 Google 或 Netflix 等拥有数百名软件开发人员的公司工作，否则你可能不需要微服务。事实上，对于大多数中小型企业来说，采用这种设计可能非常不合适。
我将会讲到一些例外，但是微服务的开发和维护成本是很多人都注意到的却又很少谈及的问题。我们可以用一个简单的问题来决定是否适合把微服务作为你的起点 : （译者注：这句子的原文中有个词语叫 房间里的大象 ，是指所有人都注意到却又不被提及的问题）
你系统中的某个组件（例如用户管理）是否足够复杂，以致于需要多个开发人员全职进行持续开发？
如果答案是否定的，那么微服务方法可能会浪费您的时间和金钱。相反，如果你足够幸运，能够在以后达到这个规模，你可能就可以慢慢地把那些需要多人开发的部分分离出来。
为什么微服务在开发和运维上开销更大
由于您不需要处理大量的分布式系统问题，因此单体应用程序通常是一个开销更少的方案。使用像 Symfony 这样的单体框架所通过提供开箱即用的集成特性提供了许多好处，这些特性可以方便地从应用程序的所有区域访问。你基本上可以避免处理以下的这些问题 :
例外情况（混合的方式）
有时候微服务是合适的，但是根据我的经验，在这些情况下，可伸缩性需求或容错需求超过了必须设计和管理分布式系统的缺点。这里的一个很好的例子是像 Monzo Bank 这样的企业应用，它既需要能够立即按需求进行伸缩，又需要能够确保系统某个区域的故障不会影响到另一个区域 .
我们在 Browser 中多次重复的一个好方法是采用混合方法进行系统设计。这涉及到一个由支持微服务包围的中心整体，但只有在有充分理由的情况下才会如此。例如，我们最近在将 NLP 处理集成 到应用程序中时使用了这种方法。
我们已经构建了几个系统，其中核心业务应用程序作为一个整体构建 ( 通常在 Symfony 中 )，由独立的微服务管道处理繁重的数据处理。这不仅允许我们在不影响核心应用程序性能的情况下处理大量数据量，而且如果需要，我们可以在不影响平台的日常操作前提下，将这些组件下线。
理想情况下，你能够清楚地理解规模和未来的开发需求，这对于决定体系结构非常重要。你想快速进入市场吗？您想要支持数百万用户吗？您是否需要处理 大量的数据流 。
尽早做出正确的决定可以增加产品在最短的时间内获得投资回报的机会，而不会妨碍您将来的 探索 。 在后续计划中将组件微服务化通常比最初的 MVP 开发中微服务化更具成本效益。
微服务的系统架构开发方式相信大家应该不陌生了吧，在前几期的文章中我们也对微服务的架构方式做了一个简单的介绍。今天，天通苑北大青鸟就来对比一下，微服务与传统单一服务架构的区别。
1.如何理解微服务，简要说明您所理解的微服务是什么
微服务，这个词语其实是一次听说，我search了下定义，然后恍然明白，其实所谓的微服务，用更通俗接地气的词语来定义和描述的话，就是敏捷+模块的服务架构体系，如何解释敏捷，原来的亚马逊CEOBezos提出来的2pizza就是微服务系统架构的鼻祖，2pizza意思就是所有参与人从设计、开发、测试、运维所有人加起来只需要2个披萨就够了(应用自网上资料)，所以你能知道，既然要求敏捷，那要快并且高效，就要有模块化的思维方式，在汽车行业，如今大众，丰田都提倡模块化造成体系，不仅高效，而且很多可移植，在IT行业，这种模块化的思路也是，不仅代码可移植，如同乐高积木进行横向功能叠加，而且基于模块化的微服务，在运维方面，也是自成体系，不仅能减少模块的测试压力和成本，后我认为这个微服务还是符合当下资源高效利用的政策的，很多系统逐渐从大而全变成小而精，对于开发，运维等等也是如此，微服务就非常符合这个命题。
2.与传统单一服务架构相比，在实战环境下，各自的优劣都有哪些
我认为存在即合理，没有所谓哪个好，只有哪个更合适，或者在当下需求和长期规划下，在不同阶段，何种架构更性价比高，对于单一架构体系，我认为复杂性高，接口冗余，稳定性中等是其特征，你可以说这是缺点，但是我认为对于比如大型金融架构，比如我所在的行业，这种soa的架构体系是主流，单一服务架构优势在于下属模块的差异度比较少，品类单一，规划比较完整，属于有了宏观架构和愿景进行搭建的方式，而微服务更适合互联网行业，快速部署，已经对于新技术的欢迎和迭代，是微服务的佳实践场所
3.如果您考虑部署微服务，在业务部署过程中会遇到哪些关键挑战
主要是在金融行业，如果在已有的单一架构系统体系中，采用微服务的部署方式，与原来系统的耦合以及接口是要好好考虑的，要不然会出现四不像，既没有了原来大型单一系统架构的优势，微服务的快速，高效和低成本也会体现不出其好的效果，还有就是我认为即使是模块化的微服务部署，在能力范围之内要选择好不同模块的耦合和类型选择，否则百花齐开虽然漂亮，但是纵向升级以及进行整合还是非常让开发和运维的人绞尽脑汁的。
大家在关注
