技术标签: 架构
本文大量内容系转载自以下文章,有删改,并参考其他文档资料加入了一些内容:
今年,ServiceMesh(服务网格)概念在社区里头非常火,有人提出2018年是ServiceMesh年,还有人提出ServiceMesh是下一代的微服务架构基础。作为架构师,如果你现在还不了解ServiceMesh的话,是否感觉有点落伍了?
那么到底什么是ServiceMesh?它诞生的背景是什么?它解决什么问题?企业是否适合引入ServiceMesh?根据近年在一线互联网企业的实践和思考,从个人视角出发,我为大家一一解答这些问题。
在业务规模化和研发效能提升等因素的驱动下,从单块应用向微服务架构的转型(如下图所示),已经成为很多企业(尤其是互联网企业)数字化转型的趋势。
在微服务模式下,企业内部服务少则几个到几十个,多则上百个,每个服务一般都以集群方式部署,这时自然产生两个问题(如下图所示):
服务发现和负载均衡并不是新问题,业界其实已经探索和总结出一些常用的模式,这些模式的核心其实是代理(Proxy,如下图所以),以及代理在架构中所处的位置,
在服务消费方和服务提供方之间增加一层代理,由代理负责服务发现和负载均衡功能,消费方通过代理间接访问目标服务。根据代理在架构上所处的位置不同,当前业界主要有三种不同的服务发现模式:
这是最简单和传统做法,在服务消费者和生产者之间,代理作为独立一层集中部署,由独立团队(一般是运维或框架)负责治理和运维。常用的集中式代理有硬件负载均衡器(如F5),或者软件负载均衡器(如Nginx),F5(4层负载)+Nginx(7层负载)这种软硬结合两层代理也是业内常见做法,兼顾配置的灵活性(Nginx比F5易于配置)。
这种方式通常在DNS域名服务器的配合下实现服务发现,服务注册(建立服务域名和IP地址之间的映射关系)一般由运维人员在代理上手工配置,服务消费方仅依赖服务域名,这个域名指向代理,由代理解析目标地址并做负载均衡和调用。
国外知名电商网站eBay,虽然体量巨大,但其内部的服务发现机制仍然是基于这种传统的集中代理模式,国内公司如携程,也是采用这种模式。
这是很多互联网公司比较流行的一种做法,代理(包括服务发现和负载均衡逻辑)以客户库的形式嵌入在应用程序中。这种模式一般需要独立的服务注册中心组件配合,服务启动时自动注册到注册中心并定期报心跳,客户端代理则发现服务并做负载均衡。
Netflix开源的Eureka(注册中心)[附录1]和Ribbon(客户端代理)[附录2]是这种模式的典型案例,国内阿里开源的Dubbo也是采用这种模式。
这种做法是上面两种模式的一个折中,代理既不是独立集中部署,也不嵌入在客户应用程序中,而是作为独立进程部署在每一个主机上,一个主机上的多个消费者应用可以共用这个代理,实现服务发现和负载均衡,如下图所示。这个模式一般也需要独立的服务注册中心组件配合,作用同模式二。
Airbnb的SmartStack[附录3]是这种模式早期实践产品,国内公司唯品会对这种模式也有探索和实践。
上面介绍的三种服务发现模式各有优劣,没有绝对的好坏,可以认为是三种不同的架构风格,在不同的公司都有成功实践。下表总结三种服务发现模式的优劣比较,业界案例和适用场景建议,供架构师选型参考:
所谓的ServiceMesh,其实本质上就是上面提到的模式三~主机独立进程模式,这个模式其实并不新鲜,业界(国外的Airbnb和国内的唯品会等)早有实践,那么为什么现在这个概念又流行起来了呢?我认为主要原因如下:
模式三(ServiceMesh)也被形象称为边车(Sidecar)模式,如下图,早期有一些摩托车,除了主驾驶位,还带一个边车位,可以额外坐一个人。在模式三中,业务代码进程(相当于主驾驶)共享一个代理(相当于边车),代理除了负责服务发现和负载均衡,还负责动态路由、容错限流、监控度量和安全日志等功能,这些功能是具体业务无关的,属于跨横切面关注点(Cross-Cutting Concerns)范畴。
通信需要底层能够传输字节码和电子信号的物理层来完成,在TCP协议出现之前,服务需要自己处理网络通信所面临的丢包、乱序、重试等一系列流控问题,因此服务实现中,除了业务逻辑外,还夹杂着对网络传输问题的处理逻辑。
为了避免每个服务都需要自己实现一套相似的网络传输处理逻辑,TCP协议出现了,它解决了网络传输中通用的流量控制问题,将技术栈下移,从服务的实现中抽离出来,成为操作系统网络层的一部分。
在TCP出现之后,机器之间的网络通信不再是一个难题,以GFS/BigTable/MapReduce为代表的分布式系统得以蓬勃发展。
这时,分布式系统特有的通信语义又出现了,如熔断策略、负载均衡、服务发现、认证和授权、quota限制、trace和监控等等,于是服务根据业务需求来实现一部分所需的通信语义。
为了避免每个服务都需要自己实现一套分布式系统通信的语义功能,随着技术的发展,一些面向微服务架构的开发框架出现了,如Twitter的Finagle、Facebook的Proxygen以及Spring Cloud等等,这些框架实现了分布式系统通信需要的各种通用语义功能:如负载均衡和服务发现等,因此一定程度上屏蔽了这些通信细节,使得开发人员使用较少的框架代码就能开发出健壮的分布式系统。
第二代微服务模式看似完美,但开发人员很快又发现,它也存在一些本质问题:
因此以Linkerd,Envoy,Ngixmesh为代表的代理模式(边车模式)应运而生,这就是第一代Service Mesh,它将分布式服务的通信抽象为单独一层,在这一层中实现负载均衡、服务发现、认证授权、监控追踪、流量控制等分布式系统所需要的功能,作为一个和服务对等的代理服务,和服务部署在一起,接管服务的流量,通过代理之间的通信间接完成服务之间的通信请求,这样上边所说的三个问题也迎刃而解。
如果我们从一个全局视角来看,就会得到如下部署图:
如果我们暂时略去服务,只看Service Mesh的单机组件组成的网络:
相信现在,大家已经理解何所谓Service Mesh,也就是服务网格了。它看起来确实就像是一个由若干服务代理所组成的错综复杂的网格。
第一代Service Mesh由一系列独立运行的单机代理服务构成,为了提供统一的上层运维入口,演化出了集中式的控制面板,所有的单机代理组件通过和控制面板交互进行网络拓扑策略的更新和单机数据的汇报。这就是以Istio为代表的第二代Service Mesh。
在新一代的ServiceMesh架构中(下图上方),服务的消费方和提供方主机(或者容器)两边都会部署代理SideCar。ServiceMesh比较正式的术语也叫数据面板(DataPlane),与数据面板对应的还有一个独立部署的控制面板(ControlPlane),用来集中配置和管理数据面板,也可以对接各种服务发现机制(如K8S服务发现)。术语数据面板和控制面板,估计是偏网络SDN背景的人提出来的。
在Service Mesh架构中,给每一个微服务实例部署一个Sidecar Proxy。该Sidecar Proxy负责接管对应服务的入流量和出流量,并将微服务架构中的服务订阅、服务发现、熔断、限流、降级、分布式跟踪等功能从服务中抽离到该Proxy中。
Sidecar以一个独立的进程启动,可以每台宿主机共用同一个Sidecar进程,也可以每个应用独占一个Sidecar进程。所有的服务治理功能,都由Sidecar接管,应用的对外访问仅需要访问Sidecar即可。当该Sidecar在微服务中大量部署时,这些Sidecar节点自然就形成了一个服务网格。
上图左下角,每个主机上同时居住了业务逻辑代码(绿色表示)和代理(蓝色表示),服务之间通过代理发现和调用目标服务,形成服务之间的一种网络状依赖关系,控制面板则可以配置这种依赖调用关系,也可以调拨路由流量。如果我们把主机和业务逻辑剥离,就出现一种网格状架构(上图右下角),服务网格由此得名。
只看单机代理组件(数据面板)和控制面板的Service Mesh全局部署视图如下:
第一代Service Mesh的代表为Linkerd和Envoy。Linkerd基于Twitter的Fingle,使用Scala编写,是业界第一个开源的Service Mesh方案,在长期的实际生产环境中获得验证。Envoy底层基于C++,性能上优于使用Scala的Linkerd。同时,Envoy社区成熟度较高,商用稳定版本面世时间也较长。这两个开源实现都是以Sidecar为核心,绝大部分关注点都是如何做好Proxy,并完成一些通用控制面的功能。但是当你在容器中大量部署Sidecar以后,如何管理和控制这些Sidecar本身就是一个不小的挑战。
第二代Service Mesh主要改进集中在更加强大的控制面功能(与之对应的Sidecar Proxy被称之为数据面),典型代表有Istio和Conduit。Istio是Google、IBM和Lyft合作的开源项目,是目前最主流的Service Mesh方案,也是事实上的第二代Service Mesh标准。在Istio中,直接把Envoy作为Sidecar。除了Sidecar,Istio中的控制面组件都是使用Go语言编写。
Istio[附录4]是Google/IBM等大厂支持和推进的一个ServiceMesh标准化工作组,上图是Istio给出的ServiceMesh参考架构。
Istio专注在控制面板的架构、功能、以及控制面板和数据面板之间API的标准化,它的控制面板功能主要包括:
Istio-Manager
负责服务发现,路由分流,熔断限流等配置数据的管理和下发
Mixer
负责收集代理上采集的度量数据,进行集中监控
Istio-Auth
负责安全控制数据的管理和下发
提供强大的服务间认证和终端用户认证,使用交互TLS,内置身份和证书管理。可以升级服务网格中的未加密流量,并为运维人员提供基于服务身份而不是网络控制来执行策略的能力。Istio的未来版本将增加细粒度的访问控制和审计,以使用各种访问控制机制(包括基于属性和角色的访问控制以及授权钩子)来控制和监视访问服务、API或资源的访问者。
Istio的设计理念先进,功能也比较强大,加之Google、IBM的影响力让Istio迅速传播,让广大开发者认识到了Istio项目在Service Mesh领域的重要性。但是Istio目前版本也存在了一些不足:
目前的Istio大部分能力与Kubernetes是强关联的。而我们在构建微服务的时候往往是希望服务层与容器层是解耦的,服务层在设计上需要能够对接多种容器层平台。
Istio至今未有稳定版本,截至本文编写时为止,Istio的最新版本为0.8版本,预计在2018年内会发布1.0版本。
其他主要组件:
Envoy
扮演Sidecar的功能,协调服务网格中所有服务的出入站流量,并提供服务发现、负载均衡、限流熔断等能力,还可以收集与流量相关的性能指标。
Envoy[附录5]是目前Istio主力支持的数据面板代理,其它主流代理如nginx/kong等也正在陆续加入这个阵营。kubernetes是目前Isito主力支持的容器云环境。
Pilot
负责部署在Service Mesh中的Envoy实例的生命周期管理。本质上是负责流量管理和控制,将流量和基础设施扩展解耦,这是Istio的核心。可以把Pilot看做是管理Sidecar的Sidecar, 但是这个特殊的Sidacar并不承载任何业务流量。Pilot让运维人员通过Pilot指定它们希望流量遵循什么规则,而不是哪些特定的pod/VM应该接收流量。有了Pilot这个组件,我们可以非常容易的实现 A/B 测试和金丝雀Canary测试。
我们再来看一下Conduit的实现,下图是Conduit的架构设计图,其中重点由Conduit Data Plane和Conduit Control Plane两部分组成:
Conduit各方面的设计理念与Istio非常类似,作者使用Rust语言重新编写了Sidecar, 叫做Conduit Data Plane, 控制面则由Go语言编写的Conduit Control Plane接管。从Conduit的架构看,作者号称Conduit吸取了很多Linkerd的教训,比Linkerd更快、更轻、更简单,控制面功能更强。与Istio比较,Conduit的架构一方面比较简单,另一方面对于要解决的问题足够聚焦。
目前我本人并不特别看好ServiceMesh,也不是特别建议企业在生产上试水ServiceMesh,主要原因如下:
所以我的个人建议,对于大部分企业(一般运维和研发能力不是特别强),采用模式一~集中代理模式就足够了。这个模式比较传统不新鲜,但是在很多一线企业已经切实落地,我甚至认为,除了一些大厂,大部分中小企业的服务发现架构采用的就是集中代理。我本人经历过三家互联网公司,大的有eBay,中等有携程,小的有拍拍贷,都是采用集中式代理模式,而且玩得都很好。我的架构理念很简单,对于生产级应用,不追新,老实采用大部分企业落地过的方案。
模式一的最大好处是集中治理,应用不侵入,语言栈无关,另外因为模式一是集中部署的,不像模式三是分布式部署,所以模式一的运维开销也远小于模式三。对于模式一,大家最大的顾虑是性能和单点问题,其实性能还是OK的,如果架构和容量规划合理的话,实际生产中经过集中代理的性能开销一般可以控制在小于10个ms,eBay和携程等大流量企业的成功实践已经验证了这点。单点问题一般建议采用两层负载结构,例如硬件F5+软件nginx两层负载,F5以主从HA部署,nginx则以集群多实例部署,这种架构兼顾了高可用和配置的灵活性。
另外,模式一还可以和服务注册中心结合,从而降低手工配置的复杂性,实现DevOps研发自助部署,一种方案如下图所示:
服务启动时自动注册到服务注册中心并定期报心跳,Proxy则定期到服务注册中心同步实例。这种方式下,不需要为每个服务申请一个域名,只需一个泛域名即可,消费者访问服务时采用服务名+泛域名即可,整个服务上线流程可以做到DevOps研发自助。目前社区流行的一些开源代理如traefik[附录7]和kong[附录8]等都支持和多种服务注册中心(Consul/Eureka/Etcd/Zookeeper等)进行集成。目前这种方案在拍拍贷有初步成功实践,采用kong[附录7]和自研服务注册中心Radar[附录8],同时和容器云调度平台配合,实现了研发全自助式发布上线。
至此,见证了6个时代的变迁,大家一定清楚了Service Mesh技术到底是什么,以及是如何一步步演化到今天这样一个形态。
现在,我们再回过头来看Buoyant的CEO William Morgan,也就是Service Mesh这个词的发明人,对Service Mesh的定义:
服务网格是一个基础设施层,用于处理服务间通信。云原生应用有着复杂的服务拓扑,服务网格保证请求在这些拓扑中可靠地穿梭。在实际应用当中,服务网格通常是由一系列轻量级的网络代理组成的,它们与应用程序部署在一起,但对应用程序透明。
这个定义中,有四个关键词:
总结一下,Service Mesh具有如下优点:
当然,Service Mesh目前也面临一些挑战:
Serverless被翻译为“无服务器架构”,这个概念在2012年时便已经存在,比微服务和Service Mesh的概念出现都要早,但是直到微服务概念大红大紫之后,Serverless才重新又被人们所关注。
Serverless(无服务器架构)并不意味着没有任何服务器去运行代码,Serverless是无需管理服务器,只需要关注代码,而提供者将处理其余部分工作。
“无服务器架构”也可以指部分服务器端逻辑依然由应用程序开发者来编写的应用程序,但与传统架构的不同之处在于,这些逻辑运行在完全由第三方管理,由事件触发的无状态(Stateless)暂存于计算容器内。
对于开发者来说,Serverless架构可以将其服务器端应用程序分解成多个执行不同任务的函数,整个应用分为几个独立、松散耦合的组件,这些组件可以在任何规模上运行。
下图为一种常见的Serverless架构图,所有的服务都以FaaS(函数即服务)的方式对外进行提供。在语言和环境方面,FaaS 函数就是常规的应用程序,例如使用JavaScript、Python以及 Java等语言实现。
云计算涌现出很多改变传统IT架构和运维方式的新技术,比如虚拟机、容器、微服务,无论这些技术应用在哪些场景,降低成本、提升效率是云服务永恒的主题。
过去十年来,我们已经把应用和环境中很多通用的部分变成了服务。Serverless的出现,带来了跨越式变革。Serverless把主机管理、操作系统管理、资源分配、扩容,甚至是应用逻辑的全部组件都外包出去,把它们看作某种形式的商品——厂商提供服务,我们掏钱购买。
过去是“构建一个框架运行在一台服务器上,对多个事件进行响应”,Serverless则变为“构建或使用一个微服务或微功能来响应一个事件”,做到当访问时,调入相关资源开始运行,运行完成后,卸载所有开销,真正做到按需按次计费。这是云计算向纵深发展的一种自然而然的过程。
Serverless是一种构建和管理基于微服务架构的完整流程,允许你在服务部署级别而不是服务器部署级别来管理你的应用部署。
它与传统架构的不同之处在于,完全由第三方管理,由事件触发,存在于无状态(Stateless)、暂存(可能只存在于一次调用的过程中)计算容器内。构建无服务器应用程序意味着开发者可以专注在产品代码上,而无须管理和操作云端或本地的服务器或运行时。Serverless真正做到了部署应用无需涉及基础设施的建设,自动构建、部署和启动服务。
国内外的各大云厂商 Amazon、微软、Google、IBM、阿里云、腾讯云、华为云相继推出Serverless产品,Serverless也从概念、愿景逐步走向落地,在各企业、公司应用开来。
Serverless由开发者实现的服务端逻辑运行在无状态的计算容器中,它由事件触发, 完全被第三方管理,其业务层面的状态则被开发者使用的数据库和存储资源所记录。Serverless涵盖了很多技术,分为两类:FaaS和BaaS。
FaaS意在无须自行管理服务器系统或自己的服务器应用程序,即可直接运行后端代码。其中所指的服务器应用程序,是该技术与容器和PaaS(平台即服务)等其他现代化架构最大的差异。
FaaS可以取代一些服务处理服务器(可能是物理计算机,但绝对需要运行某种应用程序),这样不仅不需要自行供应服务器,也不需要全时运行应用程序。
FaaS产品不要求必须使用特定框架或库进行开发。在语言和环境方面,FaaS函数就是常规的应用程序。例如AWS Lambda的函数可以通过Javascript、Python以及任何JVM语言(Java、Clojure、Scala)等实现。然而Lambda函数也可以执行任何捆绑有所需部署构件的进程,因此可以使用任何语言,只要能编译为Unix进程即可。FaaS函数在架构方面确实存在一定的局限,尤其是在状态和执行时间方面。
在迁往FaaS的过程中,唯一需要修改的代码是“主方法/启动”代码,其中可能需要删除顶级消息处理程序的相关代码(“消息监听器接口”的实现),但这可能只需要更改方法签名即可。在FaaS的世界中,代码的其余所有部分(例如向数据库执行写入的代码)无须任何变化。
相比传统系统,部署方法会有较大变化 – 将代码上传至FaaS供应商,其他事情均可由供应商完成。目前这种方式通常意味着需要上传代码的全新定义(例如上传zip或JAR文件),随后调用一个专有API发起更新过程。
FaaS中的函数可以通过供应商定义的事件类型触发。对于亚马逊AWS,此类触发事件可以包括S3(文件)更新、时间(计划任务),以及加入消息总线的消息(例如Kinesis)。通常你的函数需要通过参数指定自己需要绑定到的事件源。
大部分供应商还允许函数作为对传入Http请求的响应来触发,通常这类请求来自某种该类型的API网关(例如AWS API网关、Webtask)。
BaaS(Backend as a Service,后端即服务)是指我们不再编写或管理所有服务端组件,可以使用领域通用的远程组件(而不是进程内的库)来提供服务。理解BaaS,需要搞清楚它与PaaS的区别。
首先BaaS并非PaaS,它们的区别在于:PaaS需要参与应用的生命周期管理,BaaS则仅仅提供应用依赖的第三方服务。典型的PaaS平台需要提供手段让开发者部署和配置应用,例如自动将应用部署到Tomcat容器中,并管理应用的生命周期。BaaS不包含这些内容,BaaS只以API的方式提供应用依赖的后端服务,例如数据库和对象存储。BaaS可以是公共云服务商提供的,也可以是第三方厂商提供的。其次从功能上讲,BaaS可以看作PaaS的一个子集,即提供第三方依赖组件的部分。
BaaS服务还允许我们依赖其他人已经实现的应用逻辑。对于这点,认证就是一个很好的例子。很多应用都要自己编写实现注册、登录、密码管理等逻辑的代码,而对于不同的应用这些代码往往大同小异。完全可以把这些重复性的工作提取出来,再做成外部服务,而这正是Auth0和Amazon Cognito等产品的目标。它们能实现全面的认证和用户管理,开发团队再也不用自己编写或者管理实现这些功能的代码。
与使用虚拟机或一些底层的技术来部署和管理应用程序相比,无服务器计算提供了一种更高级别的抽象。因为它们有不同的抽象和“触发器”的集合。
拿计算来讲,这种抽象有一个特定函数和抽象的触发器,它通常是一个事件。以数据库为例,这种抽象也许是一个表,而触发器相当于表的查询或搜索,或者通过在表中做一些事情而生成的事件。
比如一款手机游戏,允许用户在不同的平台上为全球顶级玩家使用高分数表。当请求此信息时,请求从应用程序到API接口。API接口或许会触发AWS的Lambda函数,或者无服务器函数,这些函数再从数据库表中获取到数据流,返回包含前五名分数的一定格式的数据。
一旦构建完成,应用程序的功能就可以在基于移动和基于 Web 的游戏版本中重用。
这跟设置服务器不同,不是必须要有Amazon EC2实例或服务器,然后等待请求。环境由事件触发,而响应事件所需的逻辑只在响应时执行。这意味着,运行函数的资源只有在函数运行时被创建,产生一种非常高效的方法来构建应用程序。
在现阶段,Serverless主要应用在以下几个场景
Serverless 应用成功与否的评判标准并不是公司规模的大小,而是其业务背后的具体技术问题,比如业务波峰波谷明显,如何实现削峰填谷。一个公司的业务负载具有波峰波谷时,机器资源要按照峰值需求预估;而在波谷时期机器利用率则明显下降,因为不能进行资源复用而导致浪费。
业界普遍共识是,当自有机器的利用率小于 30%,使用 Serverless 后会有显著的效率提升。对于云服务厂商,在具备了足够多的用户之后,各种波峰波谷叠加后平稳化,聚合之后资源复用性更高。比如,外卖企业负载高峰是在用餐时期,安防行业的负载高峰则是夜间,这是受各个企业业务定位所限的;而对于一个成熟的云服务厂商,如果其平台足够大,用户足够多,是不应该有明显的波峰波谷现象的。
视频处理的后端系统,常见功能需求如下:视频转码、抽取数据、人脸识别等,这些均为通用计算任务,可由函数计算执行。
开发者需要自己写出实现逻辑,再将任务按照控制流连接起来,每个任务的具体执行由云厂商来负责。如此,开发变得更便捷,并且构建的系统天然高可用、实时弹性伸缩,用户不需要关心机器层面问题。
缩短交付时间
Serverless架构允许开发人员在极短时间内(几小时、几天)交付新的应用程序,而不是像以前一样需要几个星期或几个月。在新的应用程序中,依赖于第三方API提供服务的例子很多,如认证(OAuth)、社交、地图、人工智能等。
增强可伸缩性
所有人都希望自己开发的应用能够快速获取大量的新增用户,但是当活跃用户快速增长的时候,服务器的压力也会激增。使用Serverless架构的体系不再有上述担忧,可以及时、灵活进行扩展来应对快速增长的活跃用户带来的访问压力。
降低成本
Serverless架构模式可以降低计算能力和人力资源方面的成本,如果不需要服务器,就不用花费时间重新造轮子、风险监测、图像处理,以及基础设施管理,操作成本会直线下降。
改善用户体验
用户通常不太关心基础设施,而更注重于功能和用户体验。Serverless架构允许团队将资源集中在用户体验上。
减少延迟及优化地理位置信息
应用规模能力取决于三个方面:用户数量、所在位置及网络延迟。当应用要面向全国甚至全球用户的时候,通常会产生较高的延迟,从而降低用户体验。在Serverless架构下,供应商在每个用户附近都有节点,大幅度降低了访问延迟,因此所有用户的体验都可以得到提升。
对于企业来说,支持Serverless计算的平台可以节省大量时间和成本,同时可以释放员工,让开发者得以开展更有价值的工作,而不是管理基础设施。另一方面可以提高敏捷度,更快速地推出新应用和新服务,进而提高客户满意度。但是Serverless不是完美的,它也存在一些问题,需要慎重应用在生产环境。
Serverless 在请求到来时才运行。这意味着,当应用不运行的时候就会进入 “休眠状态”,下次当请求来临时,应用将会需要一个启动时间,即冷启动时间。如果你的应用需要一直长期不间断的运行、处理大量的请求,那么你可能就不适合采用 Serverless 架构。如果你通过 CRON 的方式或者 CloudWatch 来定期唤醒应用,又会比较消耗资源。这就需要我们对它做优化,如果频繁调用,这个资源将会常驻内存,第一次冷启之后,就可以一直服务,直到一段时间内没有新的调用请求进来,则会转入“休眠”状态,甚至被回收,从而不消耗任何资源。
当你所在的企业云环境已经有大量的基础设施的时候,Serverless 对于你来说,并不是一个好东西。当我们采用某云服务厂商的 Serverless 架构时,我们就和该服务供应商绑定了,那么我们再将服务迁到别的云服务商上就没有那么容易了。
我们需要修改一下系列的底层代码,能采取的应对方案,便是建立隔离层。这意味着,在设计应用的时候,就需要隔离 API 网关、隔离数据库层,考虑到市面上还没有成熟的 ORM 工具,让你既支持Firebase,又支持 DynamoDB等等。这些也将带给我们一些额外的成本,可能带来的问题会比解决的问题多。
当我使用 Serverless Framework 的时候,遇到了这样的问题:缺乏调试和开发工具。后来,我发现了 serverless-offline、dynamodb-local 等一系列插件之后,问题有一些改善。然而,对于日志系统来说,这仍然是一个艰巨的挑战。
每次你调试的时候,你需要一遍又一遍地上传代码。而每次上传的时候,你就好像是在部署服务器,并不能总是快速地定位出问题在哪。后来,找了一个类似于 log4j 这样的可以分级别记录日志的 Node.js 库 winston。它可以支持 error、warn、info、verbose、debug、silly 六个不同级别的日志,再结合大数据进行日志分析过滤,才能快速定位问题。
Serverless 很便宜,但是这并不意味着它很简单。AWS Lambda的 CloudFormation配置是如此的复杂,并且难以阅读及编写(JSON 格式),虽然CloudFomation提供了Template模板,但想要使用它的话,需要创建一个Stack,在Stack中指定你要使用的Template,然后aws才会按照Template中的定义来创建及初始化资源。
而Serverless Framework的配置更加简单,采用的是 YAML 格式。在部署的时候,Serverless Framework 会根据我们的配置生成 CloudFormation 配置。然而这也并非是一个真正用于生产的配置,真实的应用场景远远比这复杂。
Service Mesh
对于大规模部署微服务,内部服务异构程度高的场景,使用Service Mesh方案是一个不错的选择。Service Mesh实现了业务逻辑和控制的解耦,但是也带来了额外的开销,由于网络中多了一跳,增加了性能的损耗和访问的延迟。同时,由于每个服务都需要部署Sidecar, 这也会使本来就具有一定复杂度的分布式系统变得更加复杂。尤其是在实施初期,对Service Mesh的管理和运维会是一个棘手的问题。因此,当我们选择使用Service Mesh架构的时候,需要对具体的Service Mesh实现方案(例如:Istio)做好充分的技术准备和经验积累工作,方能确保方案的顺利实施。
Serverless
在微服务与容器技术火热之后,Serverless(无服务器架构)成为新的热点,无服务器云函数可以让用户无需关心服务器的部署运营,只需开发最核心的业务逻辑,即可实现上线运营,具备分布容灾能力,可以依据负载自动扩缩容,并按照实际调用次数与时长计费。
使用Serverless架构可以免除所有运维性操作,开发人员可以更加专注于核心业务的开发,实现快速上线和迭代,把握业务发展的节奏。Serverless架构可以认为是对微服务和容器化的一种补充,为用户提供了一种新的选择,来应对复杂多变的需求,尤其适合快速发展的初创型公司。
Netflix Eureka https://github.com/netflix/eureka
Netflix Ribbon https://github.com/netflix/ribbon
Airbnb SmartStack https://medium.com/airbnb-engineering/smartstack-service-discovery-in-the-cloud-4b8a080de619
Istio https://istio.io/
Envoy https://www.envoyproxy.io/
Traefik https://github.com/containous/traefik
Kong https://github.com/kong/kong
Radar https://github.com/ppdai-incubator/radar
文章浏览阅读1.6k次。安装配置gi、安装数据库软件、dbca建库见下:http://blog.csdn.net/kadwf123/article/details/784299611、检查集群节点及状态:[root@rac2 ~]# olsnodes -srac1 Activerac2 Activerac3 Activerac4 Active[root@rac2 ~]_12c查看crs状态
文章浏览阅读1.3w次,点赞45次,收藏99次。我个人用的是anaconda3的一个python集成环境,自带jupyter notebook,但在我打开jupyter notebook界面后,却找不到对应的虚拟环境,原来是jupyter notebook只是通用于下载anaconda时自带的环境,其他环境要想使用必须手动下载一些库:1.首先进入到自己创建的虚拟环境(pytorch是虚拟环境的名字)activate pytorch2.在该环境下下载这个库conda install ipykernelconda install nb__jupyter没有pytorch环境
文章浏览阅读5.2k次,点赞19次,收藏28次。选择scoop纯属意外,也是无奈,因为电脑用户被锁了管理员权限,所有exe安装程序都无法安装,只可以用绿色软件,最后被我发现scoop,省去了到处下载XXX绿色版的烦恼,当然scoop里需要管理员权限的软件也跟我无缘了(譬如everything)。推荐添加dorado这个bucket镜像,里面很多中文软件,但是部分国外的软件下载地址在github,可能无法下载。以上两个是官方bucket的国内镜像,所有软件建议优先从这里下载。上面可以看到很多bucket以及软件数。如果官网登陆不了可以试一下以下方式。_scoop-cn
文章浏览阅读4.5k次,点赞2次,收藏3次。首先要有一个color-picker组件 <el-color-picker v-model="headcolor"></el-color-picker>在data里面data() { return {headcolor: ’ #278add ’ //这里可以选择一个默认的颜色} }然后在你想要改变颜色的地方用v-bind绑定就好了,例如:这里的:sty..._vue el-color-picker
文章浏览阅读640次。基于芯片日益增长的问题,所以内核开发者们引入了新的方法,就是在内核中只保留函数,而数据则不包含,由用户(应用程序员)自己把数据按照规定的格式编写,并放在约定的地方,为了不占用过多的内存,还要求数据以根精简的方式编写。boot启动时,传参给内核,告诉内核设备树文件和kernel的位置,内核启动时根据地址去找到设备树文件,再利用专用的编译器去反编译dtb文件,将dtb还原成数据结构,以供驱动的函数去调用。firmware是三星的一个固件的设备信息,因为找不到固件,所以内核启动不成功。_exynos 4412 刷机
文章浏览阅读2w次,点赞24次,收藏42次。Linux系统配置jdkLinux学习教程,Linux入门教程(超详细)_linux配置jdk
文章浏览阅读3.3k次,点赞5次,收藏19次。xlabel('\delta');ylabel('AUC');具体符号的对照表参照下图:_matlab微米怎么输入
文章浏览阅读119次。顺序读写指的是按照文件中数据的顺序进行读取或写入。对于文本文件,可以使用fgets、fputs、fscanf、fprintf等函数进行顺序读写。在C语言中,对文件的操作通常涉及文件的打开、读写以及关闭。文件的打开使用fopen函数,而关闭则使用fclose函数。在C语言中,可以使用fread和fwrite函数进行二进制读写。 Biaoge 于2024-03-09 23:51发布 阅读量:7 ️文章类型:【 C语言程序设计 】在C语言中,用于打开文件的函数是____,用于关闭文件的函数是____。
文章浏览阅读3.4k次,点赞2次,收藏13次。跟随鼠标移动的粒子以grid(SOP)为partical(SOP)的资源模板,调整后连接【Geo组合+point spirit(MAT)】,在连接【feedback组合】适当调整。影响粒子动态的节点【metaball(SOP)+force(SOP)】添加mouse in(CHOP)鼠标位置到metaball的坐标,实现鼠标影响。..._touchdesigner怎么让一个模型跟着鼠标移动
文章浏览阅读178次。项目运行环境配置:Jdk1.8 + Tomcat7.0 + Mysql + HBuilderX(Webstorm也行)+ Eclispe(IntelliJ IDEA,Eclispe,MyEclispe,Sts都支持)。项目技术:Springboot + mybatis + Maven +mysql5.7或8.0+html+css+js等等组成,B/S模式 + Maven管理等等。环境需要1.运行环境:最好是java jdk 1.8,我们在这个平台上运行的。其他版本理论上也可以。_基于java技术的停车场管理系统实现与设计
文章浏览阅读3.5k次。前言对于MediaPlayer播放器的源码分析内容相对来说比较多,会从Java-&amp;gt;Jni-&amp;gt;C/C++慢慢分析,后面会慢慢更新。另外,博客只作为自己学习记录的一种方式,对于其他的不过多的评论。MediaPlayerDemopublic class MainActivity extends AppCompatActivity implements SurfaceHolder.Cal..._android多媒体播放源码分析 时序图
文章浏览阅读2.4k次,点赞41次,收藏13次。java 数据结构与算法 ——快速排序法_快速排序法