java微服务和分布式的区别有哪些

这个问题已经收藏了一个多月了，一直在考虑如何回答这个问题，总结了很长时间终于有了一些感悟（之前一直都是只可意会不可言传的感觉），和大家分享一下，如果有不同的建议，欢迎大家留言指正。

分布式和微服务

首先，我认为微服务就是分布式框架的一种。

分布式的思想就是把一个系统的不同模块，部署在不同的服务器上，以应对高并发的问题。

SOA是一种分布式架构，把业务系统分成多个子系统，提供不同的服务，再通过服务组合、编排实现业务流程；通常在SOA架构中，ESB企业服务总线扮演了重要的角色。

微服务是SOA的升华，如果非要说点儿不同的，那么微服务更加强调服务的细分和专业，去ESB总线、去中心化，部署粒度更细，服务扩展更灵活。

微服务不只是技术架构

很多同学一说微服务，就说这是一种技术架构，有的推荐使用Dubbo，有的推荐使用SpringCloud。

我认为，微服务不单单是一种技术架构，也涉及到了管理、组织架构。

大多数的公司，需求、开发、测试、运维都是独立的团队，这实际上是有悖于微服务快速迭代的思想；在微服务的架构下，一个服务应该是由一个团队全权负责的。

不过组织架构方面的事情，真的不是我们能说了算的。

必须要用微服务？

我觉得没有必要为了微服务，而微服务；有的公司把服务拆分，但是数据库依然是同一个库，依然是一个项目直接掉另外一个项目的接口，然后对外就宣称完成了微服务的改造

架构设计还是要根据需求背景、团队开发能力、软硬件实力综合来考虑。

好的架构是可以进化的，而不是一步到位建成的。

我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。

背景

随着公司一年多的成长，我们已经开发了数十个项目了，后台有JAVA的有PHP的，为了更好地提升开发与管理效率，各技术大牛小牛们时常进行激烈的PK，碰撞出了许许多多爱的火花，比如其中之一：微服务实践

设计

只需要有一套BASE微服务，BASE微服务生成业务系统微服务实例，供各个业务系统调用；业务系统不直接调用BASE，只能调用微服务INSTANCE。

这是运维的问题，让运维去解决，运维使用工具，实际也不算困难，反正执行的都是脚本，不需要手工 *** 作。

单点故障影响全局，我们选择了稳定更重要；另外saas的话，为了应对不同行业，会存在过度设计的嫌疑；私有化更容易。

调用逻辑

设计理念

非模块化，谈不上微服务，比如我们上面的用户微服务、产品微服务、地址微服务等，都需要先模块化，为了更好地落实开发，你可能不得不，边模块化边微服务，模块化的时候要注意，不能有关联查询，包要完全独立，到时候微服务才能拆开。

松耦合表示我们模块之间不直接依赖，无状态，可以单独地为外界提供服务；

强内聚是指，我们虽然要拆分成一个个小的微服务，但是也要考虑某些功能的强关联性，比如一个凳子是由四个脚与一个板组成，我们不能把四个脚与板分开售卖，就没有意义了。

开发

spring-boot :较springmvc更加简约了，springmvc有一大零的配置文件，比如spring-servlet、spring-mybatis、springxml与webxml，这些在spring-boot都不需要了，只需要强大的注解功能即可，boot更合适微服务。

spring-cloud :里面有比较多组件，用于支持微服务，比如spring cloud config统一配置中心，用于多环境的配置文件配置，大家再也不用为多个微服务的开发、测试与生产环境的配置文件管理而发愁了；spring cloud eureka用于服务注册与发现，下面有单独介绍；其它的组件大家可以去官网看看，这里不一一介绍，总之如果JAVA平台，尽量使用spring体系的内容。

我们采用mysql，因为我们是应用多，但数据量单表并不算大，多则不超过百万，mongodb也实验过，开发非常快，也非常灵活，但因为不是关系型数据库，维护成本较高。

RESTFUL ：URL的资源与 *** 作解耦，让URL更加符合语义，上百个接口也非常好管理，网上有很多文章讲得非常透彻，这玩意不是特别好理解，要多领悟，在项目中实践，就有矛塞盾开的感觉，这里不做详细介绍。

接口文档swagger ：比起传统全手工写接口文档，swagger有统一的输出格式，不管是几个人写的；swagger采用写代码的方式来写接口文档，以前修改了代码，还必须打开wiki手工修改接口文档，现在只需要修改一下代码即可，程序员更愿意修改了，成本更低了，前端与其它调用者不会天天吼着，你这接口咋又变了，新加的字段是啥意思呀。

RocketMQ：一直纠结kafka与rocketMQ，最终选择了RocketMQ

为了性能上面的考虑，尽量使用异步编程，比如注册送优惠券，那么注册成功就可以给用户返回注册成功了，但是送优惠券可以是异步调用的，不阻塞注册的线程。

微服务框架下，日志不可能还分散在各个服务节点上，必须有统一的日志中心。ELK是一个实时日志分析平台，就是将各个服务的日志汇总于日志中心，然后可以按照系统、节点等进行搜索，除上述搜索条件外，我们还在各个微服务实现了按照业务id（一次请求生成一个业务id）与用户id搜索日志，方便跟踪与定位问题。

当然可能有更加轻量级与好用的disconf或spring cloud config，但是我们有php开发的应用，以上二者都不支持。如果全是JAVA应用，采用disconf还是非常不错的。

测试

每个程序员都有这样的经历，刚上线，客户又反馈了bug，原来是我们修改某个功能代码的时候，导致了其它功能的bug，每次上线心里都没底；这就体现了接口测试的必须性，尤其是每次版本升级的时候，都需要执行一遍，以防修改某个接口导致其它接口报错，比手动测试靠谱许多。

部署

docker已经家喻户晓了，这是继虚拟机以后，又一重大变革，将所有的单个微服务都放在docker中，这样你何时何地想部署，直接丢过去就OK了，快到爆。

用几句简单的命令就搞定了负载均衡，而且还可以平滑升级，版本升级的时候，大家就不用告诉客户：系统通知，某日某晚00:00-08:00我行处于系统升级维护中，大家不要去取钱哦，因为你可能取不出来，呵呵。

升级

我们采用工具flyway，可以对数据库脚本进行版本控制。

传统的版本升级，

1开发推代码并同时记录自己提交了哪些文件；

2项目经理根据svn审核文件，并打包成war包；

3投到测试环境让测试公司测试；

4中途修改了文件，可能需要重新打包；

…

我都写不下去了，项目经理像个超人似的。

现在用持续集成（CI）非常简单，我们用的工具是Jenkins，推完代码，点几下按钮就完成了上线，不管是测试环境，还是生产环境都非常简单，不然项目经理核对文件眼睛都绿了。

结尾

本文主要是介绍微服务开发上的选型，对于细则不做深究，大家感兴趣可以了解下各个组件。当然，我们的选型未免正确，不同场景应用可能完全不同，本文仅供参考。

不会，一般情况下，微服务在连接不上redis时，不会直接访问数据库。微服务通常是支持缓存技术，在连接不上redis时，会使用本地缓存，或者使用其他缓存技术，比如memcached等，从而提高访问速度，减轻数据库的压力。

简单地说，微服务架构就是以业务域或业务功能为边界，将一个大而全的应用拆分为可以独立开发，独立部署，独立测试，独立运行的一组小的应用，并且使用轻量级，通用的机制在这组应用间进行通信。

主流的微服务包括：

1、SpringCloud

Spring Cloud , 来自Spring，具有Spring 社区的强大支撑，还有Netflix强大的后盾与技术输出。Netflix作为一家成功实践微服务架构的互联网公司在几年前就把几乎整个微服务框架栈开源贡献给了社区，这些框架开源的整套服务架构套件是Spring Cloud的核心。

- Eureka:服务注册发现框架；

- Zuul:服务网关；

- Karyon：服务端框架；

- Ribbon：客户端框架；

- Hystrix：服务容错组件；

- Archaius：服务配置组件；

- Servo：Metrics组件；

- Blitz4j：日志组件；

2、Dubbo

Dobbo是一个分布式服务框架，是阿里开放的微服务化治理框架，致力于提高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。其核心部分(官网)

- 远程通讯: 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式；

- 集群容错: 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持；

- 自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。

Dubbo 也是采用全 Spring 配置方式，透明化接入应用，对应用没有任何 API 侵入，只需用 Spring 加载 Dubbo的配置即可，Dubbo 基于 Spring 的 Schema 扩展进行加载。当然也支持官方不推荐的 API 调用方式。

3、lstio

lstio 作为用于微服务聚合层管理的新锐项目，是Google、IBM、Lyft（海外共享出行公司、Uber劲敌），首个共同联合开源的项目，提供了统一的连接，安全，管理和监控微服务的方案。

目前首个测试版是针对Kubernetes环境的，社区宣称在未来几个月内会为虚拟机和Cloud Foundry 等其他环境增加支持。lstio将 流量管理添加到微服务中，并为增值功能（如安全性、监控、路由、连接管理和策略）创造了基础。

- >

微服务¹架构的目标是帮助工程团队更快，更安全，更高质量地交付产品。解耦服务允许团队快速迭代，对系统的其余部分影响最小。

在Medium，我们的技术堆栈始于2012年的单片Nodejs应用程序。我们已经构建了几个卫星服务，但我们还没有制定一个系统地采用微服务架构的策略。随着系统变得越来越复杂并且团队不断发展，我们在2018年初转向了微服务架构。在这篇文章中，我们希望分享我们有效地做到这一点并避免微服务综合症的经验。

首先，让我们花一点时间来思考微服务架构是什么，不是什么。 “微服务”是那些过载和混乱的软件工程趋势之一。这就是我们在Medium认为它是什么：

该定义包括三个微服务设计原则：

Three Principles of Modeling Microservices

当我们对微服务进行建模时，我们应该遵守所有三个设计原则。这是实现微服务架构全部潜力的唯一途径。错过任何一个都会成为反模式。

没有一个目的，每个微服务最终会做太多事情，成长为多个“单片”服务。我们不会从微服务架构中获得全部好处，我们也会支付运营成本。

如果没有松散耦合，对一个服务的更改会影响其他服务，因此我们无法快速安全地发布更改，这是微服务架构的核心优势。更重要的是，紧密耦合引起的问题可能是灾难性的，例如数据不一致甚至数据丢失。

如果没有高凝聚力，我们将最终得到一个分布式单片系统 - 一组混乱的服务，必须同时进行更改和部署才能构建单一功能。由于多个服务协调的复杂性和成本（有时跨多个团队），分布式单片系统通常比集中式单片系统差得多。

与此同时，了解 微服务不是什么 很重要：

在Medium，我们总是在做出重大产品或工程决策时会问“为什么现在？”这个问题。 “为什么？”是一个显而易见的问题，但它假设我们拥有无限的人，时间和资源，这是一个危险的假设。当你想到“为什么现在？”时，你突然有了更多的限制 - 对当前工作的影响，机会成本，分心的开销等等。这个问题有助于我们更好地优先考虑。

我们现在需要采用微服务的原因是我们的Nodejs单片应用程序已经成为多个方面的瓶颈。

首先，最紧迫和最重要的瓶颈是其性能。

某些计算量很大且I / O很重的任务不适合Nodejs我们一直在逐步改进整体应用程序，但事实证明它是无效的。它的低劣性能使我们无法提供更好的产品而不会使已经非常慢的应用程序变慢。

其次，整体应用程序的一个重要且有点紧迫的瓶颈是它会减慢产品开发速度。

由于所有工程师都在单个应用程序中构建功能，因此它们通常紧密耦合。我们无法灵活地改变系统的一部分，因为它也可能影响其他部分。我们也害怕做出重大改变，因为影响太大，有时难以预测。整个应用程序作为一个整体进行部署，因此如果由于一次错误提交导致部署停滞，那么所有其他更改（即使它们完全正常工作）也无法完成。相比之下，微服务架构允许团队更快地发货，学习和迭代。他们可以专注于他们正在构建的功能，这些功能与复杂系统的其余部分分离。更改可以更快地进入生产。他们可以灵活地安全地尝试重大变革。

在我们新的微服务架构中，更改会在一小时内完成生产，工程师不必担心它会如何影响系统的其他部分。该团队还 探索 了在开发中安全使用生产数据的方法²多年来一直是白日梦。随着我们的工程团队的发展，所有这些都非常重要。

第三，单一应用程序使得难以为特定任务扩展系统或隔离不同类型任务的资源问题。

使用单一的单一应用程序，我们必须扩展和缩小整个系统，以满足更多资源需求的任务，即使这意味着系统过度配置用于其他更简单的任务。为了缓解这些问题，我们对不同类型的请求进行分片，以分离Nodejs进程。它们在一定程度上起作用，但不会扩展，因为这些微单一版本的单片服务是紧密耦合的。

最后但同样重要的是，一个重要且即将成为紧迫的瓶颈是它阻止我们尝试新技术。微服务架构的一个主要优点是每个服务都可以使用不同的技术堆栈构建，并与不同的技术集成。这使我们能够选择最适合工作的工具，更重要的是，我们可以快速安全地完成工作。

采用微服务架构并非易事。它可能会出错，实际上会损害工程生产力。在本节中，我们将分享七个在采用早期阶段帮助我们的策略：

有人可能会认为采用新的服务器架构意味着产品开发的长时间停顿以及对所有内容的大量重写。这是错误的做法。我们永远不应该为了建立新的服务而建立新的服务。每次我们建立新服务或采用新技术时，都必须具有明确的产品价值和/或工程价值。

产品价值应以我们可以为用户提供的利益为代表。与在单片Nodejs应用程序中构建值相比，需要一项新服务来提供值或使其更快地交付值。工程价值应该使工程团队更好，更快。

如果构建新服务没有产品价值或工程价值，我们将其留在单一的应用程序中。如果十年内Medium仍然有一个支持某些表面的单片Nodejs应用程序，那就完全没了问题。从单一应用程序开始实际上有助于我们战略性地对微服务进行建模。

建立具有明确价值的新服务

有人可能会认为采用新的服务器架构意味着产品开发的长时间停顿以及对所有内容的大量重写。这是错误的做法。我们永远不应该为了建立新的服务而建立新的服务。每次我们建立新服务或采用新技术时，都必须具有明确的产品价值和/或工程价值。

产品价值应以我们可以为用户提供的利益为代表。与在单片Nodejs应用程序中构建值相比，需要一项新服务来提供值或使其更快地交付值。工程价值应该使工程团队更好，更快。

如果构建新服务没有产品价值或工程价值，我们将其留在单一的应用程序中。如果十年内Medium仍然有一个支持某些表面的单片Nodejs应用程序，那就完全没了问题。从单一应用程序开始实际上有助于我们战略性地对微服务进行建模。

单片持久存储被认为是有害的

建模微服务的很大一部分是对其持久数据存储（例如，数据库）进行建模。跨服务共享持久数据存储通常似乎是将微服务集成在一起的最简单方法，然而，它实际上是有害的，我们应该不惜一切代价避免它。这就是原因。

首先，持久数据存储是关于实现细节的。 跨服务共享数据存储会将一个服务的实现细节暴露给整个系统。如果该服务更改了数据的格式，或者添加了缓存层，或者切换到不同类型的数据库，则还必须相应地更改许多其他服务。 这违反了松散耦合的原则。

其次，持久数据存储不是服务行为，即如何修改，解释和使用数据 。如果我们跨服务共享数据存储，则意味着其他服务也必须复制服务行为。 这违反了高内聚的原则 - 给定域中的行为泄露给多个服务。如果我们修改一个行为，我们将不得不一起修改所有这些服务。

在微服务架构中，只有一个服务应该负责特定类型的数据。所有其他服务应该通过负责服务的API请求数据，或者保留数据的 只读非规范（可能具体化）副本 。

这可能听起来很抽象，所以这是一个具体的例子。假设我们正在构建一个新的推荐服务，它需要来自规范帖子表的一些数据，目前在AWS DynamoDB中。我们可以通过两种方式之一为新推荐服务提供发布数据。

在单片存储模型中，推荐服务可以直接访问单片应用程序所执行的相同持久存储。这是一个坏主意，因为：

缓存可能很棘手。 如果推荐服务与单一应用程序共享相同的缓存，我们也必须在推荐服务中复制缓存实现细节;如果推荐服务使用自己的缓存，当单片应用更新帖子数据时，我们将不知道何时使其缓存无效。

如果单片应用程序决定更改为使用RDS而不是DynamoDB来存储帖子数据，我们将不得不重新实现推荐服务中的逻辑以及访问帖子数据的所有其他服务。

单片应用程序具有解释帖子数据的复杂逻辑 ，例如，如何确定帖子是否应该对给定用户不可见。我们必须在推荐服务中重新实现这些逻辑。一旦整体应用程序更改或添加新逻辑，我们也需要在任何地方进行相同的更改。

即使推荐服务是自己的数据访问模式的错误选项，推荐服务仍然停留在DynamoDB上。

在解耦存储模型中，推荐服务不能直接访问发布数据，也不能直接访问任何其他新服务。发布数据的实​​现细节仅保留在一个服务中。有不同的方法来实现这一目标。

Option A 理想情况下，应该有一个拥有帖子数据的Post服务，其他服务只能通过Post服务的API访问邮政数据。但是，为所有核心数据模型构建新服务可能是一项昂贵的前期投资。

当人员配置有限时，还有一些更实用的方法。根据数据访问模式，它们实际上可能是更好的方式。

在 选项B 中，单一应用程序可让推荐服务知道何时更新相关的帖子数据。通常，这不必立即发生，因此我们可以将其卸载到排队系统。

在 选项C 中，ETL管道生成推荐服务的发布数据的只读副本，以及可能对推荐有用的其他数据。在这两个选项中，推荐服务完全拥有其数据，因此它可以灵活地缓存数据或使用最适合的数据库技术。

解耦“建立服务”和“运行服务”

如果构建微服务很难，那么运行服务往往更难。 当运行服务与构建每个服务相结合时，它会减慢工程团队的速度，团队必须不断重新发明这样做。我们希望让每项服务都专注于自己的工作而不用担心如何运行服务的复杂问题，包括网络，通信协议，部署，可观察性等。服务管理应该与每个服务的实现完全分离。

由于最近在 容器化，容器编排，服务网格，应用程序性能监 控等方面的技术进步，“运行服务”的解耦变得比以往更容易实现。

网络。 网络（例如，服务发现，路由，负载平衡，流量路由等）是运行服务的关键部分。传统方法是为每种平台/语言提供库。它工作但不理想，因为应用程序仍然需要非常繁琐的工作来集成和维护库。通常，应用程序仍然需要单独实现某些逻辑。现代解决方案是在Service Mesh中运行服务。在Medium，我们使用 Istio和Envoy作为边车代理 。构建服务的应用工程师根本不需要担心网络问题。

通信协议 。无论您选择哪种技术堆栈或语言来构建微服务，从一个高效，类型化，跨平台且需要最少开发开销的成熟RPC解决方案开始是非常重要的。支持向后兼容性的RPC解决方案也使部署服务更加安全，即使它们之间存在依赖关系。在Medium，我们选择了gRPC。

一种常见的替代方案是基于>

两个微服务同时 *** 作数据库,怎么避免重复？答:两个微服务同时 *** 作数据库,这样做可以避免重复:将save（新增）实现和select（查询实现）放在不同的方法中，在Controller层去分别调用，这样查询数据就能查到最新新增的数据，不会造成重复现象。

以上就是关于java微服务和分布式的区别有哪些全部的内容，包括:java微服务和分布式的区别有哪些、微服务架构实践 - 你只懂docker与spring boot就够了吗、微服务连接不上redis会直接访问数据库吗等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！