精华内容
下载资源
问答
  • 微服务构建

    2019-05-11 13:06:01
    被拆分成的每一个小型服务都围绕着系统中的某一项或一些耦合度较高的业务功能进行构建,并且每个服务都维护着自身的数据存储、业务开发、自动化测试案例以及独立部署机制。由于有了轻量级的通信协作基础,所以...

    基础知识

    微服务架构

    • 微服务是系统架构的一种设计风格,它的主旨是将一个原本独立的系统拆分成多个小型服务,这些小型服务都在各自独立的进程中运行,服务之间通过基于HTTPRESTful API进行通信协作。被拆分成的每一个小型服务都围绕着系统中的某一项或一些耦合度较高的业务功能进行构建,并且每个服务都维护着自身的数据存储、业务开发、自动化测试案例以及独立部署机制。由于有了轻量级的通信协作基础,所以这些微服务以使用不同的语言来编写

    与单体系统的区别

    • 单体系统部署在一个进程内,往往我们修改了一个很小的功能,为了部署上线会影响其他功能的运行。并且,单体应用中的各个功能模块的使用场景、并发量、消耗的资源类型都各不相同,对资源的利用又互相影响,这样使得对于各个业务模块的系统容量很难给出较为准确的评估。
    • 微服务因将服务拆分从而引发了如下一些单体应用这没有的问题:
      1. 接口的一致性:服务的拆分,但是业务逻辑上的依赖并不会消除,只是从单体应用中的代码依赖变为了服务间的通信依赖。
      2. 分布式的复杂性:分布式环境的问题都将是微服务架构系统设计时要考虑的重要因素,比如网络延迟、分布式事务、异步消息等。

    微服务架构的九大特性

    1. 服务组件化。
    2. 按业务组织团队。
    3. 产品的态度。
    4. 智能端点与哑管道。
    5. 去中心化治理。
    6. 去中心环管理数据。
    7. 基础设施自动化。
    8. 容错设计。
    9. 演进式设计。

    Spring Cloud

    • Spring Cloud是一个基于Spring Boot实现的微服务架构开发工具。它为微服务架构中涉及的配置管理、服务治理、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等操作提供了一种简单的开发方式。

    #微服务构建:Spring Boot

    • Spring Boot自身拥有自动化配置、快速开发、轻松部署等优点,非常适合用作微服务架构中各项具体微服务的开发框架。
    • Spring Boot本身可以很好地融入Docker容器,并且自身就支持嵌入式的Tomcat、Jetty等容器。所以对于一个web应用只需要打成jar包,然后通过java -jar命令直接运行就能启动,这使得Spring Boot应用变得非常轻便。
    • 如何使用Spring Boot快速构建一个项目,可参考相关官方文档。

    配置详解

    配置文件

    • Spring Boot的配置文件除了可以使用传统的properties文件之外,还支持现在被广泛推荐使用的YAML文件。在yaml文件中,还可以在一个单个文件中通过spring.properties属性来定义多个不同的环境配置。如下:
    server:
      port: 8080
    ---
    spring:
      profiles: test
    server:
      port: 8081
    ---
    spring:
      profiles: prod
    server:
      port: 8082
    
    • 注意yaml目前还无法通过@PropertySources注解来加载配置。如果想要加载,需要自己手写一个类,继承DefaultPropertySourceFactory类重写createPropertySource方法。

    自定义参数和参数引用

    • 首先在配置文件中定义参数,如app.name=****
    • 使用${参数名},如${ap.name}即可。

    多环境配置

    • Spring Boot中,多环境配置的文件名需要满足application-{profile}.properties的格式,其中{profile}对应环境标识。如下:
      1. applcation-dev.properties:开发环境
      2. application-test.properties:测试环境
      3. application-prod.properties:生产环境
    • 然后在application-prooperties文件中通过spring.profiles.active属性来设置。

    加载顺序

    1. 在命令行中传入的参数;
    2. SPRING_APPLICATION_JSON中的属性。它是以JSON格式配置在系统环境变量中的内容。
    3. java:comp/env中的JNDI属性。
    4. Java的系统属性,可以通过System.getProperties()获得的内容。
    5. 操作系统的环境变量;
    6. 通过random.*配置的随机属性。
    7. 位于当前应用jar包之外,针对不同{profile}环境的配置文件内容。
    8. 位于当前应用jar包之内,这对不同{profile}环境的配置文件内容。
    9. 位于当前应用jar包之外的application.propertiesyaml配置内容。
    10. 位于当前应用jar包之内的application.propertiesyaml配置内容。
    11. @Configuration注解修改的类中,通过@PropertySource注解定义的属性。
    12. 应用默认属性,使用SpringApplication.setDefaultProperties定义的内容。

    优先级按上面的顺序由高到低,数字越小优先级越高。

    监控与管理

    • 为了让运维系统能够获取各个微服务应用的相关指标以及实现一些常规操作控制,需要开发一套专门用于植入各个微服务应用的接口供监控系统采集信息。
    • 引入spring-boot-starter-actuator模块,能够自动为Spring Boot构建的应用提供一系列用于监控的端点。
    • 可以将原生的断点分为以下三个大类:
      1. 应用配置类。获取应用程序中加载的应用配置、环境变量、自动化配置报告等与Spring Boot应用密切相关的配置类信息。
      2. 度量指标类。获取用于监控的度量指标,如内存信息、线程池信息、HTTP请求统计等。
      3. 操作控制类。提供对应用关闭等操作类功能。

    应用配置类

    该端点提供的信息报告可以说是一种静态报告。

    • /autoconfig:该断点用来获取应用的自动化配置报告,其中包括所有自动化配置的候选项。
      • postiveMatches返回的是条件匹配成功的自动化配置;
      • negativeMatches返回的是条件匹配不成功的自动化配置。
    • /beans:用来获取应用上下文中创建的所有Bean
    • /configprops:该端点用来获取应用配置的属性信息报告。
    • /env:该端点与/configprops不同,它用来获取应用所有可能的环境属性报告。包括环境变量、JVM属性、应用的配置属性、命令行中的参数。
    • /mappings:该端点用阿里返回所有Spring MVC的控制器映射关系报告。
    • /info:返回一些应用自定义的信息。

    度量指标类

    该端点提供的报告内容则可以说是动态变化的,提供了一些应用程序运行过程中的一些快照信息。如内存使用情况、HTTP请求统计、外部资源指标等。

    • /metrics:返回当前应用的各类重要度量指标。
    • /health:获取应用的各类健康指标信息。
    • /dump:用来暴露程序运行中的线程信息。
    • /trace:返回基本的HTTP跟踪信息。

    控制操作类

    他们都是默认启动的。并且他们拥有更强大的控制能力,如果想要使用他们,需要通过属性来配置并开启操作。

    展开全文
  • 深入理解Spring cloud与微服务构建 PDF 深入理解Spring cloud与微服务构建 PDF
  • 《深入理解SpringCloud与微服务构建》_sample.pdf 《深入理解SpringCloud与微服务构建》_sample.pdf 《深入理解SpringCloud与微服务构建》_sample.pdf 《深入理解SpringCloud与微服务构建》_sample.pdf
  • 本文的素材来源于我们在开发中的一些最佳实践案例,从开发、监控、日志这三个角度介绍了一些我们基于Go技术栈的微服务构建经验。微服务的开发过程中,不同模块由不同的开发者负责,明确定义的接口有助于确定开发者的...
  • 微服务构建思路与方法论

    千次阅读 多人点赞 2018-12-15 18:13:13
    微服务规划、微服务构建、微服务协同、微服务测试、微服务治理、微服务下线等是企业采用微服务必须面对的微服务生命周期管理问题。我们讨论过微服务治理的问题,由于一些原因未能整理微服务拆分、微服务设计、微服务...

    微服务规划、微服务构建、微服务协同、微服务测试、微服务治理、微服务下线等是企业采用微服务必须面对的微服务生命周期管理问题。我们讨论过微服务治理的问题,由于一些原因未能整理微服务拆分、微服务设计、微服务构建等相关内容。网上对微服务的讨论更多是微服务开发框架的使用,较少深入讨论微服务拆分、设计和构建。我们提出过采用主数据思想来构建微服务体系,目前也有采用DDD方式来设计微服务的,这里我们探讨下微服务构建的一些思路和方法,以期抛砖引玉,带来更多更深入的探讨。

    一、 采用微服务的目的

    采用微服务,首先要有明确的目的,有清晰的认知。微服务并不是放之四海而皆准的理论,有其适用范围和场景。如果用单体应用能轻松解决的问题就没必要用微服务架构。在遇到有分布式、弹性扩展等需求的情况,才需要考虑微服务架构。一个微服务我们可以认为其是一个小的单体应用。在有很多单体应用之间需要通信、协同的情况下,或者通过单体应用之间的集成无法满足业务性能要求,需要重构业务应用系统时,才需要考虑采用微服务架构。
    我们也提到过,微服务意在重构!并且通常在大中型企业有众多的单体业务系统情况下,各单体业务应用集成可能成为一个问题的时候,需要考虑采用微服务架构重构业务应用。由于微服务架构体系需要众多的基础设施平台和基础组件支撑,才能发挥微服务架构的优势,所以一些小公司或者没有计划进行大规模改造的情况下,采用微服务可能无法展现其价值,并且管理任务有可能更多、更繁琐。
    服务化的目的在于重用,微服务也是一样。其实无论函数化、模块化、组件化、服务化等重要目的在于共享、重用。技术经过若干年后总会以另外一种面貌重现,就像当前的Serverless 函数编程,原来单体应用的函数放到云端,加个Serverless的概念马上就高大上了。微服务还有重要一点在于其分布式弹性,微服务实例数弹性伸缩,可以和容器平台结合,利用容器弹性伸缩的特性,实现微服务的弹性,快速响应业务变化需求。
    采用微服务往往也是因为其轻量,可以快速迭代,即时响应新业务需求,快速开发部署微服务应用,在抢占市场的同时可以持续的迭代和完善。所以通常采用微服务是以业务需求变化快的场景为起始,比如活动促销等,然后逐步推广到其他业务场景。

    二、 构建思路,方法论

    跟很多厂商交流微服务,基本上都在谈SpringCloud、Dubbo,谈到用什么理论或方法来指导微服务的设计和构建时,几乎没有厂商关注这些,感觉大部分人也就是用微服务开发框架去写代码,至于微服务设计和构建,则基本上还不具备相应的能力。没有理论指导,每个人理解的微服务可能都不一样,所以实现出来的微服务也就五法八门、千奇百怪了。
    都知道微服务是一种架构方式,但怎么架构?什么是合适的微服务架构?可能就仁者见仁、智者见智了。如果仅知道SpringCloud,那也就是一个编码人员,不具备微服务设计和构建的能力。微服务设计和构建则需要相应的理论功底,比如比较流行的DDD领域驱动设计方法,但领域驱动设计侧重业务领域,而且整个体系复杂,业务领域专家所设计的领域模型并不一定适合技术实现,需要技术人员的二次建模,最重要的是数据的存储未充分考虑。微服务可能根据数据的量、请求负载的量、数据的类型、来源等采用不同的存储方法,可能需要考虑分库、分表、分区、物化视图等不同的方式,也可能随着业务数据的变化而更新微服务的存储和实现。我们认为这才是微服务设计和构建需要重点考虑的方面。至于用什么工具开发,那是次要的选择。
    nel5dc0v0d11
    如果了解主数据管理(MDM)的话,我们建议采用主数据的思想来构建和设计微服务。主数据强调唯一数据来源。主数据管理是实现主数据集成和治理,主数据是数据的骨架,其他数据是血肉,它们共同构成一个完整的企业数据整体。主数据并不是不关注业务,恰恰是从业务流程梳理开始,只不过我们不是构建一套主数据管理系统,而是以主数据的思路来构建微服务数据模型和存储模型。谈主数据可能需要了解通用数据模型CDM,它非常有助于我们构建适合的微服务数据模型。
    当然,我们觉得两种方法结合可能会更好一些。目前只是理论上的思路,具体还缺少实践,所以也希望能充分和有这方面考虑的团队或个人深入交流。

    三、 重点在数据

    微服务重点不在采用什么语言或什么开发工具,我们曾经讨论过SpringCloud/SpringBoot不是微服务,SpringCloud/SpringBoot开发的服务也不一定就是微服务。微服务是一个从业务层到数据层到存储层都是相对独立完成特定功能的一个单元,所以我们经常听到拆库、拆表的讨论,但缺指导性的一些原则和方法论。微服务重点在数据,因此采用微服务和数据治理能力密切相关。数据标准、数据安全、数据所属、数据模型、数据持久化等直接影响着微服务的质量和实施难度。什么时候数据存放数据库?选择什么数据库?什么时候需要分区表?什么时候分表?什么时候需要分库?非结构化数据如何处理?……这些不是选择一个开发框架就能解决的问题,这才是微服务设计和构建的重点。
    通常情况下需要考虑由原子微服务来准备数据。不同的场景数据准备的方式可能是不一样的。不过在当前的大多数业务场景下,实时及准实时的需求越来越多,所以数据准备需要在原子微服务中以实时或准实时的方式准备好。可以是高效的主动获取,也可以是被动的实时更新,但要确保数据的正确、准确。而关于用业务微服务和应用微服务封装业务逻辑和应用组件协同逻辑,我们将在下一篇《微服务协同》中详细讨论。

    四、 提取基础组件

    采用微服务在梳理完业务应用流程之后,首先就需要考虑提取基础公共组件。这些组件是每个应用系统都可能需要用到的,所以这些组件需要首先提取出来。比如日志服务、监控服务、告警服务、统计服务、权限服务、认证服务等。采用微服务架构还会涉及微服务注册发现、微服务配置、微服务网关等。这些服务通常也有开源的组件,可以协助构建整个微服务体系基础组件服务。但开源的毕竟只是在技术上可行,应用于实际的业务环境还有不少的工作要做,后期技术支持也是个需要认真考虑的事项。
    fnvftq4wt3pw
    在提取完非业务性功能组件服务之后,可能需要考虑业务性功能组件,比如公共数据字典服务、数据标准转换服务、数据分发规则服务等等。这些服务和整个业务微服务设计架构紧密相关,是其他业务微服务需要共享使用的,提取这些微服务将有助于快速的构建其他业务微服务,快速敏捷的推进微服务建设。
    五、 基础设施支撑
    微服务不是开发几个所谓的微服务就ok了,它需要众多的基础设施支撑才能更好的体现微服务的价值。微服务的开发、测试、部署、治理、运维等整个生命周期过程都需要各种设施的支持。比如基础设施资源平台,可以提供虚拟机、存储等资源服务。数据治理平台在设计构建微服务时有相应的数据标准和数据安全等支持。服务管控平台则提供微服务的部署、运营管理。接口管理平台提供微服务对内对外的标准API服务等等。
    jrk6z5mumrlu

    微服务意在重构,并不是为了某一个应用系统,而是要考虑企业内的所有应用系统,这些应用系统的公共的服务,首先就是共享,这是重构的意义所在。

    六、 量变到质变,持续的过程

    我们想强调的是,微服务设计和构建不是一步到位的。它是一个持续构建、持续优化的迭代过程。就像前面我们提到的,随着数据量的变化,微服务的实现可能需要优化,这是一个迭代的过程。数据量小的情况下可以一个库一张表,但数据量巨大的情况可能需要考虑分表、分库,甚至分区域数据中心。数据物理存储模型的改变必然导致微服务实现的变化。还有就是数据来源的变化,微服务协同的变化等都会带来微服务实现的调整。
    微服务初始实现的时候可能也就几个、十几个或几十个微服务。不过在重构第二个业务系统的时候就会简单些,公共的组件服务不需要再构建了,直接可以使用。关注的重点是业务逻辑在业务微服务中的实现,公共的能力比如日志、配置、权限等只需要按照标准的服务接口调用相应的服务就可以了。还有一些公共的业务微服务组件可以共享,比如数据字典服务、一些公共的服务比如客户服务、产品服务、账户服务等。所以随着微服务构建的增多,在重构一个应用系统时将会越来越容易,越来越便捷,越来越快速,越来越敏捷。
    其实我们觉得微服务的构建过程也会符合二八规则,前期做80%的工作可能只实现了20%的业务需求,但随着量的增加,后期20%的工作就可以实现80%的业务需求。这就是服务共享的收益。
    到后期,也许就没有原子微服务的构建需求,更多的是业务应用微服务的构建,在一个业务需求提出后,选择合适的原子微服务或业务微服务通过流程配置就可以快速的发布部署,真正实现对业务需求的敏捷响应。

    原文链接:http://www.talkwithtrend.com/Article/242631

    展开全文
  • 《深入理解Spring+Cloud与微服务构建》-方志明 《深入理解Spring+Cloud与微服务构建》-方志明
  • 深入理解Spring+Cloud与微服务构建源代码,PDF网上资源多就不分享了。
  • goa:在Go中基于Ruby's Praxis设计的微服务构建框架
  • EmailService:从Go中的微服务构建的电子邮件服务
  • 《深入理解Spring Cloud与微服务构建》从零开始详细讲解spring cloud,最后还有一个项目实例。 本资源转载自网络,如有侵权,请联系上传者或csdn删除 查看此书详细信息请在美国亚马逊官网搜索此书
  • 深入理解Spring Cloud与微服务构建 方志朋 高清pdf 最新的电子书 自己花钱买的,分享给大家
  • Spring Cloud与微服务构建:微服务简介 单体架构及其不足 1.单体架构简介 在软件设计中,经常提及和使用经典的3曾模型,即表示层、业务逻辑层和数据访问层。 表示层:用于直接和用户交互,也成为交互曾,通常是网页...

    Spring Cloud与微服务构建:微服务简介

    单体架构及其不足

    1.单体架构简介
    在软件设计中,经常提及和使用经典的3曾模型,即表示层、业务逻辑层和数据访问层。

    • 表示层:用于直接和用户交互,也成为交互曾,通常是网页、UI等;
    • 业务逻辑层:即业务逻辑处理层,例如用户输入的信息要经过业务逻辑层的处理后,才能展现给用户;
    • 数据访问层:用于操作数据库,用户在表示层会产生大量的数据,通过数据访问层对数据库进行读写操作;

    虽然在软件设计中划分了经典的3层模型,但是对业务场景没有划分。一个典型的单体应用就是将所有的业务场景的表示层、业务逻辑层和数据访问层放在一个工程中,最终通过编译、打包,部署在一台服务器上。例如典型的J2EE工程,它是将表示层的JSP、业务逻辑层的Service、Controller和数据访问层的Dao打成war包,部署在Tomcat、Jetty或者其他Servlet容器中运行。经典的单体应用如下图所示:
    739632-20180704145652171-767509586.png

    在一个小型应用的初始阶段,访问量较小,应用只需要一台服务器就能够部署所有的资源,例如将应用程序、数据库、文件资源等部署在同一台服务器上。最典型的就是LAMP系统,即服务器采用Linux系统,开发应用程序的语言为PHP,部署在Apache服务器上,采用MySQL数据库。在应用程序的初始阶段,采用这种架构的性价比是非常高的,开发速度快,开发成本低,只需要一台廉价的服务器。此时的服务器架构如下图所示:
    739632-20180704150031168-1466600379.png

    2.单体架构存在的不足
    在应用的初始阶段,单体架构无论是在开发速度、运维难度上,还是服务器的成本上都有着显著的优势。在一个产品的前景不明确的初始阶段,用单体架构是非常明智的选择。随着应用业务的发展和业务复杂度的提高,这种架构明显存在很多的不足,主要体现在以下3个方面:

    • 业务越来越复杂,单体应用的代码量越来越大,代码的可读性、可维护性和可扩展性下降,新人接手代码所需时间成倍增加,业务扩展带来的代价越来越大;
    • 随着用户越来越多,程序承受的并发越来越高,单体应用的并发能力有限;
    • 测试的难度越来越大,单体应用的业务都在同一个程序中,随着业务的扩张、复杂度的增加,单体应用修改业务或者增加业务或许会给其他业务带来一定的影响,导致测试难度增加;

    3.单体架构使用服务器集群及存在的不足
    随着业务的发展,大多数公司会将单体应用进行集群部署,并增加负载均衡服务器(例如Nginx等)。另外,还需要增加集群部署的缓存服务器和文件服务器,并将数据库读写分离,以应对用户量的增加而带来的高并发访问量。此时的系统架构如下如所示:
    739632-20180704151336435-1044227244.png
    用负责均衡服务器分发高并发的网络请求,用户的访问被分派到不同的应用服务器,应用服务器的负载不再成为瓶颈,用户量增加时,添加应用服务器即可。通过添加缓存服务器来缓解数据库的数据以及数据库读取数据的压力。大多数的读取操作是由缓存完成的,但是仍然有少数操作是从数据库读取的,例如缓存失效、实时数据等。当有大量的读写操作时,将数据库进行读写分离是一个不错的选择,例如MySQL的主从热备份,通过相关配置可以将主数据流服务器的数据同步到从数据库服务器,实现数据库的读写分离,读写分离能够改善数据库的负载能力。
    这种架构有一定的处理高并发的能力,也能应对一定复杂的业务需求,改善了系统的性能。但是依然没有改变系统为单体架构的事实,此时系统存在的不足之处如下:

    • 系统仍然为单体应用,大量的业务必然会有大量的代码,代码的可读性和可维护性依然很差;
    • 面对海量的用户,数据库将会成为瓶颈,解决方案将使用分布式数据库,也就是将数据库进行分库分表;
    • 持续交付能力差,业务越复杂代码越多,修改代码和添加代码所需时间越长,新人熟悉代码的时间长、成本高;

    由此可见,在应用初期,单体应用从成本、开发时间和运维等方面都有明显的优势。但是随着业务量和用户量的增加,它所暴露出来的缺点也显而易见。单体架构已经不能满足复杂的业务和海量的用户系统,改变单体架构势在必行。

    微服务

    一.什么是微服务
    "微服务"最初是由Martin Fowler在2014年写的一篇文章《MicroServices》中提出来的。关于Martin Fowler的介绍,维基百科上是这样描述的:

    Martin Fowler,软件工程师,也是一个软件开发方面的著作者和国际知名演说家,专注于面向对象分析>与设计、统一建模语言、领域建模,以及敏捷软件开发方法,包括极限编程。主要著作有《可重用对象>模型》《重构-改善既有代码的设计》《企业应用架构模式》等;

    对于微服务,业界没有一个严格统一的定义,但是作为"微服务"这一名词的发明人,Martin Fowler对于微服务的定义似乎更具有权威性和指导意义。他的理解如下:

    简而言之,微服务架构的风格,就是将单一程序开发成一个微服务,每个微服务运行在自己的进程>中,并使用轻量级机制通信,通常是HTTP RESTFUL API。这些服务围绕业务能力来划分构建的,>并通过完全自动化部署机制来独立部署。这些服务可以使用不同的编程语言,以及不同数据存储技>术,以保证最低限度的集中式管理;

    以我个人对这段话的理解,总计微服务具有如下特点:

    • 按业务划分为一个独立运行的程序,即服务单元;
    • 服务之间通过HTTP协议相互通信;
    • 自动化部署;
    • 可以用不同的编程语言;
    • 可以用不同的存储技术;
    • 服务集中化管理;
    • 微服务是一个分布式系统;

    1.微服务单元按业务来划分
    微服务的"微"到底需要定义到什么样的程度,这是一个非常难以界定的概念,可以从以下3个方面来界定:一是根据代码量来定义,根据代码的多少来判断程序的大小;二是根据开发时间的长短来判断;三是根据业务的大小来划分。
    根据Martin Fowler的定义,微服务的"微"是按照业务来划分的。一个大的业务可以拆分成若干小的业务,一个小的业务又可以拆分成若干更小的业务,业务到底怎么拆分才算合适,这需要开发人员自己去决定。例如微博最常见的功能是微博内容、关注和粉丝,而其中微博内容又有点赞、评论等,如何将微博这个复杂的程序划分为单个的服务,需要开发团队去决定。
    按业务划分的微服务单元独立不是,运行在独立的进程中。这些微服务单元是高度组件化的模块,并提供了稳定的模块边界,服务与服务之间没有任何的耦合,有非常好的扩展性和复用性。
    传统的软件开发模式通常由UI团队、服务端团队、数据库和运维团队构成,相应地将软件按照职能划分为UI、服务端、数据库和运维等模块。通常这些开发人员各司其职,很少有人跨职能去工作。如果按照业务来划分服务,每个服务都需要独立的UI、服务端、数据库和运维。也就是说,一个小的业务的微服务需要动用一个团队的人去协作,这显然增加了团队与团队之间交流协作的成本。所以产生了跨职能团队,这个团队负责一个服务的所有工作,包括UI、服务端和数据库。当这个团队只有1-2个人的时候,就对开发人员提出了更高的要求。

    2.微服务通过HTTP来互相通信
    按照业务划分的微服务单元独立部署,并运行在各自的进程中。微服务单元之间的通信方式一般倾向于使用HTTP这种简单的通信机制,更多的时候是使用RESTFUL API。这种接受请求、处理业务逻辑、返回数据的HTTP模式非常高效,并且这种通信机制与平台和语言无关。例如用Java写的服务可以消费用Go语言写的服务,用Go语言写的服务又可以小费用Ruby写的服务。不同的服务采用不同的语言去实现,不同的平台去部署,它们之间使用HTTP进行通信,如下图所示:
    739632-20180704160508621-1884224506.png
    服务与服务之间也可以通过轻量级的消息总线来通信,例如RabbitMQ、Kafaka等。通过发送消息或者订阅消息来达到服务与服务之间通信的目的。
    服务与服务通信的数据格式一般为JSON、XML,这两种数据格式与语言、平台、通信协议无关。一般来说,JSON格式的数据比XML轻量,并且可读性也比XML要好。另外一种就是用Protobuf进行数据序列化,经过序列化的数据为二进制数据,它比JSON更轻量。用Protobuf序列化的数据为二进制数据,可读性非常差,需要反序列化才能读懂。由于用Protobuf序列化的数据更为轻量,所以Protobuf在通信协议和数据存储上十分受欢迎。
    服务与服务之间通过HTTP或消息总线的方式进行通信,这种方式存在弊端,其通信机制是不可靠的,虽然成功率很高,但是还是会有失败的时候。

    3.微服务的数据库独立
    在单体架构中,所有的业务都共用一个数据库。随着业务量的增加,数据库表的数量越来越多,难以管理和维护,并且数据量的增加会导致查询速度越来越慢。例如一个应用有这样几个业务:用户信息、用户账户、用户购物车、数据报表服务等。典型的单体架构如下图所示:
    739632-20180704162035552-1623006428.png
    微服务的一个特点就是按照业务划分服务,服务与服务之间无耦合,就连数据库也是独立的。一个典型的微服务的架构就是每个微服务都有自己独立的数据库,数据库之间没有任何联系。这样做的好处在于,随着业务的不管扩张,服务与服务不需要提供数据库集成,而是提供API接口相互调用;还有一个好处是数据库独立,单业务的数据量少,易于维护,数据库性能有着明显的优势,数据库的迁移也很方便。
    另外,随着存储技术的发展,数据库的存储方式数据库的存储方式不再仅仅是关系型数据库,非关系型数据库的应用也非常广泛。例如Redis、MongoDB,它们有着良好的读写性能,因此越来越受欢迎。一个典型的微服务系统,可能每一个服务的数据库都不相同,每个服务所使用的数据存储技术需要根据业务需求来选择,如下图所示:
    739632-20180704164057268-854287908.png

    4.微服务的自动化部署
    在微服务架构中,系统会被拆分为若干个微服务,每个微服务又是一个独立的应用程序。单体架构的应用程序只需要部署一次,而微服务架构有多少个服务就需要部署多少次。随着服务数量的增加,如果微服务按照单体架构的部署方式,部署的难度会呈指数增加。业务的粒度划分的越细,微服务的数量就越多,这时需要更稳定的部署机制。随着技术的发展,尤其是Docker容器技术的推进,以及自动化部署工具(开源组件Jenkins)的出现,自动化部署变得越来越简单。
    自动化部署可以提高部署的效率,减少人为的控制,部署过程中出现错误的概率降低,部署过程的每一步自动化,提高软件的质量。构建一个自动化部署的系统,虽然在前期需要开发人员或运维人员的学习,但是对于整个软件系统来说是一个全系的概念。在软件系统的整个生命周期中,每一步是由程序控制的,而不是人为控制,软件的质量提高到了一个新的高度。随着DevOps这种全新概念的推进,自动化部署必然会成为微服务部署的一种方式。

    5.服务集中化管理
    微服务系统是按业务单元来划分服务的,服务数量越多,管理起来就越复杂,因此微服务必须使用集中化管理。目前流行的微服务框架中,例如Spring Cloud采用Eureka来注册服务和发现,另外Zookeeper、Consul等都是优秀的服务集中化管理框架。

    6.分布式架构
    分布式系统是集群部署的,由很多计算机相互协作共同构成,它能够处理海量的用户请求。当分布式系统对外提供服务时,用户是毫不知情的,还以为是一台服务器在提供服务。分布式系统的复杂任务通过计算机之间的相互协作来完成,当然简单的任务也可以在一台计算机上完成。
    分布式系统通过网络协议来通信,所以分布式系统在空间上没有任何限制,即分布式服务器可以部署不同的机房和不同的地区。
    微服务架构是分布式架构,分布式系统比单体系统更加复杂,主要体现在服务的独立性和服务相互调用的可靠性,以及分布式事务、全局锁、全局ID等,而单体系统不需要考虑这些复杂性。
    另外,分布式系统的应用都是集群化部署,会给数据一致性带来困难。分布式系统中的服务通信依赖于网络,网络不好,必然会对分布式系统带来很大的影响。在分布式系统中,服务之间相互依赖,如果一个服务出现了故障或网络延迟,在高并发的情况下,会导致线程阻塞,在很短的时间内该服务的线程资源会消耗殆尽,最终使得该服务不可用。由于服务的相互依赖,可能会导致整个系统的不可用,这就是"雪崩效应"。为了防止此类事件的发生,分布式系统必然要采取相应的措施,例如"熔断机制"。

    7.熔断机制
    为了防止"雪崩效应"事件的发生,发呢不是系统采用了熔断机制。在用Spring Cloud构建的微服务系统中,采用了熔断器(即Hytrix组建的Circuit Breaker)去做熔断。
    例如在微服务系统中,有a、b、c、d、e、f、g、h等多个服务,用户的请求通过网关后再到具体的服务,服务之间相互依赖,例如服务b依赖于服务f,一个对外暴露的API接口需要服务b和服务f相互协作才能完成。服务之间相互以来的架构如下图所示:
    739632-20180705083841093-332878012.png
    如果此时服务b出现故障或网络延迟,在高并发的情况下,服务b会出现大量的线程阻塞,有可能在很短的时间内线程资源就被消耗完了,导致服务b的不可用。如果服务b为较底层的服务,会影响到其他服务,导致其他服务会一直等待服务b的处理。如果服务b迟迟不处理,大量的网络请求不仅仅堆积在服务b,而且会堆积到依赖于服务b的其他服务。因而服务b出现故障影响的服务,也会影响到依赖于服务b出现故障影响的服务的其他服务,从而由b开始,影响到整个系统,导致整个系统的不可用。这是一件非常可怕的事,因为服务器运营商的不可靠,必然会导致服务的不可靠,而网络服务商的不可靠,也会导致服务的不可靠。在高并发的场景下,稍微有点不可靠,由于故障的传播性,会导致大量的服务不可用,甚至导致整个系统崩溃。
    为了解决这一难题,微服务架构引入了熔断机制。当服务b出现故障,请求失败次数超过设定的阈值之后,服务b就会开启熔断器,之后服务b不进行任何的业务逻辑操作,执行快速失败,直接返回请求失败的信息。其他依赖于b的服务就不会因为得不到响应而线程阻塞,这时除了服务b和依赖于服务b的部分功能不可用外,其他功能正常。熔断服务如下图所示:
    739632-20180705090219709-1255431263.png
    熔断器还有另外一个机制,即自我修复的机制。当服务b熔断后,经过一段时间,半打开熔断器。半打开的熔断器会检查一部分请求是否正常,其他请求执行快速失败,检查的请求如果响应成功,则可以判定服务b正常了,就会关闭服务b的熔断器;如果服务b还不正常,则继续打开熔断器。这种自我熔断机制和自我修复机制在微服务架构中有着重要的意义,一方面它使程序更加健壮,另一方面为开发和运维减少很多不必要的工作。
    最后熔断组件往往会提供一系列的监控,例如服务可用与否、熔断器是否打开、目前的吞吐量、网络延迟状态的监控等,从而很容易让开发人员和运维人员实时了解服务的状态。

    二.微服务的优势
    相对于单体服务来说,微服务具有很多优势,主要体现在以下方面:
    1)将一个复杂的业务分解成若干小的业务,每个业务拆分成一个服务,服务的边界明确,将复杂的问题简单化。服务按照业务拆分,编码也是按照业务来拆分,代码的可读性和可扩展性增加。新人加入团队,不需要了解所有的业务代码,只需要了解他所接管的服务的代码,新人学习时间成本减少。
    2)由于微服务系统是分布式系统,服务与服务之间没有任何的耦合。随着业务的增加,可以根据业务再拆分服务,具有极强的横向扩展能力。随着应用的用户量的增加,并发量增加,可以将微服务集群化部署,从而增加系统的负载能力。简而言之,微服务系统的微服务单元具有很强的横向扩展能力。
    3)服务与服务之间通过HTTP网络通信协议来通信,单个微服务内部高度耦合,服务与服务之间完全独立,无耦合。这使得微服务可以采用任何开发语言和技术来实现。开发人员不再被强迫使用公司以前的技术或已经过时的技术,而是可以自由选择最合适业务场景的或适合自己的开发语言和技术,提供开发效率、减低开发成本。
    4)如果是一个单体的应用,由于业务的复杂性、代码的耦合性,以及可能存在的历史问题。在重写一个单体应用时,要求重写应用的人员了解所有的业务,所以重写单体应用是非常困难的,并且重写风险也很高。如果是微服务系统,由于为服务是按照业务的进行拆分的,并且有坚实的服务边界,所以重写某个服务就相当于重写某一个业务的代码,非常简单。
    5)微服务的每个服务单元都是独立部署的,即独立运行在某个进程里。微服务的修改和部署对其它服务没有影响。试想,假设一个应用只有一个简单的修改,如果是单体架构,需要测试和部署整个应用;而如果采用微服务架构,只需要测试并部署被修改的那个服务,这就大大减少了测试和部署的时间。
    6)微服务在CAP理论中采用的是AP架构,即具有高可用和分区容错的特点。高可用主要体现在系统7*24小时不间断的服务,它要求系统有大量的服务器集群,从而提高了系统的负载能力。另外,分区容错也使得系统更加健壮。

    三.微服务的不足
    凡事都有两面性,微服务也不例外,微服务相对于单体应用来说具有很多的优势,当然也有其不足之处,主要体现在如下方面:
    1.微服务的复杂度
    构建一个微服务系统并不是一件容易的事,微服务系统是分布式系统,构建的复杂度远远超过单体系统,开发人员需要付出一定的学习成本去掌握跟过的架构知识和框架知识。服务于服务之间通过HTTP协议或消息传递机制通信,开发者需要选出最佳的通信机制,并解决网络服务较差时带来的风险。
    另外服务与服务之间相互依赖,如果修改某一个服务,会对另外一个服务产生影响,如果掌控不好,会产生不必要的麻烦。由于服务的依赖性,测试也会变得复杂,比如修改一个比较基础的服务,可能需要重启所有的服务才能完成测试。

    2.分布式事务
    微服务架构所设计的系统是分布式系统。分布式系统有一个著名的CAP理论,即同时满足"一致性"、"可用性"和"分区容错"是一件不可能的事。CAP理论是有Eric Brewer在2000年PODC会议上提出的,该理论在两年后被证明成类。CAP理论告诉架构师不要妄想设计出同时满足三者的系统,应该有所取舍,设计出适合业务的系统。CAP理论如下如所示:
    739632-20180706085605133-1612733727.png

    • Consistency:指数据的强一致性,如果写入某个数据成功,之后读取,读到的都是新写入的数据;如果写入失败,之后读取的都不是写入失败的数据;
    • Aavilability:指服务的可用性;
    • Partition-tolerrance:指分区容错;

    在分布式系统中,P是基本要求,而单体服务是CA系统。微服务系统通常是一个AP系统,即同时满足可用性和分区容错。这就有了一个难题:在分布式系统中如何确保数据的一致性?这就是大家经常讨论的分布式事务。
    在微服务系统中,每个服务都是独立的进程单元,每个服务都有自己的数据库。通常情况下,只有关系型数据库在特定的数据引擎下才支持事务,而大多数非关系型数据库是不支持事务的,例如MongoDB是不支持事物的,而Redis是支持事务的。在微服务架构中,分布式事务一直都是一个难以解决的问题,业界给出的解决方案通常是两阶段提交。
    网上购物在日常生活中是一个非常普通的场景,假设我们在淘宝上买了一部手机,需要从我的账户中扣除1000元钱,同时手机的库存数量需要减1.当然需要在卖方的账户中加1000元钱,为了使案例简单化,暂时不用考虑其他。
    如果这是一个单体应用,并且使用支持事物的MySQL数据库(InnoDB数据库引擎才支持事务),我们可以这样写代码:

    @Transacntional
    public void update() throws RuntimeException{
        updateAccountTable();        // 更新账户表
        updateGoodsTable();        // 更新商品表
    }

    如果是微服务架构,账户是一个服务,而商品是一个服务,这时不能用数据库自带的事务,因为这两个数据表不在一个数据库中。因此常常用到两个阶段提交,两个阶段提交的过程如下如所示:
    739632-20180706095115612-1979038849.png
    第一阶段,service-account发起一个分布式事务,交给事务协调器TC处理,事务协调器TC向所有参与的事务的节点发送处理事务操作的准备操作。所有的参与节点执行准备操作,将Undo和Redo信息写入日志,并向事务管理器返回准备操作是否成功;
    第二阶段,事务管理器收集所有节点的准备操作是否成功,如果都成功,则通知所有的节点执行提交操作;如果有一个失败,则执行回滚操作;
    两阶段提交,将事务分成两部分能够大大提高分布式事务成功的概率。如果在第一阶段都成功了,而执行第二阶段的某一个节点失败,仍然导致数据的不准确,这时一般需要人工去处理,这就是当初在第一步记录日志的原因。另外,如果分布式事务涉及的节点很多,某一个节点的网络出现异常会导致整个事务处于阻塞状态,大大降低数据库的性能。所以一般情况下,尽量少用分布式事务。

    3.服务的划分
    将一个完整的系统拆分成很多个服务,是一件非常困难的事,因为这涉及到了具体的业务长江,比明明一个类更加困难。对于微服务的拆分原则,Martin Fowler给出的建议是:服务是可以被替换和更新的。也就是服务和服务之间无耦合,任何一个服务都可以被替换,服务有自己严格的边界。当然这个原则很抽象,根据具体的业务场景来拆分服务,需要依靠团队人员对业务的熟悉程度和理解程度,并考虑与已有架构的冲入、业务的扩展性、开发的风险和未来业务的发展等诸多因素。
    领域驱动设计是一个全新的概念,也是一个比较理想的微服务拆分的理念。领域驱动设计通过代码和数据分析找到合理的切分点,并通过数据分析来判断服务的划分边界和划分粒度。目前来说,在中国几乎没有公司去落地领域驱动设计这个理念,随着微服务的发展,这一理念在以后有可能会落地。

    4.服务的部署
    一个简单的单体系统可能只需要将程序集群部署并配置负载均衡服务器即可,而部署一个复杂的微服务架构的系统就复杂得多。因为每一个微服务可能还涉及比较低层的组件,例如数据库、消息中间件等。微服务系统往往由数量众多的服务构成,例如Netflix公司大约有600个服务,而每个服务又有大量的实例。微服务系统需要对每个服务进行治理、监控和管理等,而每个服务有大量的配置,还需要考虑服务的启动顺序和启动时机等。
    部署微服务系统,需要开发人员或者运维人员对微服务系统有足够强的控制力。随着云计算和云服务器的发展,部署微服务系统并不是一件难事,例如使用PaaS服务、使用Docker编排等。这就是人们往往提到微服务,就会想到Docker、DevOps的原因。其中,微服务是核心;Docker为容器技术,是微服务最佳部署的容器;DevOps是一种部署手段或理念,他们的关系如图所示:
    739632-20180706104626062-596861959.png

    四.微服务和SOA的关系
    SOA即面向服务的架构,这种架构在20年前就已经被提出了。SOA往往与企业服务总线(ESB)联系在一起,主要原因在于SOA的实施思路是根据ESB模式来整合集成大量单一庞大的系统,这是SOA主要的落地方式。然而,SOA在过去20年并没有取得成功。在谈到微服务时,人们很容易联想到它是一个面向服务的架构,的确,微服务的概念提出者Martin Fowler并没有否认这一层关系。
    微服务相对于和ESB联系在一起的SOA显然轻便敏捷得多,微服务将复杂的业务组件化,实际也是一种面向服务思想的体现。对于微服务来说,它是SOA的一种实现,但是它比ESB实现的SOA更加轻便、敏捷和简单。

    五.微服务的设计原则
    软件设计就好比建筑设计。Architect这个词在建筑学中是"建筑师"的意思,而在软件领域则是"架构师"的意思,可见它们确实有相似之处。无论是建筑师还是架构师,他们都希望把作品设计出自己的特色,并且更愿意把创造出来的东西称之为艺术品。然而现实却是,建筑设计和软件设计有非常大的区别。建筑师设计并建造出来的建筑往往很难有变化,除非拆了重建。而架构师设计出来的软件系统,为了满足产品的业务发展,在它的整个生命周期中,每一个版本都有很多的变化。
    软件设计每一个版本都在变化,所以软件设计应该是渐进式发展。软件从一开始就不应该被设计成微服务架构,微服务架构固然有优势,但是它需要更多的资源,包括服务器资源、技术人员等。追去大公司所带来的技术解决方案,刻意地追求某个新技术,企图使用新技术解决所有的问题,这些都是软件设计的误区。
    技术应该是随着业务的发展而发展的,任何脱离业务的技术是不能产生价值的。在初创公司,业务很单一时,如果在LAMP单体架构够用的情况下,就应该用LAMP,因为它开发速度快,性价比高。随着业务的发展,用户量的增加,可以考虑将数据库读写分离、加缓存、加负载均衡器、将应用程序集群化部署等。如果业务还在不断发展,这时可以考虑使用分布式系统,例如微服务架构的系统。不管使用什么样的架构,驱动架构发展的一定是业务的发展,只有当前架构不适合当前业务的发展,才考虑更换架构。
    在微服务架构中,有三大难题,那就是服务故障的传播性、服务的划分和分布式事务。在微服务设计时,一定要考虑清楚这三个难题,从而选择合适的框架。目前比较流行的微服务框架有Spring社区的Spring Cloud、Google公司的Kubernetes等。不管使用哪一种框架或者工具,都需要考虑这三大难题。为了解决服务故障的传播性,一般的微服务框架都有熔断机制组件。另外,服务的划分没有具体的划分方法,一般来说根据业务来划分服务,领域驱动设计具有指导作用。最后,分布式事务一般的解决办法就是两阶段提交或者三阶段提交,不管使用哪一种都存在事务失败,导致数据不一致的情况,关键时刻还得人工去恢复数据。总之,微服务的设计一定是渐进式的,并且是随着业务的发展而发展的。

    转载于:https://www.cnblogs.com/love9527/p/9264257.html

    展开全文
  • 方志朋版——深入理解Spring Cloud与微服务构建,学习 Cloud可以看下,内容不太深
  • 《深入理解Spring Cloud与微服务构建》学习笔记(六)~SpringBoot 整合 Redis
  • 通过微服务构建易扩展云平台

    万次阅读 2020-08-27 14:50:24
    所有架构方案的提出都是根据应用场景进行优化的,想一下5年前,当时springmvc大行其道,使用ssm 构建应用基本上是当时开发界的标准。当时的数据量还没有进行服务拆分,所有服务构建在一个单体应 用中,所有服务

    当前各种云平台、开放平台满天飞,大到互联网巨头小到垂直行业头部有野心的企业,都会有搭建云平台的冲动。技术上也有各种高大上满天飞的,但是最终落地还是需要结合自身实际情况和业务需求,考虑性价比来执行。往往是从丰满到骨感,引无数大牛尽折腰。好了,不多说了,找个合适的给大家看看

    1、为什么要构建微服务
    所有架构方案的提出都是根据应用场景进行优化的,想一下5年前,当时springmvc大行其道,使用ssm 构建应用基本上是当时开发界的标准。当时的数据量还没有进行服务拆分,所有服务构建在一个单体应 用中,所有服务间调用是通过http请求实现的。

    但是这种方式构建的应用有几个最主要的缺点:
    1、当请求量和并发量上来后,服务扩展比较困难,单体应用可以实现集群化提供服务,但需要配置前 端代理服务器,如果并发量降下来后又要回收服务资源修改配置。
    2、所有服务共用一个后端数据库资源,这样数据库就成为了性能瓶颈。
    3、单体应用一旦挂掉,整个服务将不能提供应用,比如一个服务中提供了下单、浏览、注册服务,如 果所有接口构建在一个服务中,那么当出现问题时所有功能都不可用。

    以上只是列举了几个单体应用可能遇见的问题,微服务提出就可以解决以上出现的问题,将大的服务拆 分成多个小应用提供服务,每个服务单独使用各自的数据库资源,这样就实现了“不把鸡蛋放在一个篮 子里”,当某个服务宕机后,最多那个服务不可用,其他资源还可继续使用。

    2、微服务的优势与劣势
    微服务拆分最大程度上解耦了应用,但是也一样带来了服务的复杂度,比如要查询用户的订单信息,在 早期的架构方案中,这两个数据是存储在一起的,通过一个表关联查询出数据;但是在微服务下这样就 实现不了了,因为这两个数据是存储在不同位置,如果要查询这两个数据,需要到两个服务中分别取出 来然后再组装起来返回给客户。

    微服务优点:
    1、服务解耦:不同的服务拆分成不同的应用对外提供服务
    2、方便扩展:如果某个应用并发量很大,对单个应用进行扩容,当请求量将下来后再回收资源
    3、数据解耦:将不同的应用数据存储在不同的数据库中,这样就实现了数据的水平拆分

    微服务的缺点:
    1、增加了服务的复杂性,原来一个请求就能获取到的数据,微服务化后可能需要多次请求才能获取到 结果
    2、维护成本增加了,不同的应用需要不同的人员进行维护
    3、架构复杂,增加了问题排查和定位的难度

    3、docker容器化实现动态伸缩
    如果只是对服务进行拆分,并没有体现出微服务的优势,对于动态扩容和伸缩还是需要人员来参与,所 以云平台在构建的时候考虑到了这些,在服务拆分同时,使用的k8s进行服务治理,实现动态扩容和伸 缩,同时使用elk进行日志收集和分析,这种架构基本实现了我们的业务需求:
    1、服务和数据拆分,不同服务的数据存储在不同的数据库,对数据库进行水平扩展
    2、日志统一收集处理,排查和定位问题方便
    3、使用k8s进行服务编排和治理,可以实现资源动态伸缩,方便管理

    4、云平台整体架构
    云平台整体使用的springcloud构建微服务,微服务构建使用docker部署在k8s中,对外通过统一的
    nginx做请求转发,应用服务和数据存储之间使用redis缓存。

    在这里插入图片描述
    云平台参考地址http://cloud.kuaidi100.com/home

    展开全文
  • 《深入理解Spring Cloud与微服务构建》学习笔记(八)~服务注册和发现 Eureka,可以直接运行参考
  • 微服务构建易扩展云平台 1、为什么要构建微服务 所有架构方案的提出都是根据应用场景进行优化的,想一下5年前,当时springmvc大行其道,使用ssm 构建应用基本上是当时开发界的标准。当时的数据量还没有进行服务拆分...
  • 基于kubernetes和SpringCloud微服务构建方案
  • 微服务的一大特性就是独立发布,快速迭代,但前提是足够稳定,他们在使用微服务构建API的过程中就遇到很多问题: 1.客户(微服务使用方)经常反馈API 升级变更后不可用,有时影响范围不可控,导...
  • 第二章:微服务构建 Spring Boot
  • 《深入理解Spring Cloud与微服务构建》学习笔记(九)~Eureka集群配置,可以直接运行。
  • 《深入理解Spring Cloud与微服务构建》学习笔记(五)~SpringBoot 整合 JPA,直接运行参考
  • 深入理解 Spring Cloud 与微服务构建_读书笔记第16章 使用 Spring Cloud 构建微服务综合案例16.1 案例介绍16.2 案例详解16.3 启动源码工程16.4 项目演示16.5 总结 第16章 使用 Spring Cloud 构建微服务综合案例 16.1...
  • 《深入理解Spring Cloud与微服务构建》学习笔记(十六)~路由网关Spring Cloud Zuul
  • 近年来,微服务架构发展迅速,...微服务的一大特性就是独立发布,快速迭代,但前提是足够稳定,他们在使用微服务构建API的过程中就遇到很多问题:客户(微服务使用方)经常反馈 API 升级变更后不可用,有时影响范...
  • 《深入理解Spring Cloud与微服务构建》学习笔记(十一)~使用RestTemplate和Ribbo消费服务
  • 本文讲的是利用微服务构建现代应用(二),【编者的话】本文是如何用微服构建现代应用的第二部分,介绍了如何用MongoDB中实现微服务,在迁移到微服务之前需要考虑的问题以及使用MongoDB构建微服务架构的客户案例。...
  • 深入理解Spring Cloud与微服务构建 第2版

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 12,252
精华内容 4,900
关键字:

微服务构建