微服务架构模式解析 | 大魏学微服务系列第一篇

Posted 大魏分享

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了微服务架构模式解析 | 大魏学微服务系列第一篇相关的知识,希望对你有一定的参考价值。

前言


本文仅代表作者的个人观点;

本文的内容仅限于技术探讨,不能作为指导生产环境的素材;

本文素材是红帽公司产品技术和手册;

本文分为系列文章,将会有多篇,初步预计将会有26篇。



一、介绍微服务架构


微服务架构( Microservice Architecture MSA)环境的定义特征是:模块化服务是单独部署的、每个模块化服务可以独立于其他服务,或同一服务的其他实例进行替换。MSA与规模无关:每个微服务应遵循领域驱动设计技术(DDD:Domain-Driven Design),实现定义明确、高度凝聚的业务环境。


每个服务由一个自治团队作为独立单元开发和部署。每个团队都可以遵循不同的发布策略并使用不同的框架和运行时。


MSA的另一个定义特征是:分布式系统的固有复杂性从一开始就被考虑,而不是事后的想法。每个服务团队都需要考虑非功能性问题,例如网络可靠性、跟踪和监控。与旧的面向服务的体系结构(SOA)世界不同,MSA团队并不认为中心基础架构处理这些非功能性组件。


微服务架构通过容器化、云平台、持续集成/持续部署(CI / CD)和轻量级应用程序运行时(如WildFly Swarm,Vert.x和Node.js)实现。


许多模式已经成为实施MSA的推荐方法,其中包括:


  • 进程间通信

  • 服务发现

  • 容错:隔板和断路器

  • API网关

  • 分布式跟踪

  • 聚合日志记录

  • 安全



二、进程之间的通信


每个微服务作为一个独特的过程运行,通常作为一个独特的容器。 微服务使用标准的进程间通信(IPC)机制进行通信,该机制通常是以下之一:


  • REST over HTTP:同步的请求/响应

  • AMQP,MQTT:消息驱动的异步协议,可以实现发布/订阅,或者消息队列


微服务IPC机制是独立于运行时,因此使用不同框架实现的微服务可以透明地进行通信。 通常使用JSON编码来格式化消息。



三、服务发现



我们要实现一个服务的可扩展性,通常是给一个服务增加多个实例。这个时候,客户端的请求的时候,就需要有到应用的负载均衡。并且需要知道哪些实例是好的,哪些已经挂了。


许多库(如Netflix OSS Eureka、Ribbon)实现了服务发现模式,但它们通常仅适用于使用相同库的其他服务。这些库,都需要一个特殊的服务注册表,来跟踪每个微服务的可用实例。



在OpenShift集群外部运行的微服务可以使用路由进行通信,这提供了与服务相同的优点,并且与公共DNS主机名相关联。




四、容错


与容错相关的模式包括断路器circuit breaker 和bulkhead 。某些MSA库(如Netflix OSS Hystrix库)实现了这两种模式。


断路器circuit breaker 

当客户端调用过载或无响应的从属服务时,断路器可避免级联故障。断路器包装服务调用并监视所有调用以检测故障和超时。


当断路器检测到故障时,它会打开电路,因此不会对服务进行调用,直到发现它再次健康为止。同时,断路器可以提供后退响应,例如先前缓存的值,从而不会因为不健康的服务而停止客户端。


即使没有回退响应,对不健康的服务进行网络调用也会增加网络负载,从而影响不相关的服务,并可能迫使服务花费更长的时间来恢复。


bulkhead

bulkhead将服务依赖关系彼此隔离,并限制对每个服务的依赖性访问。隔离文件在信号量或线程池中包装服务调用,并且在获取信号量或池已满时,服务调用将排队。


Bulkhead还可以提供回退响应,而不是对呼叫进行排队,或者在队列长度高于阈值时提供回退响应。


五、API网关


MSA环境中的API网关不是策略实施或消息转换的机制,而是提供一个或多个HTTP API的自定义视图的分布式机制。 一个API网关是为特定的服务和客户端定制的,不同的应用程序通常使用不同的API网关。


使用API网关的一些使用场景包括:

  • 聚合来自许多服务的数据,以呈现基于Web浏览器的应用程序的统一视图。

  • 桥接不同的消息传输协议,例如HTTP和AMQP。

  • 公开旧版本的服务API,但将请求委托给同一服务的较新版本。

  • 使用不同的安全机制验证客户端。


有多种方法可以实现API网关,例如:自定义编码服务,与任何其他微服务没有什么不同,以及专用集成工具包,如Fuse Integration Services和Apache Camel。




六、分布式跟踪


对MSA环境的最终用户或客户端应用程序请求可以跨越多个服务。使用传统技术无法对此请求进行调试和分析,无法隔离单个进程来观察和排除故障。监视单个服务不会提示哪个发起请求引发了哪个调用。


分布式跟踪模式为每个请求分配唯一ID。此ID包含在所有相关服务调用中,并且这些服务在进行进一步的服务调用时也包含相同的ID。这样,就可以跟踪从始发请求到所有相关请求的调用图。


每个从属服务还会添加跨度ID,该ID应与先前服务请求的跨度ID有些相关。这样,可以在时间和空间上对来自相同始发请求的多个服务调用进行排序。


请注意,请求ID对于调用图中的所有服务都是相同的。调用图中的每个服务的跨度ID都不同。


应用程序记录请求和跨区ID,还可以提供其他数据,例如开始和停止时间戳以及相关业务数据。收集这些日志或将其发送到中央聚合器以进行存储和可视化。


分布式跟踪的一个流行标准是OpenTracing API,该标准的一个流行实现是Jaeger项目。



七、聚合日志记录 Aggregated Logging


大多数Java开发人员习惯使用标准API生成日志。传统应用程序依赖本地存储来保存这些日志,但是容器化应用程序是短暂的,因此当容器停止时,所有日志都会丢失。


许多组织为传统应用程序保留了集中的日志存储设这些集中式日志通常只记录安全和审计跟踪,应用程序日志保留在运行应用程序的本地服务器上。


借助云和容器平台,聚合应用程序日志已成为当务之急。如果没有聚合的应用程序日志,则没有用于对应用程序进


容器化应用程序应将所有日志事件发送到标准输出和错误流,容器引擎将收集它们。 OpenShift提供了一个日志记录子系统,它从所有集群节点中的容器引擎收集日志,并将它们存储在中央存储库中。 OpenShift日志记录子系统不仅支持检索,还支持日志上的自定义查询。


为了更好地利用OpenShift日志查询功能,应用程序应生成结构化日志,通常是JSON格式的消息,而不是纯文本行。最流行的Java日志框架支持结构化日志的自定义格式。



八、安全


维护身份和验证访问控制角色是分布式环境中的一项重要工作。

使用多种方法解决分布式身份和访问控制,例如:


  • 单点登录(SSO)系统

  • 分布式会话

  • 客户端令牌


所有这些方法,都需要中央身份验证和授权服务器来存储和验证用户凭据和访问角色。每个服务都需要为每个请求调用该中央服务器,这可能会成为单点故障,也是性能瓶颈。


客户端令牌解决方案,旨在通过基于公钥/私钥对生成加密签名的令牌,来减少这些问题。这些令牌可以转发到后续服务调用,并由每个从属服务验证,而无需访问中央认证服务器。每个令牌都有一个生存时间,以避免需要会话构造和向中央服务器发送注销请求。访问规则也嵌入到客户端令牌中,因此每个服务都可以自行做出授权决策。


OpenID Connect和JSON Web令牌(JWT)标准是客户端令牌的流行实现。基于Keycloak开源项目的OpenShift Master API和Red Hat Single Sign-on(RHSSO)产品都支持OpenID Connect和JWT。



九、使用Fabric8 Maven插件部署微服务


Fabric8 Maven插件用于在Kubernetes和OpenShift上构建和部署Java应用程序。


fabric8是一个开源集成开发平台,为基于Kubernetes和Jenkins的微服务提供持续发布。


功能特性

  • fabric8可以很方便地在笔记本上安装,也可以在现有的Kubernetes或OpenShift集群或者公有云上安装。

  • fabric8可以方便地创建微服务、构建、测试并且通过持续发布流水线发布,也能够通过持续改进和ChatOps运行和管理。

核心组件

  • Console:开发命令行可以帮助创建、构建和管理微服务,提供项目、app和环境的深度可视化。

  • Jenkins:利用Jenkins Pipelines和Functions功能实现持续集成和持续发布。

  • Nexus:为android Studio Canary提供代码仓库管理与推荐版本,与此同时还提供了Maven中央仓库镜像服务。

  • Gogs:内部git仓库托管。

  • JBoss:通过一组向导实现快速创建app和持续发布流水线。



该插件主要关注三个主要任务:

  • 构建容器图像

  • 创建OpenShift和Kubernetes资源

  • 在Kubernetes和OpenShift上部署应用程序


启用Fabric8 Maven插件

1.可以在POM文件的插件部分中启用Fabric8插件。 假设要在项目中启用插件的3.5.38版,请将以下内容添加到pom.xml文件中:


<plugin>
  <groupId>io.fabric8</groupId>
  <artifactId>fabric8-maven-plugin</artifactId>
  <version>3.5.38</version>
</plugin>

2.可以通过使用mvn命令运行插件的设置目标来启用插件:

mvn io.fabric8:fabric8-maven-plugin:3.5.38:setup

从pom.xml文件所在的项目文件夹的根目录运行该命令。 设置目标自动将必需的XML配置添加到pom.xml文件的plugins部分。


配置Fabric8 Maven插件

默认情况下,使用convention-over-configuration的方法。 这使得快速启动和运行变得容易。


例如,如果要部署基于WildFly Swarm的微服务(通常打包为Web存档WAR文件),则可以通过以下方式自定义项目的pom.xml文件:



1 声明插件应使用OpenShift imagestream tag,来标识用于构建容器图像的S2I构建容器镜像。


2 标识将用于构建容器图像的S2I构建器图像的图像流标记。在这种情况下,使用的是Red Hat Container Catalog中的官方OpenJDK 1.8映像。


使插件的发生器配置使用wildfly-swarm生成器而不是默认值。因为fabric8插件将项目归类为常规Web应用程序,因为打包类型设置为WAR,并尝试使用webapp生成器构建容器映像。


4 排除webapp生成器,并强制构建使用wildfly-swarm生成器。


5 Bind fabric8:resource和fabric8:为Maven的标准生命周期阶段构建目标。绑定这些目标使开发人员可以轻松地运行单个目标,即fabric8:deploy,它构建应用程序,生成OpenShift资源,构建容器映像,并一次性将应用程序部署到OpenShift集群。



将应用程序部署到OpenShift集群

fabric8 Maven插件提供了许多在OpenShift集群上构建和部署应用程序的目标。在运行其中一些目标之前,必须已登录到OpenShift集群。该插件在当前选定的OpenShift项目下创建资源。


fabric8:build

此目标构建应用程序的容器映像。插件会自动检测目标平台是否为OpenShift,并使用S2I方法构建映像。


对于OpenShift,插件使用二进制源构建方法构建容器图像。在此方法中,应用程序二进制文件在OpenShift集群外部构建,然后创建容器映像并将其流式传输到OpenShift集群中。


fabric8:resource

此目标生成Kubernetes和OpenShift资源描述符。可以运行此目标并检查生成的资源描述符文件,这些文件采用YAML格式。开发人员可以提供资源片段,这些片段是可以通过插件丰富的YAML模板文件(使用Enrichers)。必须在项目的src / main / fabric8目录中提供这些资源片段。


fabric8:apply

此目标将由fabric8:资源目标生成的生成资源文件应用于OpenShift集群。还可以运行fabric8:资源应用目标,该目标结合了资源生成并将其作为单个原子操作应用于群集。


fabric8:deploy

fabric8:deploy目标是运行fabric8的快捷方式:resource,fabric8:build和fabric8:按顺序应用目标。这会导致重建应用程序,创建新的容器映像,并使用单个命令将资源应用于OpenShift集群。





魏新宇

  • "大魏分享"运营者、红帽资深解决方案架构师

  • 专注开源云计算、容器及自动化运维在金融行业的推广

  • 拥有MBA、ITIL V3、Cobit5、C-STAR、TOGAF9.1(鉴定级)等管理认证。

  • 拥有红帽RHCE/RHCA、VMware VCP-DCV、VCP-DT、VCP-Network、VCP-Cloud、AIX、HPUX等技术认证。



以上是关于微服务架构模式解析 | 大魏学微服务系列第一篇的主要内容,如果未能解决你的问题,请参考以下文章

从零开始学微服务06.微服务架构的建设思路

从零开始学微服务06.微服务架构的建设思路

微服务架构实战160讲

从零开始学微服务08.引入微服务架构的时机

从零开始学微服务08.引入微服务架构的时机

学微服务之前,技术栈需要先分类