赞
踩
微服务,又称微服务 架 构,是一种架构风格,它将应用程序构建为以业务领域为模型的小型自治服务集合 。
通俗地说,你必须看到蜜蜂如何通过对齐六角形蜡细胞来构建它们的蜂窝状物。他们最初从使用各种材料的小部分开始,并继续从中构建一个大型蜂箱。这些细胞形成图案,产生坚固的结构,将蜂窝的特定部分固定在一起。这里,每个细胞独立于另一个细胞,但它也与其他细胞相关。这意味着对一个细胞的损害不会损害其他细胞,因此,蜜蜂可以在不影响完整蜂箱的情况下重建这些细胞。
图 1:微服务的蜂窝表示 – 微服务访谈问题
请参考上图。这里,每个六边形形状代表单独的服务组件。与蜜蜂的工作类似,每个敏捷团队都使用可用的框架和所选的技术堆栈构建单独的服务组件。就像在蜂箱中一样,每个服务组件形成一个强大的微服务架构,以提供更好的可扩展性。此外,敏捷团队可以单独处理每个服务组件的问题,而对整个应用程序没有影响或影响最小。
图 2:微服务的 优点 – 微服务访谈问题
· 独立开发 – 所有微服务都可以根据各自的功能轻松开发
· 独立部署 – 基于其服务,可以在任何应用程序中单独部署它们
· 故障隔离 – 即使应用程序的一项服务不起作用,系统仍可继续运行
· 混合技术堆栈 – 可以使用不同的语言和技术来构建同一应用程序的不同服务
· 粒度缩放 – 单个组件可根据需要进行缩放,无需将所有组件缩放在一起
图 3:微服务的 特点 – 微服务访谈问题
· 解耦 – 系统内的服务很大程度上是分离的。因此,整个应用程序可以轻松构建,更改和扩展
· 组件化 – 微服务被视为可以轻松更换和升级的独立组件
· 业务能力 – 微服务非常简单,专注于单一功能
· 自治 – 开发人员和团队可以彼此独立工作,从而提高速度
· 持续交付 – 通过软件创建,测试和批准的系统自动化,允许频繁发布软件
· 责任 – 微服务不关注应用程序作为项目。相反,他们将应用程序视为他们负责的产品
· 分散治理 – 重点是使用正确的工具来做正确的工作。这意味着没有标准化模式或任何技术模式。开发人员可以自由选择最有用的工具来解决他们的问题
· 敏捷 – 微服务支持敏捷开发。任何新功能都可以快速开发并再次丢弃
以下是设计微服务的最佳实践:
图 4:设计微服务的最佳实践 – 微服务访谈问题
微服务架构具有以下组件:
图 5:微服务 架构 – 微服务面试问题
· 客户端 – 来自不同设备的不同用户发送请求。
· 身份提供商 – 验证用户或客户身份并颁发安全令牌。
· API 网关 – 处理客户端请求。
· 静态内容 – 容纳系统的所有内容。
· 管理 – 在节点上平衡服务并识别故障。
· 服务发现 – 查找微服务之间通信路径的指南。
· 内容交付网络 – 代理服务器及其数据中心的分布式网络。
· 远程服务 – 启用驻留在 IT 设备网络上的远程访问信息。
图 6: 单片 SOA 和微服务之间的比较 – 微服务访谈问题
· 单片架构类似于大容器,其中应用程序的所有软件组件组装在一起并紧密封装。
· 一个面向服务的架构是一种相互通信服务的集合。通信可以涉及简单的数据传递,也可以涉及两个或多个协调某些活动的服务。
· 微服务架构是一种架构风格,它将应用程序构建为以业务域为模型的小型自治服务集合。
开发一些较小的微服务听起来很容易,但开发它们时经常遇到的挑战如下。
· 自动化组件:难以自动化,因为有许多较小的组件。因此,对于每个组件,我们必须遵循 Build,Deploy 和 Monitor 的各个阶段。
· 易感性:将大量组件维护在一起变得难以部署,维护,监控和识别问题。它需要在所有组件周围具有很好的感知能力。
· 配置管理:有时在各种环境中维护组件的配置变得困难。
· 调试:很难找到错误的每一项服务。维护集中式日志记录和仪表板以调试问题至关重要。
SOA 和微服务之间的主要区别如下:
您可以列出微服务的特征,如下所示:
图 7:微服务的特征 – 微服务访谈问题
图 8: DDD 原理 – 微服务面试问题
图 9:我们需要 DDD 的因素 – 微服务面试问题
如果您必须定义泛在语言(UL),那么它是特定域的开发人员和用户使用的通用语言,通过该语言可以轻松解释域。
无处不在的语言必须非常清晰,以便它将所有团队成员放在同一页面上,并以机器可以理解的方式进行翻译。
模块内部元素所属的程度被认为是凝聚力。
组件之间依赖关系强度的度量被认为是耦合。一个好的设计总是被认为具有高内聚力和低耦合性。
Representational State Transfer(REST)/ RESTful Web 服务是一种帮助计算机系统通过 Internet 进行通信的架构风格。这使得微服务更容易理解和实现。
微服务可以使用或不使用 RESTful API 实现,但使用 RESTful API 构建松散耦合的微服务总是更容易。
事实上,随着新功能的增加,弹簧变得越来越复杂。如果必须启动新的 spring 项目,则必须添加构建路径或添加 maven 依赖项,配置应用程序服务器,添加 spring配置。所以一切都必须从头开始。
Spring Boot 是解决这个问题的方法。使用 spring boot 可以避免所有样板代码和配置。因此,基本上认为自己就好像你正在烘烤蛋糕一样,春天就像制作蛋糕所需的成分一样,弹簧靴就是你手中的完整蛋糕。
图 10: Spring Boot 的因素 – 微服务面试问题
Spring Boot 执行程序提供了 restful Web 服务,以访问生产环境中运行应用程序的当前状态。在执行器的帮助下,您可以检查各种指标并监控您的应用程序。
根据 Spring Cloud 的官方网站,Spring Cloud 为开发人员提供了快速构建分布式系统中一些常见模式的工具(例如配置管理,服务发现,断路器,智能路由,领导选举,分布式会话,集群状态)。
在使用 Spring Boot 开发分布式微服务时,我们面临的问题很少由 Spring Cloud解决。
· 与分布式系统相关的复杂性 – 包括网络问题,延迟开销,带宽问题,安全问题。
· 处理服务发现的能力 – 服务发现允许集群中的进程和服务找到彼此并进行通信。
· 解决冗余问题 – 冗余问题经常发生在分布式系统中。
· 负载平衡 – 改进跨多个计算资源(例如计算机集群,网络链接,中央处理单元)的工作负载分布。
· 减少性能问题 – 减少因各种操作开销导致的性能问题。
在测试目标只关注 Spring MVC 组件的情况下,WebMvcTest 注释用于单元测试Spring MVC 应用程序。在上面显示的快照中,我们只想启动 ToTestController。执行此单元测试时,不会启动所有其他控制器和映射。
虽然您可以通过多种方式实现微服务,但 REST over HTTP 是实现微服务的一种方式。REST 还可用于其他应用程序,如 Web 应用程序,API 设计和 MVC 应用程序,以提供业务数据。
微服务是一种体系结构,其中系统的所有组件都被放入单独的组件中,这些组件可以单独构建,部署和扩展。微服务的某些原则和最佳实践有助于构建弹性应用程序。
简而言之,您可以说 REST 是构建微服务的媒介。
在使用微服务时,由于有多个微服务协同工作,测试变得非常复杂。因此,测试分为不同的级别。
· 在底层,我们有面向技术的测试,如单元测试和性能测试。这些是完全自动化的。
· 在中间层面,我们进行了诸如压力测试和可用性测试之类的探索性测试。
· 在顶层, 我们的 验收测试数量很少。这些验收测试有助于利益相关者理解和验证软件功能。
分布式事务是指单个事件导致两个或多个不能以原子方式提交的单独数据源的突变的任何情况。在微服务的世界中,它变得更加复杂,因为每个服务都是一个工作单元,并且大多数时候多个服务必须协同工作才能使业务成功。
幂等性是能够以这样的方式做两次事情的特性,即最终结果将保持不变,即好像它只做了一次。
用法:在远程服务或数据源中使用 Idempotence,这样当它多次接收指令时,它只处理指令一次。
有界上下文是域驱动设计的核心模式。DDD 战略设计部门的重点是处理大型模型和团队。DDD 通过将大型模型划分为不同的有界上下文并明确其相互关系来处理大型模型。
双因素身份验证为帐户登录过程启用第二级身份验证。
图 11: 双因素认证的表示 – 微服务访谈问题
因此,假设用户必须只输入用户名和密码,那么这被认为是单因素身份验证。
这三种凭证是:
图 12: 双因素认证的证书类型 – 微服务面试问题
客户端系统用于向远程服务器发出经过身份验证的请求的一种数字证书称为客户端证书。客户端证书在许多相互认证设计中起着非常重要的作用,为请求者的身份提供了强有力的保证。
PACT 是一个开源工具,允许测试服务提供者和消费者之间的交互,与合同隔离,从而提高微服务集成的可靠性。
微服务中的用法
· 用于在微服务中实现消费者驱动的合同。
· 测试微服务的消费者和提供者之间的消费者驱动的合同。
查看即将到来的批次
OAuth 代表开放授权协议。这允许通过在 HTTP 服务上启用客户端应用程序(例如第三方提供商 Facebook,GitHub 等)来访问资源所有者的资源。因此,您可以在不使用其凭据的情况下与另一个站点共享存储在一个站点上的资源。
“任 何 设 计 系 统 的 组 织 ( 广 泛 定 义 ) 都 将 产 生 一 种 设 计 , 其 结 构 是 组 织 通 信 结 构的 副 本 。” – Mel Conway
图 13: Conway 定律的表示 – 微服务访谈问题
该法律基本上试图传达这样一个事实:为了使软件模块起作用,整个团队应该进行良好的沟通。因此,系统的结构反映了产生它的组织的社会边界。
根据 Martin Flower 的说法,合同测试是在外部服务边界进行的测试,用于验证其是否符合消费服务预期的合同。
此外,合同测试不会深入测试服务的行为。更确切地说,它测试该服务调用的输入&输出包含所需的属性和所述响应延迟,吞吐量是允许的限度内。
端到端测试验证了工作流中的每个流程都正常运行。这可确保系统作为一个整体协同工作并满足所有要求。
通俗地说,你可以说端到端测试是一种测试,在特定时期后测试所有东西。
图 14:测试层次 – 微服务面试问题
容器是管理基于微服务的应用程序以便单独开发和部署它们的好方法。您可以将微服务封装在容器映像及其依赖项中,然后可以使用它来滚动按需实例的微服务,而无需任何额外的工作。
图 15: 容器的表示及其在微服务中的使用方式 – 微服务访谈问题
DRY 代表不要重复自己。它基本上促进了重用代码的概念。这导致开发和共享库,这反过来导致紧密耦合。
这基本上是用于开发微服务的模式,以便它们可以被外部系统使用。当我们处理微服务时,有一个特定的提供者构建它,并且有一个或多个使用微服务的消费者。
通常,提供程序在 XML 文档中指定接口。但在消费者驱动的合同中,每个服务消费者都传达了提供商期望的接口。
微服务架构基于一个概念,其中所有服务应该能够彼此交互以构建业务功能。因此,要实现这一点,每个微服务必须具有接口。这使得 Web API 成为微服务的一个非常重要的推动者。RESTful API 基于 Web 的开放网络原则,为构建微服务架构的各个组件之间的接口提供了最合理的模型。
语义监控,也称为 综合监控, 将自动化测试与监控应用程序相结合,以检测业务失败因素。
跨功能测试是对非功能性需求的验证,即那些无法像普通功能那样实现的需求。
非确定性测试(NDT)基本上是不可靠的测试。所以,有时可能会发生它们通过,显然有时它们也可能会失败。当它们失败时,它们会重新运行通过。
从测试中删除非确定性的一些方法如下:
1、 隔离
2、 异步
3、 远程服务
4、 隔离
5、 时间
6、 资源泄漏
存根
· 一个有助于运行测试的虚拟对象。
· 在某些可以硬编码的条件下提供固定行为。
· 永远不会测试存根的任何其他行为。
例如,对于空堆栈,您可以创建一个只为 empty()方法 返回 true 的存根。因此,这并不关心堆栈中是否存在元素。
嘲笑
· 一个虚拟对象,其中最初设置了某些属性。
· 此对象的行为取决于 set 属性。
· 也可以测试对象的行为。
例如,对于 Customer 对象,您可以通过设置名称和年龄来模拟它。您可以将 age设置为 12,然后测试 isAdult()方法,该方法将在年龄大于 18 时返回 true。因此,您的 Mock Customer 对象适用于指定的条件。
Mike Cohn 提供了一个名为 Test Pyramid 的模型。这描述了软件开发所需的自动化测试类型。
图 16: Mike Cohn 的测试金字塔 – 微服务面试问题
根据金字塔,第一层的测试数量应该最高。在服务层,测试次数应小于单元测试级别,但应大于端到端级别。
Docker 提供了一个可用于托管任何应用程序的容器环境。在此,软件应用程序和支持它的依赖项紧密打包在一起。
因此,这个打包的产品被称为 Container,因为它是由 Docker 完成的,所以它被称为 Docker 容器!
Canary Releasing 是一种降低在生产中引入新软件版本的风险的技术。这是通过将变更缓慢地推广到一小部分用户,然后将其发布到整个基础架构,即将其提供给每个人来完成的。
持续集成(CI)是每次团队成员提交版本控制更改时自动构建和测试代码的过程。这鼓励开发人员通过在每个小任务完成后将更改合并到共享版本控制存储库来共享代码和单元测试。
持续监控深入监控覆盖范围,从浏览器内前端性能指标,到应用程序性能,再到主机虚拟化基础架构指标。
微服务架构中的架构师扮演以下角色:
· 决定整个软件系统的布局。
· 帮助确定组件的分区。因此,他们确保组件相互粘合,但不紧密耦合。
· 与开发人员共同编写代码,了解日常生活中面临的挑战。
· 为开发微服务的团队提供某些工具和技术的建议。
· 提供技术治理,以便技术开发团队遵循微服务原则。
我们知道拥有自己的数据库的每个微服务都是一个可独立部署的程序单元,这反过来又让我们可以创建一个状态机。因此,我们可以为特定的微服务指定不同的状态和事件。
例如,我们可以定义 Order 微服务。订单可以具有不同的状态。Order 状态的转换可以是 Order 微服务中的独立事件。
Reactive Extensions 也称为 Rx。这是一种设计方法,我们通过调用多个服务来收集结果,然后编译组合响应。这些调用可以是同步或异步,阻塞或非阻塞。Rx是分布式系统中非常流行的工具,与传统流程相反。
Spring cloud 流应用程序启动器是基于 Spring Boot 的 Spring 集成应用程序,提供与外部系统的集成。Spring cloud Task,一个生命周期短暂的微服务框架,用于快速构建执行有限数据处理的应用程序。
使用 Spring Boot 开发分布式微服务时,我们面临以下问题
(1)与分布式系统相关的复杂性-这种开销包括网络问题,延迟开销,带宽问题,安全问题。
(2)服务发现-服务发现工具管理群集中的流程和服务如何查找和互相交谈。它涉及一个服务目录,在该目录中注册服务,然后能够查找并连接到该目录中的服务。
(3)冗余-分布式系统中的冗余问题。
(4)负载平衡 --负载平衡改善跨多个计算资源的工作负荷,诸如计算机,计算机集群,网络链路,中央处理单元,或磁盘驱动器的分布。
(5)性能-问题 由于各种运营开销导致的性能问题。
(6)部署复杂性-Devops 技能的要求。
当我们开始一个项目时,我们通常在属性文件中进行所有的配置。随着越来越多的服务开发和部署,添加和修改这些属性变得更加复杂。有些服务可能会下降,而某些位置可能会发生变化。手动更改属性可能会产生问题。 Eureka 服务注册和发现可以在这种情况下提供帮助。由于所有服务都在 Eureka 服务器上注册并通过调用 Eureka 服务器完成查找,因此无需处理服务地点的任何更改和处理。
(1)服务调用方式 dubbo是RPC springcloud Rest Api
(2)注册中心,dubbo 是zookeeper springcloud是eureka,也可以是zookeeper
(3)服务网关,dubbo本身没有实现,只能通过其他第三方技术整合,springcloud有Zuul路由网关,作为路由服务器,进行消费者的请求分发,springcloud支持断路器,与git完美集成配置文件支持版本控制,事物总线实现配置文件的更新与服务自动装配等等一系列的微服务架构要素。
SpringBoot专注于快速方便的开发单个个体微服务。
SpringCloud是关注全局的微服务协调整理治理框架,它将SpringBoot开发的一个个单体微服务整合并管理起来,
为各个微服务之间提供,配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等集成服务
SpringBoot可以离开SpringCloud独立使用开发项目, 但是SpringCloud离不开SpringBoot ,属于依赖的关系.
SpringBoot专注于快速、方便的开发单个微服务个体,SpringCloud关注全局的服务治理框架。
在计算中,负载平衡可以改善跨计算机,计算机集群,网络链接,中央处理单元或磁盘驱动器等多种计算资源的工作负载分布。负载平衡旨在优化资源使用,最大化吞吐量,最小化响应时间并避免任何单一资源的过载。使用多个组件进行负载平衡而不是单个组件可能会通过冗余来提高可靠性和可用性。负载平衡通常涉及专用软件或硬件,例如多层交换机或域名系统服务器进程。
Hystrix 是一个延迟和容错库,旨在隔离远程系统,服务和第三方库的访问点,当出现故障是不可避免的故障时,停止级联故障并在复杂的分布式系统中实现弹性。
通常对于使用微服务架构开发的系统,涉及到许多微服务。这些微服务彼此协作。
思考以下微服务
假设如果上图中的微服务 9 失败了,那么使用传统方法我们将传播一个异常。但这仍然会导致整个系统崩溃。
随着微服务数量的增加,这个问题变得更加复杂。微服务的数量可以高达 1000.这是 hystrix 出现的地方 我们将使用 Hystrix 在这种情况下的 Fallback 方法功能。我们有两个服务 employee-consumer 使用由 employee-consumer 公开的服务。
简化图如下所示
现在假设由于某种原因,employee-producer 公开的服务会抛出异常。我们在这种情况下使用 Hystrix 定义了一个回退方法。这种后备方法应该具有与公开服务相同的返回类型。如果暴露服务中出现异常,则回退方法将返回一些值。
由于某些原因,employee-consumer 公开服务会引发异常。在这种情况下使用Hystrix 我们定义了一个回退方法。如果在公开服务中发生异常,则回退方法返回一些默认值。
如果 firstPage method() 中的异常继续发生,则 Hystrix 电路将中断,并且员工使用者将一起跳过 firtsPage 方法,并直接调用回退方法。 断路器的目的是给第一页方法或第一页方法可能调用的其他方法留出时间,并导致异常恢复。可能发生的情况是,在负载较小的情况下,导致异常的问题有更好的恢复机会 。
Feign 是受到 Retrofit,JAXRS-2.0 和 WebSocket 启发的 java 客户端联编程序。
Feign 的第一个目标是将约束分母的复杂性统一到 http apis,而不考虑其稳定性。
在 employee-consumer 的例子中,我们使用了 employee-producer 使用 REST模板公开的 REST 服务。
但是我们必须编写大量代码才能执行以下步骤
(1)使用功能区进行负载平衡。
(2)获取服务实例,然后获取基本 URL。
(3)利用 REST 模板来使用服务。 前面的代码如下
- @Controller
- public class ConsumerControllerClient {
- @Autowired
- private LoadBalancerClient loadBalancer;
- public void getEmployee() throws RestClientException, IOException {
- ServiceInstance serviceInstance=loadBalancer.choose("employee-producer");
- System.out.println(serviceInstance.getUri());
- String baseUrl=serviceInstance.getUri().toString();
- baseUrl=baseUrl+"/employee";
- RestTemplate restTemplate = new RestTemplate();
- ResponseEntity<String> response=null;
- try{
- response=restTemplate.exchange(baseUrl,
- HttpMethod.GET, getHeaders(),String.class);
- }
- catch (Exception ex)
- {
- System.out.println(ex);
- }
- System.out.println(response.getBody());
- }
之前的代码,有像 NullPointer 这样的例外的机会,并不是最优的。我们将看到如何使用 Netflix Feign 使呼叫变得更加轻松和清洁。如果 Netflix Ribbon 依赖关系也在类路径中,那么 Feign 默认也会负责负载平衡。
考虑以下情况:我们有多个应用程序使用 Spring Cloud Config 读取属性,而Spring Cloud Config 从 GIT 读取这些属性。
下面的例子中多个员工生产者模块从 Employee Config Module 获取 Eureka 注册的财产。
如果假设 GIT 中的 Eureka 注册属性更改为指向另一台 Eureka 服务器,会发生什么情况。在这种情况下,我们将不得不重新启动服务以获取更新的属性。
还有另一种使用执行器端点/刷新的方式。但是我们将不得不为每个模块单独调用这个 url。例如,如果 Employee Producer1 部署在端口 8080 上,则调用 http:// localhost:8080 / refresh。同样对于 Employee Producer2 http://localhost:8081 / refresh 等等。这又很麻烦。这就是 Spring Cloud Bus 发挥作用的地方。
Spring Cloud Bus 提供了跨多个实例刷新配置的功能。因此,在上面的示例中,如果我们刷新 Employee Producer1,则会自动刷新所有其他必需的模块。如果我们有多个微服务启动并运行,这特别有用。这是通过将所有微服务连接到单个消息代理来实现的。无论何时刷新实例,此事件都会订阅到侦听此代理的所有微服务,并且它们也会刷新。可以通过使用端点/总线/刷新来实现对任何单个实例的刷新。
当一个服务调用另一个服务由于网络原因或自身原因出现问题,调用者就会等待被调用者的响应 当更多的服务请求到这些资源导致更多的请求等待,发生连锁效应(雪崩效应)
断路器有完全打开状态:一段时间内 达到一定的次数无法调用 并且多次监测没有恢复的迹象 断路器完全打开 那么下次请求就不会请求到该服务
半开:短时间内 有恢复迹象 断路器会将部分请求发给该服务,正常调用时 断路器关闭
关闭:当服务一直处于正常状态 能正常调用
在分布式系统中,由于服务数量巨多,为了方便服务配置文件统一管理,实时更新,所以需要分布式配置中心组件。在Spring Cloud中,有分布式配置中心组件spring cloud config ,它支持配置服务放在配置服务的内存中(即本地),也支持放在远程Git仓库中。在spring cloud config 组件中,分两个角色,一是config server,二是config client。
使用:
(1)添加pom依赖
(2)配置文件添加相关配置
(3)启动类添加注解@EnableConfigServer
Spring Cloud Gateway是Spring Cloud官方推出的第二代网关框架,取代Zuul网关。网关作为流量的,在微服务系统中有着非常作用,网关常见的功能有路由转发、权限校验、限流控制等作用。
使用了一个RouteLocatorBuilder的bean去创建路由,除了创建路由RouteLocatorBuilder可以让你添加各种predicates和filters,predicates断言的意思,顾名思义就是根据具体的请求的规则,由具体的route去处理,filters是各种过滤器,用来对请求做各种判断和修改。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。