Browsed by
标签： Prometheus

Service Mesh实践之Istio初体验

Service Mesh实践之Istio初体验

Comments 0 Comment  272 Views

閱讀本文約花費: 16 (分鐘)微服务国内发展背景： 2014年，Martin Fowler撰写的《Microservices》使得许多国内的先行者接触到微服务这个概念并将其引入国内，2015年越来越多的人通过各种渠道了解到微服务的概念并有人开始在生产环境中落地，2016-2017年，微服务的概念被越来越多的人认可，带动了一大批公司以微服务和容器为核心开始技术架构的全面革新。 至今微服务已经历了两代发展，第一代以Spring Cloud为代表的微服务开发框架，该框架在微服务发展的前几年一度独领风骚，甚至在部分人群中成为微服务的代名词，但事实上该微服务框架并不是唯一实现微服务的方式；第二代微服务技术为服务网格（Service Mesh），它的出现解决了大部分开发人员在使用Spring Cloud中遇到的不足和痛点。 Service Mesh是如何解决这些问题的，又是何以赢得众多开发者的支持呢？笔者就这些问题给大家分享一篇以Istio为代表的第二代微服务实践。 一、微服务和Istio Service Mesh基本概念 服务网格是一个基础设施层，主要用于处理服务间的通信。云原生应用有着复杂的服务拓扑，服务网格负责在这些拓扑中实现请求的可靠传递。在实践中，服务网格通常实现为一组轻量级网络代理，它们与应用程序部署在一起，而对应用程序透明。 图1展示了服务网格的拓扑，当微服务数量增多达到几十上…

Read More Read More

使用Istio治理微服务入门

使用Istio治理微服务入门

Comments 0 Comment  236 Views

閱讀本文約花費: 20 (分鐘)近两年微服务架构流行，主流互联网厂商内部都已经微服务化，初创企业虽然技术积淀不行，但也通过各种开源工具拥抱微服务。再加上容器技术赋能，Kubernetes又添了一把火，微服务架构已然成为当前软件架构设计的首选。 但微服务化易弄，服务治理难搞！ 一、微服务的“痛点” 微服务化没有统一标准，多数是进行业务领域垂直切分，业务按一定的粒度划分职责，并形成清晰、职责单一的服务接口，这样每一块规划为一个微服务。微服务之间的通信方案相对成熟，开源领域选择较多的有RPC或RESTful API方案，比如：gRPC、Apache Thrift等。这些方案多偏重于数据如何打包、传输与解包，对服务治理的内容涉及甚少。 微服务治理是头疼的事，也是微服务架构中的痛点。治理这个词有多元含义，很难下达一个精确定义，这里可以像小学二年级学生那样列出治理的诸多近义词：管理、控制、规则、掌控、监督、支配、规定、统治等。对于微服务而言，治理体现在以下诸多方面： 服务注册与发现 身份验证与授权 服务的伸缩控制 反向代理与负载均衡 路由控制 流量切换 日志管理 性能度量、监控与调优 分布式跟踪 过载保护 服务降级 服务部署与版本升级策略支持 错误处理 …… 从微服务治理角度来说，微服务其实是一个“大系统”，要想将这个大系统全部落地，绝非易事，尤其是之前尚没有一种特别优雅的技术方案。多数方案（…

Read More Read More

kubernetes实践：Istio之策略与遥测

kubernetes实践：Istio之策略与遥测

Comments 0 Comment  266 Views

閱讀本文約花費: 9 (分鐘)一：Istio简介 1.Istio定义 一个用来连接，管理和保护服务的开发平台。Istio提供一种简单的方式建立已部署服务网络，具备负载均衡，服务间认证和监控等功能。 而不需要改变任何服务代码。想要为服务增加对Istio的支持，只需要在环境中部署一个sidecar,使用Istio控制面板功能配置和管理代理，拦截微服务之间的所有网络通信。 2.为什么需要Istio 随着微服务出现，微服务的连接，管理和监控成为难题。Kubernetes可以处理多个容器的工作负载，但当涉及更复杂的需求时，需要像Istio这样的服务网格。 3.Istio的主要功能 a.流量管理(Pilot): 控制服务之间的流量和API调用的流向，使得调用更灵活可靠，并使网络在恶劣情况下更加健壮。 b.可观察性： 通过集成zipkin等服务，快速了解服务之间的依赖关系，以及它们之间流量的本质和流向，从而提供快速识别问题的能力。 c.策略执行(mixer): 将组织策略应用于服务之间的互动，确保访问策略得以执行，资源在消费者之间良好分配。策略的更改是通过配置网格而不是修改应用程序代码。 d.服务身份和安全(Istio-auth)： 为网格中的服务提供可验证身份，并提供保护服务流量的能力，使其可以在不同可信度的网络上流转。 4.Envoy架构 a.svcA服务作为客户端点用服务端svcB，svc…

Read More Read More

Service Mesh架构反思：数据平面和控制平面的界线该如何划定？

Service Mesh架构反思：数据平面和控制平面的界线该如何划定？

Comments 0 Comment  227 Views

閱讀本文約花費: 19 (分鐘)苦等一年，始终不见Istio的性能有实质性提升，失望之余，开始反思Istio而至Service Mesh的架构。焦点所在：proxy到底该做哪些事情？架构的优美和性能的实际表现该如何平衡？ 问题所在 Istio的性能，从去年5月问世以来，就是一块心病。 前段时间Istio 0.7.1版本发布，不久我们得到了这个一个”喜讯”：Istio的性能在0.7.1版本中得到了大幅提升！ 最大QPS从0.5.1的700，到0.6.0的1000，再到0.7.1的1700，纵向比较Istio最近的性能提升的确不错，都2.5倍性能了。 但是，注意，QPS 700/1000/1700。是的，没错，你没有看错，没有漏掉一个零或者两个零。 稍微回顾一下近年中有自己有实际感受的例子： 几个月之前写了一个基于netty4.1的HTTP转发的demo，没做任何优化和调教，轻松10万+的QPS 两年前写的dolphin框架，gRPC直连，15万QPS轻松做到 然后，白衣和隔壁老王两位同学轻描淡写的好像说过，OSP极致性能过了20万QPS了（背景补充：OSP是唯品会的服务化框架，sidecar模式，它的Proxy是被大家诟病以慢著称的Java）。 当然Istio测试场景稍微复杂一些，毕竟不是空请求，但是如论如何，从QPS十几二十万这个级别，直落到QPS一两千，中间有几乎100倍的差距。…

Read More Read More

最常用的Java框架或者开源项目有哪些？

最常用的Java框架或者开源项目有哪些？

Comments 0 Comment  236 Views

閱讀本文約花費: 19 (分鐘)系统设计 微服务/分布式 基础框架 Spring Boot [1] ：Spring Boot 可以轻松创建独立的生产级基于 Spring 的应用程序,内置 web 服务器让你可以像运行普通 Java 程序一样运行项目。另外，大部分 Spring Boot 项目只需要少量的配置即可，这有别于 Spring 的重配置。 spring-cloud-alibaba[2] : Spring Cloud Alibaba 致力于提供微服务开发的一站式解决方案。此项目包含开发分布式应用微服务的必需组件，方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。 Spring Cloud Alibaba Sentinel[3] ：A lightweight powerful flow control component enabling reliability and monitoring for microservices. (轻量级的流量控制、熔断降级 Java 库)。 Dubbo[4] ：Apache Dubbo 是一个基于 Java 的高性能开源 RPC 框架。 Nacos[5] ：Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮…

Read More Read More

微服务运维减负：Istio Service Mesh原理+实战

微服务运维减负：Istio Service Mesh原理+实战

Comments 0 Comment  184 Views

閱讀本文約花費: 8 (分鐘)一、Istio的来源 随着微服务架构的普及，越来越多的应用已经拆分成了微服务的架构。而微服务架构落地的一个难点，就是如何让服务和服务之间进行稳定的通信。 部署微服务之后，如何做服务的负载均衡、容错性、服务监控、日志追踪以及熔断等功能都需要考虑周全。 还好，现在已经有很多开源工具帮你做这样的事情。例如： Netflix的Eureka实现服务注册，它的优势在于实现跨数据中心的服务注册； Ribbon – 客户端的负载均衡； Hystrix – 微服务的熔断器； Zipkin – 分布式的追踪组件； Prometheus – 监控组件； Grafana – 数据可视化的工具； 于是，在写完我的微服务之后，我引入了更多的组件，带来了极大的部署复杂度，每个组件都需要高可用、负载均衡、熔断、日志收集等等。 为了让业务团队返璞归真，将所有精力集中在业务代码而不是配合微服务组件写大量非功能性需求的代码，Istio应运而生。 Istio是谷歌、IBM、Lyft等公司贡献的开源Service Mesh组件。它实现的目标就是让业务开发不再关注微服务之间如何调用、管理、监控等非功能性需求，而是让Istio来处理这些问题。Istio和Kubernetes有天然的支持。 Istio能轻松解决蓝绿发布和金丝雀发布的问题。 金丝雀发布有什么用？它的最大实际意义，是让运维不用在夜里加班…

Read More Read More

蚂蚁金服大规模微服务架构下的Service Mesh探索之路

蚂蚁金服大规模微服务架构下的Service Mesh探索之路

Comments 0 Comment  144 Views

閱讀本文約花費: 44 (分鐘)前言 今天给大家带来的内容叫做Service Mesh探索之路，但是在前面加了一个定语：大规模微服务架构下。之所以加上这个词，是因为我们这个体系是在蚂蚁金服这样一个大的架构下进行的，蚂蚁金服的体量大家可以想象，所以这个探索会带有一个非常隆重的色彩：对性能/规模/高可用等方面的思考。 在深圳的GIAC大会，我们同事披露了这个正在开发中的 Service Mesh产品，我们现在暂时命名为 SOFA Mesh。我们目前的产品都在 SOFA品牌下，比如 SOFA RPC，SOFA Boot等。今天我们详细介绍 SOFA Mesh这个单独产品，上次大会只是简单披露，也就是给大家介绍说我们有这样一个产品，而我今天的内容是把这个产品详细展开。 一、技术选型 先上来一堆要求，刚才我们提到过的，因为是大规模，而蚂蚁金服的体量，大家可以想象到的。实际上在性能，稳定性上，我们的衡量标准，我们考虑的基石，都是以蚂蚁金服这样的一个规模来考虑的。 在这样一个规模下，我们会涉及到一些跟其他公司不太一样的地方，比如说：我们在性能的考量上会比较重一些。因为如果性能不高的话，可能没法支撑我们这样一个规模。在考虑性能的时候，就有另外一层考量：架构和性能之间的这个权衡和取舍是要非常谨慎的。性能要求不太高的情况下，架构可能的选择，和需要比较高性能的情况下，可能会有完全不一样的取舍。稳定性就不…

Read More Read More

CephFS+Kubernetes 在网易轻舟容器平台的实践

CephFS+Kubernetes 在网易轻舟容器平台的实践

Comments 0 Comment  377 Views

閱讀本文約花費: 8 (分鐘)在网易集团，基于 Kubernetes 构建的网易轻舟云原软件生产力平台扮演着支撑数字化业务快速高效创新的重任，帮助业务团队快速实现云原生应用，提高研发效能，并节省运维成本。 作为网易轻舟云原生平台的存储后端，CephFS 主要为网易轻舟容器平台 NCS 解决容器间共享存储的问题。尤其是在当前比较火的 AI 训练场景应用十分广泛，存储规模达已达数 PB 级，CephFS 的性能优化等工作非常重要。 Ceph 和 CephFS 简介 Ceph 由 RADOS 作为底座，上层提供对象、块、文件等接口服务。RADOS 由 MON、OSD、MGR 组成，MON 负责集群的各类视图（osdmap，pgmap 等），健康状态的管理。MGR 则提供了丰富的系统信息查询功能，以及支持第三方模块接入（Zabbix，Prometheus，Dashboard 等）。OSD 则负责最终的数据存储，一般一个 OSD 对应一块磁盘。 CephFS 在此架构基础之上增加了 MDS 和 client，其中 MDS 负责文件系统的元数据管理和持久化操作。client 则对外提供了兼容 POSIX 语义的文件系统客户端，可通过 mount 命令进行挂载。 CephFS 典型实践 部署 整个 CephFS 在轻舟 Kubernetes 环境中的部署架构如下： 在 Kubernetes 的使…

Read More Read More

Nacos 企业级落地实践

Nacos 企业级落地实践

Comments 0 Comment  493 Views

閱讀本文約花費: 16 (分鐘)前言 在高速发展的时候，公司规模越来越大，老师人数越来越多，这时候公司不能铺太多人去做运营与服务，必须提高每个人效，这就需要技术驱动。因此掌门教育转变成一家技术驱动型的公司，如果被迫成为一家靠资金驱动的公司就活不下去了。 ——张翼（掌门教育创始人兼 CEO） 掌门教育自 2014 年正式转型在线教育以来，秉承“让教育共享智能，让学习高效快乐”的宗旨和愿景，经历云计算、大数据、人工智能、 AR / VR / MR 以及现今最火的 5G ，一直坚持用科技赋能教育。掌门教育的业务近几年得到了快速发展，特别是今年的疫情，使在线教育成为了新的风口，也给掌门教育新的机遇。 随着业务规模进一步扩大，流量进一步暴增，微服务数目进一步增长，使老的微服务体系所采用的注册中心 Eureka 不堪重负，同时 Spring Cloud 体系已经演进到第二代，第一代的 Eureka 注册中心已经不大适合现在的业务逻辑和规模，同时它目前被 Spring Cloud 官方置于维护模式，将不再向前发展。如何选择一个更为优秀和适用的注册中心，这个课题就摆在了掌门人的面前。经过对 Alibaba Nacos 、HashiCorp Consul 等开源注册中心做了深入的调研和比较，最终选定 Alibaba Nacos 做微服务体系 Solar 中的新注册中心。 背景故事 掌门教育微服务面临…

Read More Read More

【K8S】基于Docker+K8S+GitLab/SVN+Jenkins+Harbor搭建持续集成交付环境（环境搭建篇）

【K8S】基于Docker+K8S+GitLab/SVN+Jenkins+Harbor搭建持续集成交付环境（环境搭建篇）

Comments 0 Comment  852 Views

閱讀本文約花費: 51 (分鐘)环境搭建概述 1.K8S是什么？ K8S全称是Kubernetes，是一个全新的基于容器技术的分布式架构领先方案，基于容器技术，目的是实现资源管理的自动化，以及跨多个数据中心的资源利用率的最大化。 如果我们的系统设计遵循了kubernetes的设计思想，那么传统系统架构中那些和业务没有多大关系的底层代码或功能模块，都可以使用K8S来管理，我们不必再费心于负载均衡的选型和部署实施问题，不必再考虑引入或自己开发一个复杂的服务治理框架，不必再头疼与服务监控和故障处理模块的开发。总之，使用kubernetes提供的解决方案，会大大减少开发成本，同时可以将精力更加集中于业务本身，而且由于kubernetes提供了强大的自动化机制，所以系统后期的运维难度和运维成本大幅降低。 2.为什么要用K8S? Docker 这个新兴的容器化技术当前已经被很多公司所采用，其从单机走向集群已成必然，而云计算的蓬勃发展正在加速这一进程。Kubernetes 作为当前唯一被业界广泛认可和看好的 Docker 分布式系统解决方案。可以预见，在未来几年内，会有大量的新系统选择它，不管是运行在企业本地服务器上还是被托管到公有云上。 3.使用K8S有哪些好处？ 使用Kubernetes就是在全面部署微服务架构。微服务架构的核心就是将一个巨大的单体应用分解为很多小的互相连接的微服务，一个微服…

Read More Read More

云原生应用 Kubernetes 监控与弹性实践

云原生应用 Kubernetes 监控与弹性实践

Comments 0 Comment  396 Views

閱讀本文約花費: 8 (分鐘) 本文向大家介绍一个云原生应用该如何在Kubernetes中无缝集成监控和弹性能力。希望对您的学习有所帮助。 前言 云原生应用的设计理念已经被越来越多的开发者接受与认可，而Kubernetes做为云原生的标准接口实现，已经成为了整个stack的中心，云服务的能力可以通过Cloud Provider、CRD Controller、Operator等等的方式从Kubernetes的标准接口向业务层透出。开发者可以基于Kubernetes来构建自己的云原生应用与平台，Kubernetes成为了构建平台的平台。 阿里云容器服务Kubernetes的监控总览 云服务集成 阿里云容器服务Kubernetes目前已经和四款监控云服务进行了打通，分别是SLS（日志服务）、ARMS（应用性能监控）、AHAS（架构感知监控服务）、Cloud Monitor（云监控）。 SLS主要负责日志的采集、分析。在阿里云容器服务Kubernetes中，SLS可以采集三种不同类型的日志 APIServer等核心组件的日志 Service Mesh/Ingress等接入层的日志 应用的标准日志 除了采集日志的标准链路外，SLS还提供了上层的日志分析能力，默认提供了基于APIServer的审计分析能力、接入层的可观测性展现、应用层的日志分析。在阿里云容器服务Kubernetes中，日志组件…

Read More Read More

第四章 Sentinel–服务容错

第四章 Sentinel–服务容错

Comments 0 Comment  415 Views

閱讀本文約花費: 30 (分鐘) 从高并发带来的问题的问题说起 ，讲解服务雪崩效应，常见容错方案，Sentinel基础，相关的应用规则等。 4.1 高并发带来的问题 在微服务架构中，我们将业务拆分成一个个的服务，服务与服务之间可以相互调用，但是由于网络原因或者自身的原因，服务并不能保证服务的100%可用，如果单个服务出现问题，调用这个服务就会出现网络延迟，此时若有大量的网络涌入，会形成任务堆积，最终导致服务瘫痪。 接下来，我们来模拟一个高并发的场景 @[email protected] class OrderController2 {@Autowiredprivate OrderService orderService;@Autowiredprivate ProductService productService;@RequestMapping(“/order/prod/{pid}”)public Order order(@PathVariable(“pid”) Integer pid) {log.info(“接收到{}号商品的下单请求,接下来调用商品微服务查询此商品信息”, pid); //调用商品微服务,查询商品信息Product product = productService.find…

Read More Read More

阿里巴巴双十一千万级实时监控系统技术揭秘

阿里巴巴双十一千万级实时监控系统技术揭秘

Comments 0 Comment  711 Views

閱讀本文約花費: 13 (分鐘)本次分享主要介绍以下四方面： 时序业务全景 TSDB 介绍 核心技术 总结展望 时序业务全景 从底层的机器监控到直面用户的应用，都离不开时序性的业务场景，而时序性的数据一般都由专业的时序数据库来存储分析，下面主要介绍 TSDB 覆盖的业务场景以及面临的挑战。 1.1 时序数据库覆盖场景 基础设施层：机柜、物理机、操作系统监控日志 基础运维：sunfire(集团统一监控、采集、报警系统)、阿里云监控、GOC(阿里全球应急调度指挥系统) 资源调度：集团内部调度系统、Kubernetes 集群管理：DBPaas(阿里所有数据库实例的监控和调度) 应用层：APM 场景下的各种应用 1.2 时序数据库面临的挑战 由于面临各个层级的不用场景，所以时序数据库也面临不同挑战： 应用层挑战：由于直面客户所以需要提供高频率、低延迟的查询 olap 数据库本身特性：海量数据的聚合 时序数据库特有的：发散时间线 双十一大促：突然流量十倍以上增长 TSDB 介绍 2.1 TSDB 的发展及性能 TSDB 于 2016 年开始服役, 到目前为止参与了三次双十一大促，相比于 2017 年读写吞吐翻倍增长, 写入 TPS4000w，查询 2wQPS 覆盖集团 130+ 业务线及存储百亿的时间线。 2.2 TSDB 架构介绍 如上图，从左到右为数据的采集到展现的过程： 边缘计算：轻量…

Read More Read More

Kubernetes HPA 详解

Kubernetes HPA 详解

Comments 0 Comment  683 Views

閱讀本文約花費: 32 (分鐘)Kubernetes HPA 详解 在前面的学习中我们使用用一个 kubectl scale 命令可以来实现 Pod 的扩缩容功能，但是这个毕竟是完全手动操作的，要应对线上的各种复杂情况，我们需要能够做到自动化去感知业务，来自动进行扩缩容。为此，Kubernetes 也为我们提供了这样的一个资源对象：HorizontalPodAutoscaling（Pod水平自动伸缩），简称 HPA，HPA 通过监控分析一些控制器控制的所有 Pod 的负载变化情况来确定是否需要调整 Pod 的副本数量，这是 HPA 最基本的原理： 我们可以简单的通过 kubectl autoscale 命令来创建一个 HPA 资源对象， HPAController默认 30s轮询一次（可通过 kube-controller-manager 的 –horizontal-pod-autoscaler-sync-period 参数进行设置），查询指定的资源中的 Pod 资源使用率，并且与创建时设定的值和指标做对比，从而实现自动伸缩的功能。 Metrics Server 在 HPA 的第一个版本中，我们需要 Heapster 提供 CPU 和内存指标，在 HPA v2 过后就需要安装 Metrcis Server 了， MetricsServer 可以通过标准的 Kubernetes A…

Read More Read More

Cloud Native Computing Foundation Announces ‘Introduction to Kubernetes’ Course Surpasses 100,000 Registrations

Cloud Native Computing Foundation Announces ‘Introduction to Kubernetes’ Course Surpasses 100,000 Registrations

Comments 0 Comment  350 Views

閱讀本文約花費: 2 (分鐘)Hosted by The Linux Foundation and edX.org, the course teaches the basics of Kubernetes to  developers and systems administrators SAN FRANCISCO, Calif. – January 28, 2020 – The Cloud Native Computing Foundation® (CNCF®), which builds sustainable ecosystems for cloud native software, today announced that more than 100,000 people have registered for the free ‘Introduction to Kubernetes’ course, hosted by The Linux Foundation with edX.org. CNCF has made significant investments to implement training, expert certification, and provider certification programs for Kubern…

Read More Read More

基于k8s Prometheus+Grafana+Altermanager钉钉报警

基于k8s Prometheus+Grafana+Altermanager钉钉报警

Comments 0 Comment  1,855 Views

閱讀本文約花費: 6 (分鐘)一、概述 Alertmanager与Prometheus是相互分离的两个组件。Prometheus服务器根据报警规则将警报发送给Alertmanager，然后Alertmanager将silencing、inhibition、aggregation等消息通过电子邮件、dingtalk和HipChat发送通知。 Alertmanager处理由例如Prometheus服务器等客户端发来的警报。它负责删除重复数据、分组，并将警报通过路由发送到正确的接收器，比如电子邮件、Slack、dingtalk等。Alertmanager还支持groups,silencing和警报抑制的机制。 钉钉作为内部通讯工具，基本上大家在电脑和手机上都能用，消息可以第一时间查看，报警消息的即时性要求比较高，所以适合用钉钉通知。 二、添加钉钉机器人 请参考官方文档：自定义机器人 添加机器人后获取机器人的hook（机器人好像只能在钉钉群里面添加）,在后面部署会用到。 机器人hook：https://oapi.dingtalk.com/robot/send?access_token=xxxxxx 三、配置Alertmanager Alertmanager官方文档：https://github.com/prometheus/docs/blob/db2a09a8a7e193d6e474f37…

Read More Read More

Scroll Up