什么是微服务架构啊

微服务(Microservices Architecture)是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。

微服务是指开发一个单个 小型的但有业务功能的服务，每个服务都有自己的处理和轻量通讯机制，可以部署在单个或多个服务器上。

微服务也指一种种松耦合的、有一定的有界上下文的面向服务架构。也就是说，如果每个服务都要同时修改，那么它们就不是微服务，因为它们紧耦合在一起；如果你需要掌握一个服务太多的上下文场景使用条件，那么它就是一个有上下文边界的服务。

微服务架构的优点：

每个微服务都很小，这样能聚焦一个指定的业务功能或业务需求。

微服务能够被小团队单独开发，这个小团队是2到5人的开发人员组成。

微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。

微服务能使用不同的语言开发。

微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。

微服务允许你利用融合最新技术。

微服务只是业务逻辑的代码，不会和HTML,CSS 或其他界面组件混合。

微服务架构的缺点：

微服务架构可能带来过多的 *** 作。

需要DevOps技巧 (>

可能双倍的努力。

分布式系统可能复杂难以管理。

因为分布部署跟踪问题难。

当服务数量增加，管理复杂性增加。

微服务适合哪种情况：

当需要支持桌面，web，移动智能电视，可穿戴时都是可以的。

甚至将来可能不知道但需要支持的某种环境。

微服务架构对于程序员来说是需要掌握的新型技术之一，而其受到追捧的原因就是符合互联网的发展以及其便捷性。今天我们就一起来了解一下，微服务架构带来的变化。

微服务架构给IT系统和团队带来了以下显著的变化：

基础设施的升级，需要引入虚拟化(如Docker)，现存基础设施也需要与之进行适配;

系统架构的升级，需要引入服务注册(如Consul)，服务间的交互方式也需要与之进行适配;

运维平台的升级，建议引入日志收集(如Fluentd)，分布式跟踪(如Zipkin)和仪表盘(如Vizceral/Grafana)等;

运维效率和自动化水平的提升也迫在眉睫，否则无法应对实例数量，变更频率，系统复杂度的快速增长;

观念的转变，基础设施，系统架构和运维平台等的大幅升级，犹如小米加步q换成飞机大炮，相应的战略战术也需要与之相适配才行。

微服务架构下用户面临的监控问题

在转型到微服务架构以后，用户在监控方面主要会面临以下问题。

监控配置的维护成本增加。某个在线系统大概有106个模块，每个模块都需要添加端口监控，进程监控，日志监控和自定义监控;不同服务的监控指标，聚合指标，报警阈值，报警依赖，报警接收人，策略级别，处理预案和备注说明也不完全相同;如此多的内容，如何确保是否有效，是否生效，是否完整无遗漏。

当前针对维护成本，业界常用的几种方法有：

通过变量的方式尽量减少人工输入;

通过监控配置文件解析做一些可标准化的校验;

通过故障演练验证报警是否符合预期;

其次，三方依赖越来越多。沙河电脑培训发现例如Docker的可靠性很大程度上取决于宿主机，如果所在的宿主机发生资源争用，网络异常，硬件故障，修改内核参数， *** 作系统补丁升级等，都可能会让Docker莫名其妙地中招。

简单地说，API主导的连接方法可以被看作是API设计的一种分层方法（至少在本文中是这样）。其中，系统API公开系统的资产数据信息；中间的是流程API，与系统API一起进行编排和组合；顶端的体验API公开来自后端数据源的数据，提供最终用户体验。这种API分层方法与细粒度SOA模式很好地结合在一起，通常，这两者要么可以共存，要么细粒度SOA模式演化成基于细粒度SOA的分层API模式。

API主导的连接方法为细粒度SOA模式提供了一些层次结构，这些层次结构允许对API或微服务进行一致的管理和治理。然而，基于细粒度SOA的分层API模式也存在一些与细粒度SOA 模式类似的深层问题（这很直观）：

在细粒度SOA模式执行单个API调用的地方，基于细粒度SOA的分层API模式现在必须通过层执行多个调用。从“网络跳数”的角度来看，这种模式可能是低效的。但是，基于细粒度SOA的分层API模式中，层次结构的存在并不强制跨越网络来调用每个API。直接的跨层调用，而不是通过网络调用是完全有效的；分层的目的是为了增加灵活性，同时以一种很好地分离关注点的方式构建体系架构。

在细粒度SOA模式管理大量服务的地方，使用分层API将会管理来自多个层次的大量细粒度服务。您的管理工具可能不再像以前那样有效，因为它们可能无法可视化复杂的微服务视图。

最终应用程序的数据存储一致性在分层API模式下实际上得到了改善，因为访问数据的服务都是有组织，且集中地查询或修改应用程序的状态。（例如：系统API）

实际上，对于大多数企业来说，基于细粒度SOA的分层API模式是一个很好的模式，但是，就像细粒度SOA模式一样，在实践过程中会出现困难。然而，这种困难通常在大范围使用时才会显现出来。因此，只有在预期或正在经历大规模的使用时，我们才应该准备其他的模式。

问题：

没有一定层次结构的微服务架构是很难进行合理解释的，因为没有明显的方法来对每个微服务的用途进行分类和可视化。

解决方案：

通过创建按用途分组的分层API（系统层、流程及领域模型层，以及体验层），您可以更容易地管理微服务架构的复杂性。

应用：

将微服务架构分为多个层。通常情况下，可以使用标准化，并具有类似用途的一组微服务以类似的方式工作，从而进一步使微服务架构的复杂性合理化。

影响：

1通过标准化和进一步分解微服务架构，可以提高快速变更的能力。

2由于更专门化的层次结构，进程间服务调用的数量可能增加。

3需要对服务监控和可视化工具进行检查，以确定它们是否能够正确地与分层架构一起工作。

目标：

1快速的敏捷变更。

2可伸缩性：理论上通过基于细粒度SOA的分层API模式可以提高可伸缩性，但实际上，除非有支持自动化的基础设施，否则可伸缩性往往会降低。

主要特点：

1为了实现快速变更，可能存在低效的IPC（Inter-Process Communication，进程间通信）。

2数据一致性和状态管理能力较差，但允许高度重用。重用本身会抵消变更的速度。

3由于与现存模式的相似性，已有的问题往往同样会出现。

4基于细粒度SOA的分层API模式在小范围内使用效果很好，在大规模情况下会出现困难。

5由于采用了结构化的体系架构方法，所以具有很高的内聚性。

6重点放在服务颗粒度要细，但通常没有考虑其能力。

7基于细粒度SOA的分层API模式以集成为导向，每个微服务依赖于外部系统。这将会降低变更的速度。

基于细粒度SOA的分层API模式如何与SOA或API等现有系统共存？

基于细粒度SOA的分层API模式往往是与现有IT资产共存的最佳方式。由于分层减少了每个微服务的范围，并约束了其用途，因此该模式能够在不明显降低变更速度的情况下，最好地连接和利用现有IT系统。然而，通过细粒度和分层的设计来协调变更可能是一个挑战。您可能需要使用一定的技术手段来管理所有不同微服务之间的契约，或者使用完全自动化的测试技术来确保变更不会造成破坏。

一、服务注册中心的由来

假如没有服务注册中心，我们会干些什么事情呢？

在传统行业的项目架构中以下的方案最为常见了：

这种架构开发、部署都是最简单的，一般适用于中小企业访问量并不是太多的情况下，各个系统服务一台机器就搞定了。系统之间的调用也是拿到对方的IP+PORT直接连接。

接下来可能因为应用B开始访问量大了，单台机器已经不能满足我们的需求，于是一些反向代理工具应运而出，其中比较常见的有Apache、Nigix，架构演变为：

相比之前的应用B的单台机器访问，这种nginx代理的方式减轻了服务器的压力，但是可能会出现Nginx挂了，那么整个服务也不可用，于是又来了这么一套架构：

这样看方案算是完美了吧。然后事情并不是想象的那么一帆风顺，这还只是应用A调用一个应用B，如果应用A调用的可能是应用B、C、D、E，这种完全就不知道他后面到底还想干嘛，这种架构看似可以，但是绝对会累死运维的（nginx的配置将会非常混乱，直接导致运维不干了）。

服务注册中心干些什么事情呢？

上面提到的那种靠人力（主要是运维干的事情）比较繁琐，还不好维护，有这么几点不方便：应用服务的地址变了、双十一搞活动服务器新增等等。那么我们可以有这么的一种架构：

    服务注册中心主要是维护各个应用服务的ip+port列表，并保持与各应用服务的通讯，在一定时间间隔内进行心跳检测，如果心跳不能到达则对服务IP列表进行剔除，并同时通知给其它应用服务进行更新。同样要是有新增的服务进来，应用服务会向注册中心进行注册，服务注册中心将通知给其它应用进行更新。每个应用都有需要调用对应应用服务的地址列表，这样在进行调用时只要处理客户负载杂均衡即可。

二、微服务注册中心

1Zookeeper

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。

上面的话直接摘抄百度百科的内容，国内很多公司做分布式开发最初的选型大部分都是采用dubbo框架。dubbo框架注册中心主要使用zookeeper。zookeeper服务端与客户端的底层通讯为netty。zookeeper采用CAP理论中的CP，一般集群部署最少需要3台机器。

2Euraka

先来看一下euraka的架构图：

Register：服务注册

当Eureka客户端向Eureka Server注册时，它提供自身的元数据，比如IP地址、端口，运行状况指示符URL，主页等。

Renew：服务续约

Eureka客户会每隔30秒发送一次心跳来续约。 通过续约来告知Eureka Server该Eureka客户仍然存在，没有出现问题。 正常情况下，如果Eureka Server在90秒没有收到Eureka客户的续约，它会将实例从其注册表中删除。 建议不要更改续约间隔。

Fetch Registries：获取注册列表信息

Eureka客户端从服务器获取注册表信息，并将其缓存在本地。客户端会使用该信息查找其他服务，从而进行远程调用。该注册列表信息定期（每30秒钟）更新一次。每次返回注册列表信息可能与Eureka客户端的缓存信息不同， Eureka客户端自动处理。如果由于某种原因导致注册列表信息不能及时匹配，Eureka客户端则会重新获取整个注册表信息。 Eureka服务器缓存注册列表信息，整个注册表以及每个应用程序的信息进行了压缩，压缩内容和没有压缩的内容完全相同。Eureka客户端和Eureka 服务器可以使用JSON / XML格式进行通讯。在默认的情况下Eureka客户端使用压缩JSON格式来获取注册列表的信息。

Cancel：服务下线

Eureka客户端在程序关闭时向Eureka服务器发送取消请求。 发送请求后，该客户端实例信息将从服务器的实例注册表中删除。该下线请求不会自动完成，它需要调用以下内容：

DiscoveryManagergetInstance()shutdownComponent()；

Eviction 服务剔除

在默认的情况下，当Eureka客户端连续90秒没有向Eureka服务器发送服务续约，即心跳，Eureka服务器会将该服务实例从服务注册列表删除，即服务剔除。

自我保护机制：

既然Eureka Server会定时剔除超时没有续约的服务，那就有可能出现一种场景，网络一段时间内发生了 异常，所有的服务都没能够进行续约，Eureka Server就把所有的服务都剔除了，这样显然不太合理。所以，就有了 自我保护机制，当短时间内，统计续约失败的比例，如果达到一定阈值，则会触发自我保护的机制，在该机制下， Eureka Server不会剔除任何的微服务，等到正常后，再退出自我保护机制。自我保护开关(eurekaserverenableself-preservation: false)

3Consul

consul推荐的架构图：

Consul不像Euraka的部署那么简单，他是go语言开发的，需要运维单独部署，有提供java的客户端连接，采用的是CAP的CP。

4Nacos

    Euraka是Spring Cloud Netflix早期版本中推荐使用的，后来euraka10版本不再维护，euraka20已经闭源，导致很多新项目基于Spring Cloud Netflix 开发的选型变迁为Consul

Nacos是阿里开源的服务注册中心，它可以与spring cloud aliaba集成使用。

Nacos的官方介绍：

    Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您实现动态服务发现、服务配置管理、服务及流量管理。

    Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。 Nacos 是构建以“服务”为中心的现代应用架构(例如微服务范式、云原生范式)的服务基础设施。

Nacos 地图

Nacos 生态图

如 Nacos 全景图所示，Nacos 无缝支持一些主流的开源生态，例如

Spring Cloud

Apache Dubbo and Dubbo Mesh TODO

Kubernetes and CNCF TODO

三、服务注册与发现技术选型

以下是来自网上的一个分享：

除了上述的几种以外，笔者更推荐使用Nacos作为服务注册中心。

推荐理由：

Nacos服务注册表结构Map<namespace, Map<group::serviceName, Service>>采用多层次Map结构，控制的颗粒度更细，支持金丝雀模式发布，心跳同步机制也更快速，服务更新更及时。

一、面向服务的架构SOA

面向服务的架构是一种软件体系结构，应用程序的不同组件通过网络上的通信协议向其他组件提供服务。通信可以是简单的数据传递，也可以是两个或多个服务彼此协调连接。这些独特的服务执行一些小功能，例如验证付款、创建用户 帐户 或提供社交登录等。

面向服务的架构不太关于如何对应用程序进行模块化构建，更多的是关于如何通过分布式、单独维护和部署的软件组件的集成来组成应用程序。这些通过技术和标准来实现，通过技术和标准使得组件能够更容易地通过网络（尤其是IP网络）进行通信和协作。

SOA架构中有两个主要角色： 服务提供者（Provider）和服务使用者（Consumer）。 而软件代理则可以 扮演这 两个角色。该Consumer层是用户（人、应用程序或第三方的其它组件）与SOA交互的点，和Provider层则由SOA架构内的所有服务所构成。

SOA首先在90年代中期得名，当时一家名为Gartner Group的公司认识到了这个软件架构的新趋势，并在全球推广。通过这样做，他们设法大大加快了这种架构模式的采用和进一步发展。然而，使用分布式服务作为软件体系结构的最早记录可追溯到二十世纪80年代初。

二、微服务架构

微服务架构在某种程度上是面向服务的架构SOA继续发展的下一步。基本上，这种架构类型是开发软件，网络或移动应用程序作为独立服务套件（又称微服务）的一种特殊方式。这些服务的创建仅限于一个特定的业务功能，如用户管理、用户角色、电子商务车、搜索引擎、社交媒体登录等。此外，它们是完全独立的，也就是说它们可以写入不同的编程语言并使用不同的数据库。集中式服务管理几乎不存在，微服务使用轻量级>

微服务有助于开发人员用更低的成本和更少的错误来开发程序。

常用的微服务框架：

1、Spring Boot

Spring Boot是Spring的一个特定版本，它通过对配置细节的处理，使微服务构建更加简便。创建Spring Boot旨在自启动任何类型的Spring项目，而不仅仅是微服务。应用程序完成后，Spring Boot将在Web服务器中混合，并输出一个JAR文件，JVM除外。你可以将其视为原始Docker容器，这也是许多负责构建微服务的开发者都非常喜欢Spring Boot的原因。

2、Dropwizard

Dropwizard框架为开发者提供了一个非常简单的模型，里面包含了许多重要的模块，你可以根据需求添加一些业务逻辑，或者配置其他内容，最后你会发现JAR文件非常小，并且能够快速启动。

Dropwizard最大的限制可能是缺乏依赖注入。如果你希望使用依赖项注入来保持代码的整洁和松散耦合，则需要自己添加库，这点和Spring不同，但是现在Dropwizard也支持大多数功能，包括日志记录、健康检查和提供d性代码。

3、Cricket

是一个用于快速API开发框架。Cricket很小，尽管它包括许多额外的功能，如键值数据存储，以避免连接数据库和调度程序来控制后台重复处理。没有添加复杂性或其他依赖项，因此很容易将代码添加到Cricket并启动独立的微服务。

4、Jersey

开发web服务的标准方法之一是RESTful web服务的Java API(又名JAX-RS)，这是Jersey框架中实现的通用规范。这种方法主要依赖于使用注释来指定路径映射和返回细节。从参数解析到JSON打包的所有其他内容都由Jersey处理。

Jersey的主要优点是它实现了JAX-RS标准，这个特性非常受欢迎，一些开发人员习惯将Jersey与Spring Boot结合在一起使用。

5、Play

体验JVM跨语言能力的最佳方式之一是使用Play框架，这是可以与Java或任何其他JVM语言兼容的。它的基础非常现代，具有异步、无状态的模型，不会让试图跟踪用户及其会话数据的线程使服务器过载。还有许多额外的特性可以用来充实网站，比如OpenID、验证和文件上传支持。Play代码库已经发展了十多年，因此你还会发现类似于对XML的支持的这种古老的功能。play既成熟又轻盈，这种组合还是比较有特色的。

当然，常用的Java微服务框架还有Swagger、Helidon、WildFly Thorntail等，在此就不多赘述了。

希望能帮到你，望采纳！！！

微服务架构对于程序员来说是需要掌握的新型技术之一，而其受到追捧的原因就是符合互联网的发展以及其便捷性。

今天我们就一起来了解一下，微服务架构带来的变化。

微服务架构给IT系统和团队带来了以下显著的变化：基础设施的升级，需要引入虚拟化(如Docker)，现存基础设施也需要与之进行适配;系统架构的升级，需要引入服务注册(如Consul)，服务间的交互方式也需要与之进行适配;运维平台的升级，建议引入日志收集(如Fluentd)，分布式跟踪(如Zipkin)和仪表盘(如Vizceral/Grafana)等;运维效率和自动化水平的提升也迫在眉睫，否则无法应对实例数量，变更频率，系统复杂度的快速增长;观念的转变，基础设施，系统架构和运维平台等的大幅升级，犹如小米加步q换成飞机大炮，相应的战略战术也需要与之相适配才行。

微服务架构下用户面临的监控问题在转型到微服务架构以后，用户在监控方面主要会面临以下问题。

监控配置的维护成本增加。

某个在线系统大概有106个模块，每个模块都需要添加端口监控，进程监控，日志监控和自定义监控;不同服务的监控指标，聚合指标，报警阈值，报警依赖，报警接收人，策略级别，处理预案和备注说明也不完全相同;如此多的内容，如何确保是否有效，是否生效，是否完整无遗漏。

当前针对维护成本，业界常用的几种方法有：通过变量的方式尽量减少人工输入;通过监控配置文件解析做一些可标准化的校验;通过故障演练验证报警是否符合预期;其次，三方依赖越来越多。

重庆电脑培训>

以上就是关于什么是微服务架构啊全部的内容，包括:什么是微服务架构啊、微服务架构带来的变化分析、六种常用的微服务架构设计模式（建议收藏）等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！