• 微服务操作模型


    这里并不是介绍微服务概念,如需要了解微服务,可以阅读Fowler-Microservices文章。本博客假定我们已开始使用微服务解耦单体应用,用来提升可部署性和可扩展性。

    当我们在系统范围内部署大量的微服务时,一个新的挑战产生了,单体应用部署时不会发生。这篇文章将针对这些新的挑战,在系统范围内部署大量微服务时定义一套操作模型(operations model)。

    这篇文章分为如下几个部分:

    1. 前提条件;
    2. 扩展;
    3. 问题;
    4. 需要的组件;
    5. 参考模型;
    6. 下一步;

    1. 前提条件

    当在系统范围内需要部署大量微服务时,需要什么条件呢?

    根据Flower的文章,如下是我们想要得到的:

     (Source:http://martinfowler.com/articles/microservices.html)

    然而,在开始发布大量微服务替换单体应用之前,我们需要实现如下这些前置条件:

    • 目标架构;
    • 持续交付工具;
    • 合适的组件结构;

    下面简要描述每一个前置条件。

    1.1   目标架构

    首先,我们需要分区微服务。例如,我们可以垂直分解微服务。

    • 核心服务(Core services)-处理业务数据的持久化和实施业务逻辑和其他规则;
    • 组合服务(Composite services)-组合服务指编排一组核心服务实现一个特定任务,或者从一组核心服务中聚合信息;
    • API services – 向外暴露功能,例如允许第三方使用底层功能创建新的应用;

    也可以水平上应用领域驱动分解。如下是一个目标架构:

    备注:这仅仅是一个范例目标架构,你可以使用完全不同的架构。核心时在开始部署微服务之前,需要有简历一个目标架构。否则,你最终的架构有可能像一团面条一样,甚至比现有的单体应用更加糟糕。

    1.2 持续交付

    我们假定已经有了一套可持续交付的发布工具,以便我们可以高效地反复发布微服务。

     

    (Source: http://www.infoq.com/minibooks/emag-devops-toolchain)

    1.3合适的组织

    最后,我们需要采用合适的组织结构,避免和Conway法则相冲突。Conway法则如下:

    Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

     

    (Source: http://martinfowler.com/articles/microservices.html)

    2. 扩展

    接下来是本文关注的要点:

    当我们分解单体应用,并使用大量的微服务替换时,在系统范围内会发生什么呢?

    (1)   大量的部署单元

    将产生需要的小的微服务,而不是之前的一个大的单体应用,这将需要管理和跟踪大量的部署单元。

    (2)   微服务将同时暴露和调用服务

    在系统范围内,大部分的微服务彼此是互相连接的。

    (3)   一些微服务暴露外部API

    这些微服务将负责包含其他的微服务不允许外部访问。

    (4)   系统根据动态

    新的微服务部署,替换老的服务。现有的微服务新增实例,满足增长的负荷。这意味着微服务将比以前更高的频率增加和下线。

    (5)   平均故障时间(MTBF)将下降

    在系统范围内,故障发生频率将更频繁。软件组件将不时发生问题。大量部署的微服务将比之前部署的单体应用出现问题的可能更高。

    3. 问题

    微服务模型将导致一些重要的运行时相关的问题:

    (1)   微服务如何配置以及是否正确?

    针对少量的应用程序,处理配置不是主要的问题,如使用配置文件或者在数据库中的配置表。在大量的微服务部署到大量的服务器上时,这一配置访问将变得非常复杂。这将导致大量的小的配置文件或者数据配置表遍布整个系统,使得难以高效可靠地维护。

    (2)   什么微服务部署了,部署在哪里了?

    在只有少量服务部署时,管理部署的主机和端口还是比较简单的。但是当有大量的微服务部署时,这些服务或多或少需要持续变更,如手工维护将变得非常麻烦。

    (3)   如何维护路由信息?

    在动态系统范围中,服务消费方也是一个挑战。尤其是路由表或者消费配置文件,需要手工更新。在微服务不断新增新的主机/端口时,将没有时间手工维护。交付时间将会延长,并且手工维护出错的风险也会增加。

    (4)   如何防止失败链?

    由于微服务之间是相互连接的,需要关注系统范围内的失败链。例如,一个被其他众多微服务依赖的微服务失败了,其他依赖的微服务也可能开始失败。如果没有合适处理,大量微服务将受到这个单一失败的微服务所影响,导致一个脆弱的系统。

    (5)   如何验证所有的微服务已上线且在运行中?

    跟踪少量应用的运行状态是比较简单的,但是如何验证所有的微服务是健康的,且准备好接收请求?

    (6)   如何跟踪服务之间的消息?

    如何应对组织开始接到关于一些流程执行失败?什么微服务到导致这一问题的根本原因?例如,订单12345卡住了,我们如何知道是因为微服务A无法访问,还是因为微服务B在发送一个订单确认消息之前,需要手工批准。

    (7)   如何确保仅仅API服务暴露给外部?

    例如我们如何避免外部未授权的请求,对内部微服务的访问?

    (8)   如何保证API服务的安全?

    这不是针对微服务的特定问题,但是保护对外暴露的微服务仍然是非常重要的。

    4. 需要的组件

    为了解决上述的一些问题,新的操作和管理功能是必须的。针对上述问题,建议的解决方案包括如下组件:

    (1)   中心配置服务Central Configuration Server

    我们需要一个中心配置管理,而不是针对每一个部署单元(微服务)有一个本地配置。此外,我们还需一个配置API,微服务用来获取配置信息。

    (2)   服务发现服务 Service Discovery Server

    我们需要服务发现功能,微服务在启动时,通过API自己注册,而不是手工跟踪微服务部署的主机和端口。

    (3)   动态路由和负载均衡 Dynamic Routing and Load Balancer

    基于服务发现功能,路由组件使用discovery API 查询请求的微服务部署在哪里;在被请求的服务部署了多个实例的情况下,负载均衡组件可以决定路由请求到特定的实例。

    (4)   电路断路器 Circuit Breaker

    为了避免失败链问题,我们需要营养Circuit Breaker模式,详细信息可以参考 Fowler-Circuit Breaker的文章。

    (5)   监控 Monitoring

    基于电路断路器,我们可以监控微服务的状态,同时收集运行时统计数据,获知服务的健康状态和当前使用率。这些信息可以收集并显示在dashboard上,并针对配置阈值设置自动报警。

    (6)   中心日志分析 Centralized Log Analysis

    为了跟踪消息,并检测微服务何时故障,我们需要一个中心日志分析功能,可以访问服务器并收集每一个微服务的log文件。日志分析功能保存log信息在中心数据库中,并提供了查询和dashboard功能。备注:为了查找相关的消息,所有微服务需要在log消息中使用相关的id,这点很重要。

    (7)   边缘服务 Edge Server

    为了对外部暴露API 服务,并阻止对内部微服务的未授权访问,我们需要一个边缘服务(Edge Server),所有外部的访问都经过边缘服务器。基于前面的服务发现组件,边缘服务器可以重用动态路由和负载均衡功能。边缘服务器作为一个动态和有效的反向代理,在内部系统更新时,不必手动更新。

    (8)   OAuth 2.0保护的API

    建议OAuth 2.0 标准保护暴露的API服务。应用OAuth 2.0 有如下效果:

    1/一个新组建作为OAuth Authorization Server;

    2/API服务作为OAuth Resource Server;

    3/外部API消费方作为OAuth Clients;

    4/边缘服务器(Edge Server)作为OAuth Token Relay;

    (4.1)作为OAuth Resource Server;

    (4.2)将外部请求中的OAuth Access Tokens传递给API 服务;

    备注:OAuth 2.0 标准可能通过OpenID Connect标准来补充完善,提供更好的授权功能。

    5. 参考模型

    总而言之,微服务需要一套包含上述支持服务的基础设施,微服务使用它们的API来交互。下图描绘了这一基础设施:

     

    备注:为了减少上图中交互的复杂度,微服务和支持服务的交互并没有画出来。

    6. 下一步

    在接下来的文章中,我们将描述和演示如何实现上述建议的参考模型。

    英文原文链接:

    An operations model for Microservices

  • 相关阅读:
    算法>分支限界 小强斋
    C# DataGridView 的 CellValueChanged 与修改数据没保存的情况
    Windows8使用虚拟磁盘vhdx功能来为容量较大的文件夹扩容
    DataSet / DataTable 对 Access 数据库进行更改后,无法获取自动编号(自增)列的新值
    使用Windows Server 2012配置更新服务Update Service,以及客户端的配置
    在Windows 8中找回开始菜单
    DataSet / BindingSource / DataGridView / BindingNavigator 的关系与绑定、更新顺序
    Windows8 的搜狗输入法的快捷键推荐设置方法
    如果要使用DataAdapter来修改DataSet的子集时,请尽量对父级做修改。
    about PostgreSQL
  • 原文地址:https://www.cnblogs.com/rickie/p/6538158.html
Copyright © 2020-2023  润新知