中国4200万家企业需要精益生产;全球70亿人都需要精益思维;
学精益,就上环球精益网
  • 精益管理名词解释大全
    栏目分类
    热门仓库管理文章推荐

    主页 > 仓库管理 > INTRODUCE

    盘点管理微服务的工具

    2020-05-16 17:27 作者:洛逸 来源: 浏览: 我要评论 (条) 字号:

    摘要:到2018年,微服务架构(面向服务架构的变体)已成为开发任何软件应用程序的首选,这不再是个空话了,对于许多企业来说已经是今天的现实。我们非常清楚微服务架构背后的驱动力,如强大的敏捷性,团队自治,每个服务都有自己的数据库等优势。 我从头开始设计微

    到2018年,微服务架构(面向服务架构的变体)已成为开发任何软件应用程序的首选,这不再是个空话了,对于许多企业来说已经是今天的现实。我们非常清楚微服务架构背后的驱动力,如强大的敏捷性,团队自治,每个服务都有自己的数据库等优势。


    我从头开始设计微服务架构,并将巨大的单体架构迁移到微服务架构。


    在过去的几年里,我亲眼目睹了微服务技术栈的发展历程。我评估了Netflix OSS,Spring Cloud和Java的本地微服务栈。诚然,这个世界现已由Kubernetes主导。


    实际上,Kubernetes并没有针对微服务进行概念化。然而,该领域的发展方式使Kubernetes生态系统为微服务提供了一个全面且完整的平台。在过去的几年中,已经为微服务建立了最先进的技术:由Kubernetes,Docker,Kafka,REST JSON,GRPC 协议缓冲区以及Golang等组成。


    我们处于基础设施时代混合代码,迈向使基础设施完全自治的一步。所以我们用Docker来打包应用程序。当你有数百个微服务或容器时,还需要编排引擎,比如使用K8s。


    我们只需要向Kubernetes提供所需的状态,并保证为你管理其余的状态,接着用Kafka来管理微服务之间的异步通信。在许多产品中,核心API和产品API之间存在明显的界限。GRPC加协议缓冲区的组合通常用于核心API,REST和JSON的事实标准通常用于产品API。


    即使这个微服务栈现在已成为常态,但现实还缺少一些东西。当你从单体架构迁移到微服务时,事情不会保持不变。在微服务领域,团队的组织和沟通结构会影响系统的设计,当你真正开始实现这些体系结构时,很快就会发现你在分布式系统中处于领先地位。


    分布式系统看上去很酷。然而它们也很糟糕:当你有数百个微服务时,那相当于有了一个蜘蛛网式的网络。


    设计单体和微服务的思维过程不那么相同,不再是经典的n层系统,这就是为什么必须提前准备解决微服务架构中出现的问题的原因。这些横切关注点直接影响系统的NFR。


    那么,这些问题都有哪些?我们梳理一下。


    你需要一个存储配置文件和机密的位置,即加密文件,这是K8s的配置映射和Secret。当您有托管多个单个微服务实例的不同节点时,需要进行服务发现。这由K8s提供的服务与入口完成的,在服务发现之后,接着是负载均衡,这也是由K8s服务和入口完成的。


    微服务世界的一个关键方面是跟踪监控,提供系统的整体视图。集中日志记录可帮助人们将日志存储在中央位置。在架构计划中,它由EFK完成,即Elastic,FluentD和Kibana组成。集中式日志记录与分布式跟踪协同工作。在微服务领域,特定的API请求可以由数十或数百个微服务处理,


    另一个重要方面是收集指标,监控微服务和Kubernetes集群的状态。这是由三个产品:Heapster,Prometheus和Grafana完成的,然后是架构弹性和容错。在如今的架构时代,这是系统架构的核心。在K8s中,它由Kubernetes服务和健康检查功能完成。


    最后,我们还要必须处理扩展自己的微服务,即pods。为此你要有HPA - 水平pod自动缩放器,用来根据不同的策略扩展自己的微服务实例。


    在某些情况下,你可能需要扩展到K8s集群之外,因此有CA-Cluster自动缩放器。在整体结构的情况下,你必须要注意的是它们比微服务要小得多。在开始微服务架构的设计之前,需要提前考虑这些因素。


    因此,我们已经找到了一套解决交叉问题的组件。如何安装这些不同的组件,使用Helm图表,可以自动安装,但那么这些组件的维护和必要升级又如何做呢?


    组件管理确实是一种负担。除了这些问题之外,如何更改解决特定微服务问题的组件呢?例如希望将EFK堆栈替换为其他工具或Grafana替换为其他工具。如果有这些组件,那么必须管理这些全部内容。


    问题还没有结束。还有许多事情需要解决。


    请求路由,服务可视化,速率限制(传入和传出),认证,故障管理和故障注入,熔断,滚动升级,遥测等。有了这些背景,我们才能意识到什么问题。


    人们开始使用ZooKeeper,它在一定程度上解决了这些问题。我们现在还有服务网格,它可以解决所有问题。我评估了不同的服务网格,如Istio,Consul,Conduit,Linkerd,最后我用Istio把这些问题解决掉了。


    Istio于2017年由谷歌推出。在2018年,它已经相当稳定。lstio由Google,IBM,Lyft,Pivotal,思科和Red Hat共同参与其中。


    让我们简要理解Istio如何工作。


    Istio有两个平面,一个控制平面和一个数据平面。数据平面由一组部署为sidecars的智能代理(Envoy)组成,包括代理和控制微服务之间的所有网络通信策略和遥测中心混合工具。


    控制平面管理和配置代理以路由处理。此外,控制平面配置实施策略并收集遥测。


    Citadel用于身份验证,Pilot为Envoy提供服务发现,并为智能路由和弹性提供流量管理功能。


    Istio是一个智能代理,它做到了:


    • 动态服务发现

    • 负载均衡

    • TLS终止

    • HTTP / 2和gRPC代理

    • 熔断器

    • 健康检查

    • 流量分割的分阶段部署

    • 故障注入

    • 丰富的动态指标


    我想强调的是,微服务架构之旅并不像人们想象的那么容易,虽然许多组织开始了这个技术旅程; 然而,人们遇到了我强调的不同层次的问题,缺乏架构规划这会使他们付出了很多代价。


    许多人将单体和微服务混合在一起,作为一种具有反腐化层设计模式的解决方案。向大家告诉一个消息,我的最新技术完成了Istio架设,这是微服务架构的最精彩之旅。


    作者:smiggle

    编译:洛逸



    (责任编辑:环球精益网)
    顶一下
    (0)
    0%
    踩一下
    (0)
    0%
    ------分隔线----------------------------
    特别说明

    此处放横条广告

    ◎最新评论
        谈谈您对该文章的看
        表  情:
        评论内容:
        * 请注意用语文明且合法,谢谢合作 审核后才会显示! Ctrl+回车 可以直接发表

        精益疑问
        免费咨询

        一键加群交流

        石老师

        18970479044