Browsed by
标签:RPC

Service Mesh实践之Istio初体验

Service Mesh实践之Istio初体验

閱讀本文約花費: 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治理微服务入门

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

Read More Read More

6种微服务RPC框架,你知道几个?

6种微服务RPC框架,你知道几个?

閱讀本文約花費: 7 (分鐘)跟语言平台绑定的开源 RPC 框架主要有下面几种。 Dubbo:国内最早开源的 RPC 框架,由阿里巴巴公司开发并于 2011 年末对外开源,仅支持 Java 语言。 Motan:微博内部使用的 RPC 框架,于 2016 年对外开源,仅支持 Java 语言。 Tars:腾讯内部使用的 RPC 框架,于 2017 年对外开源,仅支持 C++ 语言。 Spring Cloud:国外 Pivotal 公司 2014 年对外开源的 RPC 框架,仅支持 Java 语言 而跨语言平台的开源 RPC 框架主要有以下几种。 gRPC:Google 于 2015 年对外开源的跨语言 RPC 框架,支持多种语言。 Thrift:最初是由 Facebook 开发的内部系统跨语言的 RPC 框架,2007 年贡献给了 Apache 基金,成为 Apache 开源项目之一,支持多种语言。 如果你的业务场景仅仅局限于一种语言的话,可以选择跟语言绑定的 RPC 框架中的一种; 如果涉及多个语言平台之间的相互调用,就应该选择跨语言平台的 RPC 框架。 RPC 框架,它们具体有何区别? 1. Dubbo 先来聊聊 Dubbo,Dubbo 可以说是国内开源最早的 RPC 框架了,目前只支持 Java 语言,它的架构可以用下面这张图展示。 从图中你能看到,Dubbo 的架构主要包含四…

Read More Read More

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

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

閱讀本文約花費: 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

蚂蚁金服 Service Mesh 实践探索

蚂蚁金服 Service Mesh 实践探索

閱讀本文約花費: 50 (分鐘)摘要 在勇敢的选择了Service Mesh作为未来技术方向之后,蚂蚁金服率先开始了Service Mesh大规模落地探索。在此过程中,我们遇到很多问题,面临各种挑战,也有了一些思路和方法。今天我们将这些实践分享出来,并结合我们开源的SOFAMesh项目,和大家一起探讨:如何更好的将Service Mesh这样的新兴技术落地于实际生产环境。 大家好,我是来自蚂蚁金服中间件团队的敖小剑,目前是蚂蚁金服 Service Mesh 项目的PD。我同时也是 Servicemesher中国技术社区 的创始人,是 Service Mesh 技术在国内最早的布道师。我今天给大家带来的主题是”长路漫漫踏歌而行:蚂蚁金服Service Mesh实践探索”。 今天我们的内容不是继续做 Service Mesh 的布道,今年要好好讲一讲实践。所以今天我不会像去年那样给大家详细解释 Service Mesh 是什么,能做什么,有什么优势。而是结合过去一年中蚂蚁金服的实践经验,结合蚂蚁金服的 SOFAMesh 产品,帮助大家更深刻的理解 Service Mesh 技术。 在开始今天的内容分享之前,我们先来热个身,温习一下去年的内容。去年我是来布道的,而布道的核心内容就是告诉大家:Service Mesh 是什么? 为了帮忙大家回答,我给出一个提示图片,了解 Service M…

Read More Read More

高并发架构的设计

高并发架构的设计

閱讀本文約花費: 10 (分鐘)1、什么是高并发 1)高并发(High Concurrency)是互联网分布式系统架构设计中必须考虑的因素之一,它通常 是指,通过设计保证系统能够同时并行处理很多请求。 2)高并发相关常用的一些指标有响应时间(Response Time),吞吐量(Throughput),每秒查 询率 QPS(Query Per Second),并发用户数等。 3)响应时间:系统对请求做出响应的时间。例如系统处理一个 HTTP 请求需要 200ms,这个 200ms 就是系统的响应时间。 4)吞吐量:单位时间内处理的请求数量。 5)QPS:每秒响应请求数。在互联网领域,这个指标和吞吐量区分的没有这么明显。 6)并发用户数:同时承载正常使用系统功能的用户数量。例如一个即时通讯系统,同时在线量 一定程度上代表了系统的并发用户数。 2、如何提升系统的并发能力 互联网分布式架构设计,提高系统并发能力的方式,方法论上主要有两种:垂直扩展 (Scale Up)与水平扩展(Scale Out)。 垂直扩展:提升单机处理能力。垂直扩展的方式又有两种: 1)增强单机硬件性能,例如:增加 CPU 核数如 32 核,升级更好的网卡如万兆,升级更 好的硬盘如 SSD,扩充硬盘容量如 2T,扩充系统内存如 128G; 2)提升单机架构性能,例如:使用 Cache 来减少 IO 次数,使用异步来…

Read More Read More

别让自己“墙”了自己

别让自己“墙”了自己

閱讀本文約花費: 19 (分鐘)这一两周与几个朋友聊天,有年轻的90后,也有大叔级的70后,这些人在我看来都是很有能力的人,但是一些喜好过于强烈,让我不经意地回顾了我工作20年来身边的人,有发展得好的,也有发展的不好的,有些人是很可惜的,因为限制他们的不是其它人,也不是环境,而是自己,所以,很想写下这篇文章。(注:这篇文章可能会是一篇说教的文章,所以,可能会让你看着犯困,所以,我会尽量地短一些,而且尽可能多讲故事,少道理,这里的故事,全是真实发生的) 几个故事 2019年年初,我面试了一个很年轻的小伙子(93/94年出生),这个小伙子特别有灵性,也很聪明,计算机专业出身,也很喜欢技术,基础和学习能力也很好。在我这20年来认识的人中,如果他能呆在北京、上海、深圳这样的城市,我保证不出三年,他会成为他们同龄人中非常出色的技术人员,如果有个好的舞台有一个好的团队带他,他的未来会非常成功。然而,这个小伙子有两大喜好:1)只愿(或是说被迫)呆在一个毫无IT的环境的三/四线城市,2)对技术有非常大的偏好,只喜欢Go语言,非常不喜欢其它的语言,比如:Java(离开Java的世界,基本上离开了做架构的世界(相关解释见文末))。 他的这两个喜好,足以让一个未来会很优秀的人毁掉,因为,这个时代没有限制他,他的能力也没有限制他,但是他的意识完完全全地限制了他。 他把自己最宝贵的青春放在了很烂的项目上,就…

Read More Read More

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

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

閱讀本文約花費: 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

程序员如何把控自己的职业

程序员如何把控自己的职业

閱讀本文約花費: 26 (分鐘)这篇文章的主要内容主要是我今年3月份在腾讯做的直播,主要是想让一些技术人员对世界有一个大体的认识,并且在这个认识下能够有一个好的方法成就自己。而不是在一脸蒙圈的状态下随波逐流,而日益迷茫和焦虑。直播完后,腾讯方面把我的直播形成文字的形式发了出来,我觉得我可以再做一个精编版。所以,有了这篇文章,希望对大家有帮助。 对我来说,在我二十多年的工作经历来看,期间经历了很多技术的更新换代,整个技术模式、业务模式也是一直变来变去,我们这群老程序员成长中所经历的技术比今天的程序员玩的还更杂更多。我罗列一下我学过的,而且还被淘汰掉的技术,大家先感受一下。 – MIS应用开发:FoxPro,PowerBuilder,Delphi – OA:Lotus Notes,VBScripts – 微软:ODBC/ADO,COM/DCOM,MFC/ATL,J++ – 服务器:AIX,HP-UX,SCO Unix – Web:CGI,ISAPI,SOAP – RPC:CICS,Tuxedo – J2EE:Websphere,Weblogic – DB:Sybase,Informix 我想说的是,无论过去还是今天,我们这些前浪和你们后浪所面对的技术的挑战和对技术的焦虑感是相似的,我们那个时候不但玩996,还玩封闭开发(就是一周只能回家一天)。当然,唯一好的东西,就是比起今天的程序员来…

Read More Read More

Service Mesh 在有赞的实践与发展

Service Mesh 在有赞的实践与发展

閱讀本文約花費: 20 (分鐘)一、缘起 有赞初期,使用的是 Nginx+PHP-FPM,所有的业务逻辑代码都在一个叫做 Iron 的 PHP 代码仓库里,是一个典型的单体应用 (Monolith),整体架构可以简单的表示成下图: 架构在有赞初期,团队规模比较小,且业务逻辑相对比较简单的时候,很好的支撑和承载了有赞的核心业务。但是,随着有赞业务和团队规模的极速发展,单体应用的缺陷愈来愈凸显: 耦合性高 隔离性差 团队协作性差 一次发布带来的故障往往需要几个业务团队的人坐在一起,花费数十分钟甚至几个小时才能定位究竟是哪处改动引发的。对单体应用进行微服务改造,势在必行。 综合当时团队和业务发展的实际情况,一方面,有赞选择了国内非常流行且具备良好生态的 dubbo 作为 Java 语言 RPC 框架;另一方面,考虑到团队中有相当数量 PHP 开发的同学,有赞内部孵化出了 ZanPHP——使用 PHP 语言的纯异步 RPC 框架,并选择了 ETCD 作为服务注册和发现中心,开始搭建有赞服务化的整体架构。为了解决跨语言 (Java 与 PHP 语言之间) 的 RPC 通信问题,有赞在 facebook 开源的 thrift 协议基础上进行了二次封装,开发了 NOVA 协议用以支持跨语言 RPC 调用。 综上所述,这一时期,整体的架构选型如下: 尽管将单体应用拆分成微服务能够带来一系列众所周知…

Read More Read More

Service Mesh的本质、价值和应用探索

Service Mesh的本质、价值和应用探索

閱讀本文約花費: 17 (分鐘)Service Mesh 进入国内技术社区后很快就成了微服务的“新秀”。2018 年 Service Mesh 这一技术可以用“火爆”一词去形容:Istio 1.0 正式发布、Linkerd 2.0 发布、Knative 基于 Istio 打造等等。 网上介绍 Service Mesh 的资料不少,但关注这一技术的本质、价值的内容却不多。阿里巴巴高级技术专家李云带领团队在这一领域探索的过程中想清楚了这两点,并在 QCon 2018 上海站分享了阿里巴巴对 Service Mesh 的探索与实践。 大规模分布式应用的挑战 微服务软件架构(microservices)已经被越来越多的企业作为规模分布式软件开发的首选架构。引入该架构之初是将一个单体应用拆解成多个更小粒度的微服务 (micro-service),通过 HTTP API 或像 Dubbo 这样的 RPC 框架将这些服务组装起来作为整体去提供服务。由于每个微服务足够地小且功能内聚,因此能很好地解决以往单体应用的开发与发布困难的问题。即便如此,随着企业的业务发展和人员规模的壮大,不同业务所形成的微服务群之间的协同却面临新的挑战。 在阿里巴巴内部,RPC 框架由中间件事业部统一开发与维护,以 SDK 形式提供给集团内的其他事业部使用。由于 SDK 与应用逻辑是耦合在同一个进程中的,当 SDK 向前演…

Read More Read More

聊聊ServiceMesh 数据面板 Envoy

聊聊ServiceMesh 数据面板 Envoy

閱讀本文約花費: 27 (分鐘)Envoy 简介 在 Service Mesh 模式中,每个服务都配备了一个代理“sidecar”,用于服务之间的通信。这些代理通常与应用程序代码一起部署,并且它不会被应用程序所感知。Service Mesh 将这些代理组织起来形成了一个轻量级网络代理矩阵,也就是服务网格。这些代理不再是孤立的组件,它们本身是一个有价值的网络。其部署模式如图所示: 绿色部分代表应用程序 蓝色部分则是sidecar 服务网格是用于处理服务到服务通信的“专用基础设施层”。它通过这些代理来管理复杂的服务拓扑,可靠地传递服务之间的请求。 从某种程度上说,这些代理接管了应用程序的网络通信层。 Envoy是 Service Mesh 中一个非常优秀的 sidecar 的开源实现。我们就来看看 Envoy 都是做些什么工作。 Envoy 用到的几个术语 Host: 通常我们将 Host 看做是一个具备网络通信功能的实体(可以是一台物理机,也可以是一台移动设备等等) 。在 Envoy 中,host 是一个逻辑网络中的应用. 可能运行在由有多个主机组成的底层硬件,只要它们各自独立寻址。 Downstream: 请求发起者(服务请求方)。 Upstream: 请求接收者(服务提供方)。 Listener: 服务(程序)监听者。就是真正干活的。 envoy 会暴露一个或者多个listene…

Read More Read More

浅谈服务治理、微服务与Service Mesh

浅谈服务治理、微服务与Service Mesh

閱讀本文約花費: 48 (分鐘)SOA与服务治理 SOA(面向服务的体系结构)概念由来已久,在10多年前便开始进入到我们广大软件开发者的视线中。SOA是一种粗粒度、松耦合服务架构,服务之间通过简单、精确定义接口进行通讯,不涉及底层编程接口和通讯模型。SOA可以看作是B/S模型、Web Service技术之后的自然延伸。 服务治理,也称为SOA治理,是指用来管理SOA的采用和实现的过程。以下是在2006年时IBM对于服务治理要点的总结: l 服务定义(服务的范围、接口和边界) l 服务部署生命周期(各个生命周期阶段) l 服务版本治理(包括兼容性) l 服务迁移(启用和退役) l 服务注册中心(依赖关系) l 服务消息模型(规范数据模型) l 服务监视(进行问题确定) l 服务所有权(企业组织) l 服务测试(重复测试) l 服务安全(包括可接受的保护范围) 限于当时的技术发展水平,广大软件设计与开发人员对于SOA和服务治理的技术认知还主要停留在Web Service和ESB总线等技术和规范上,并没有真正在软件开发中得以充分落地。 Dubbo开源 直到2011年10月27日,阿里巴巴开源了自己的SOA服务化治理方案的核心框架Dubbo,服务治理和SOA的设计理念开始逐渐在国内软件行业中落地,并被广泛应用。 Dubbo作为阿里巴巴内部的SOA服务化治理方案的核心框架,在2012年时已经…

Read More Read More

Kubernetes Informer 机制源码解析

Kubernetes Informer 机制源码解析

閱讀本文約花費: 14 (分鐘)这篇文章来源于云原生社区组织的 Kubernetes 源码研习社的作业,是个人学习Informer机制、理解Informer各个组件的设计的总结。 背景 为什么Kubernetes需要Informer机制?我们知道Kubernetes各个组件都是通过REST API跟API Server交互通信的,而如果每次每一个组件都直接跟API Server交互去读取/写入到后端的etcd的话,会对API Server以及etcd造成非常大的负担。而Informer机制是为了保证各个组件之间通信的实时性、可靠,并且减缓对API Server和etcd的负担。 Informer 流程 这个流程,建议先看看《From Controller Study Informer》 这里我们以CoreV1. Pod资源为例子: 第一次启动Informer的时候,Reflector 会使用 List从API Server主动获取CoreV1. Pod的所有资源对象信息,通过 resync将资源存放在 Store中 持续使用 Reflector建立长连接,去 Watch API Server发来的资源变更事件 当2 监控到CoreV1.Pod的资源对象有增加删除修改之后,就把资源对象存放在 DeltaFIFO中,…

Read More Read More

《微服务架构设计模式》之二:服务的拆分策略

《微服务架构设计模式》之二:服务的拆分策略

閱讀本文約花費: 67 (分鐘) 2.1 微服务架构到底是什么第1章描述了微服务架构的关键思想是如何进行功能分解。你可以将应用程序构建为一组服务,而不是开发一个大型的单体应用程序。一方面,将微服务架构描述为一种功能分解是有用的。但另一方面,它留下了几个未解决的问题,包括:微服务架构如何与更广泛的软件架构概念相结合?什么是服务?服务的规模有多重要?为了回答这些问题,我们需要退后一步,看看软件架构的含义。软件的架构是一种抽象的结构,它由软件的各个组成部分和这些部分之间的依赖关系构成。正如你将在本节中看到的,软件的架构是多维的,因此有多种方法可以对其进行描述。架构很重要的原因是它决定了应用程序的质量属性或能力。传统上,架构的目标是可扩展性、可靠性和安全性。但是今天,该架构能够快速安全地交付软件,这一点非常重要。你将了解微服务架构是一种架构风格,可为应用程序提供更高的可维护性、可测试性和可部署性。我将通过描述软件架构的概念及其重要性来开始本节。接下来,我将讨论架构风格的概念。然后我将微服务架构定义为特定的架构风格。让我们从理解软件架构的概念开始。2.1.1 软件架构是什么,为什么它如此重要架构显然很重要。至少有两个专门讨论该主题的会议:Oreilly的软件架构会议和SATURN会议。许多开发人员的目标是成为一名架构师。但什么是架构,为什么它如此重要?为了回答这个问题,我首先定义术语软件架构…

Read More Read More

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

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

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

Read More Read More

Scroll Up