Browsed by
作者:CoolShell

Serverless 与容器决战在即?有了弹性伸缩就不一样了

Serverless 与容器决战在即?有了弹性伸缩就不一样了

閱讀本文約花費: 16 (分鐘)导读:Serverless 和 Autoscaling 是近些年来广大开发者非常关心的内容。有人说 Serverless 是容器 2.0,终有一天容器会和 Serverless 进行一场决战,分出胜负。实际上,容器和 Serverless 是可以共存并且互补的,特别是在 Autoscaling 相关的场景下,Serverless 可以与容器完美兼容,弥补容器场景在使用简单、速度、成本的缺欠。 当我们在谈论”弹性伸缩”的时候 当我们在谈论”弹性伸缩”的时候,我们在谈论什么?”弹性伸缩”对于团队中不同的角色有不同的意义,而这正是弹性伸缩的魅力所在。 从一张资源曲线图讲起 这张图是阐述弹性伸缩问题时经常引用的一张图,表示的是集群的实际资源容量和应用所需容量之间的关系。 其中红色的曲线表示的是应用实际所需的容量,因为应用的资源申请量相比节点而言会小很多,因此曲线相对比较平滑; 而绿色的折线表示的是集群的实际资源容量,折线的拐点表明此时进行了手动的容量调整,例如增加节点或者移除节点,因为单个节点的资源容量固定且相对较大,因此以折线为主。 首先,我们先看左侧第一块黄色栅格的区域,这个区域表示集群的容量无法满足业务的容量所需,在实际的场景中,通常会伴随出现由于资源不足而无法调度的 Pod 等现…

Read More Read More

微服务架构下的分布式限流方案全解析

微服务架构下的分布式限流方案全解析

閱讀本文約花費: 9 (分鐘)1.微服务限流 随着微服务的流行,服务和服务之间的稳定性变得越来越重要。缓存、降级和限流是保护微服务系统运行稳定性的三大利器。 缓存的目的是提升系统访问速度和增大系统能处理的容量,而降级是当服务出问题或者影响到核心流程的性能则需要暂时屏蔽掉,待高峰或者问题解决后再打开,而有些场景并不能用缓存和降级来解决,比如稀缺资源、数据库的写操作、频繁的复杂查询,因此需有一种手段来限制这些场景的请求量,即限流。 比如当我们设计了一个函数,准备上线,这时候这个函数会消耗一些资源,处理上限是1秒服务3000个QPS,但如果实际情况遇到高于3000的QPS该如何解决呢? 所以限流的目的应当是通过对并发访问/请求进行限速或者一个时间窗口内的的请求进行限速来保护系统,一旦达到限制速率就可以拒绝服务、等待、降级。 学习如何去实现一个分布式限流框架,首先,我们需要去了解最基本的两种限流算法。 2.限流算法 2.1漏桶算法 漏桶算法思路很简单,水(也就是请求)先进入到漏桶里,漏桶以一定的速度出水,当水流入速度过大会直接溢出,然后就拒绝请求,可以看出漏桶算法能强行限制数据的传输速率。示意图(来源网络)如下: 2.2令牌桶算法 令牌桶算法和漏桶算法效果一样但方向相反的算法,更加容易理解。随着时间流逝,系统会按恒定1/QPS时间间隔(如果QPS=100,则间隔是10ms)往桶里加入令牌(…

Read More Read More

Java 应用性能调优实践

Java 应用性能调优实践

閱讀本文約花費: 24 (分鐘)Java 应用性能优化是一个老生常谈的话题,典型的性能问题如页面响应慢、接口超时,服务器负载高、并发数低,数据库频繁死锁等。尤其是在”糙快猛”的互联网开发模式大行其道的今天,随着系统访问量的日益增加和代码的臃肿,各种性能问题开始纷至沓来。Java 应用性能的瓶颈点非常多,比如磁盘、内存、网络 I/O 等系统因素,Java 应用代码,JVM GC,数据库,缓存等。笔者根据个人经验,将 Java 性能优化分为 4 个层级:应用层、数据库层、框架层、JVM 层,如图 1 所示。 图 1.Java 性能优化分层模型 每层优化难度逐级增加,涉及的知识和解决的问题也会不同。比如应用层需要理解代码逻辑,通过 Java 线程栈定位有问题代码行等;数据库层面需要分析 SQL、定位死锁等;框架层需要懂源代码,理解框架机制;JVM 层需要对 GC 的类型和工作机制有深入了解,对各种 JVM 参数作用了然于胸。 围绕 Java 性能优化,有两种最基本的分析方法:现场分析法和事后分析法。现场分析法通过保留现场,再采用诊断工具分析定位。现场分析对线上影响较大,部分场景(特别是涉及到用户关键的在线业务时)不太合适。事后分析法需要尽可能多收集现场数据,然后立即恢复服务,同时针对收集的现场数据进行事后分析和复现。下面我们从性能诊断工具出发,分享搜狗商业平台在其中的一些案例与实践。 性…

Read More Read More

SpringCloud之Ribbon负载均衡的入门操作

SpringCloud之Ribbon负载均衡的入门操作

閱讀本文約花費: 6 (分鐘)使用Ribbon进行负载均衡 在使用Ribbon之前,我们先想一个之前的问题,之前我们将服务提供者注册进了eureka注册中心,但是在消费者端,我们还是使用的restTemplate调用的时候,其中写的还是http://localhost:8001这样的调用方式,是不是有一些不妥呢?是不是应用像dubbo那样,使用服务名进行调用呢?不然,我们使用注册中心有什么用呢? 好的呢,我们先保留这个思考 。来进入Ribbon的学习 什么是Ribbon? Ribbon [?r?b?n] ,是SpringCloud Netflix中的一个关于客户端的负载均衡插件。 主要解释如下: 这个客户端主要是指服务消费者,也就是说,这个插件是用在消费者端的,它自己会根据一些算法对相同服务的提供者(也就是这几个服务提供者的application.name要相同)进行甄别,自己决定我要访问哪一个服务者。 而Nginx是整个服务器的负载均衡,当浏览器等设备的访问请求进来后,它会根据自身的配置,进行服务的路径选择。 Ribbon的集成(客户端,即消费者) 上边说了,是在消费端进行的负载均衡,所以要修改cousumer端,但为了方便学习,我就新创建了一个项目,demo3-ribbon-consumer,代码和之前的没什么太大的变化。而且,要有多个相同名称的服务提供者才能进行负载均衡,才能…

Read More Read More

SpringCloud-Ribbon[入门案例]

SpringCloud-Ribbon[入门案例]

閱讀本文約花費: 4 (分鐘)一、 Ribbon 在微服务中的作用 1 什么是 Ribbon Ribbon 是一个基于 Http 和 TCP 的客服端负载均衡工具,它是基于 Netflix Ribbon 实现的。 它不像 spring cloud 服务注册中心、配置中心、API 网关那样独立部署,但是它几乎存在于每个 spring cloud 微服务中。包括 feign 提供的声明式服务调用也是基于该 Ribbon实现的。 ribbon 默认提供很多种负载均衡算法,例如 轮询、随机 等等。甚至包含自定义的负载均衡算法。 2 Ribbon 解决了什么问题 他解决并提供了微服务的负载均衡的问题。 二、 集中式与进程内负载均衡的区别 1 负载均衡解决方案的分类 目前业界主流的负载均衡方案可分成两类: 第一类:集中式负载均衡, 即在 consumer 和 provider 之间使用独立的负载均衡设施(可以是硬件,如 F5, 也可以是软件,如 nginx), 由该设施负责把 访问请求 通过某种策略转发至 provider; 第二类:进程内负载均衡,将负载均衡逻辑集成到 consumer,consumer 从服务注册中心获知有哪些地址可用,然后自己再从这些地址中选择出一个合适的 provider。Ribbon 就属于后者,它只是一个类库,集成于 consumer 进程,consumer 通过它…

Read More Read More

Service Mesh Is Still Hard

Service Mesh Is Still Hard

閱讀本文約花費: 5 (分鐘)KubeCon + CloudNativeCon NA Virtual sponsor guest post from Lin Sun, Senior Technical Staff Member at IBM At ServiceMeshCon EU this August, William Morgan from Linkerd and I gave a joint talk entitled service mesh is still hard.  William detailed the improvements to Linkerd, while I covered the improvements to Istio.  It’s clear both projects are working hard to make it easier for users to adopt service mesh. Service mesh is more mature than it was one or two years ago, however, it’s still hard for users.  There are two types of …

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

项目架构之传统三层架构和领域模型三层架构

项目架构之传统三层架构和领域模型三层架构

閱讀本文約花費: 18 (分鐘)一、工程结构 本系列文章所示范的项目基于传统三层架构进行分层,基于工作职责和Maven结构进行模块划分。本文将对传统三层架构和对应的领域模型架构、以及每个模块的职责进行简单的说明。下图即示范项目的模块结构: 二、架构之传统三层架构 传统三层架构是一种软件架构,是一种典型的、基于贫血模型的、面向过程的JavaWeb分层方式。该架构分为以下三个层次: 数据访问层(DAL – Data Access Layer)即对包括数据库在内的数据源进行操作的部分。 业务逻辑层(BLL – Business Logic Layer)即对业务数据进行逻辑处理的部分。 表现层(UI – User Interface)即与用户交互的部分。 分层的目的是为了解耦和明确责任。开发人员可以只关心自己所负责的那一层,因为他只需要知道上一层提供了哪些接口,从而利用这些接口进行编程。而上一层的开发人员在不改变接口的情况下,可以任意地替换具体的实现,从而实现松耦合。 相比更传统的架构,三层架构有着明显的优势,但也有不可忽视的缺点。初期的JavaWeb在JSP内同时进行数据库读写、业务逻辑处理和页面渲染,简单而暴力。而今的架构,在JSP之上增加了一个处理业务逻辑的中间层和一个封装了数据库操作的数据访问层,毫无疑问造成了代码量的大幅度上升和效率的下降。 本…

Read More Read More

WordPress post和page的区别

WordPress post和page的区别

閱讀本文約花費: 1 (分鐘)  wordpress博客主要有两部分构成posts和pages,但是对于wordpress初学者来说,经常把这两个概念混淆。在post和page之间有很多不同点,知道并理解这些不同点,能够让我们更好的使用wordpress中的pages和posts。 post的特点: 1、post通常按发布时间倒序排列 2、post经常被更新,需要显示发布时间 3、可以通过标签和分类来组织post 4、post会出现在Rss订阅中 page的特点: 1、博客中的page页面独立于post显示,通常很少发生变动 2、通常使用page来和读者分享信息,但是很少去更新它 3、page页面没有发布时间,我们不需要显示page发布的时间 4、根据主题的不同,page可以显示在任何地方 5、page通常按字母排序,但是我们可以改变排序的方式 6、page没有标签和分类 7、page页面不会出现在RSS源中,读者需要访问博客才能看到page页面的更新情况 8、不要在page页面中嵌入Post 9、通过page页面之间的父子关系,可以建立复杂的网站结构 所以像留言板、关于、友链这样的页面喜欢用page,而一般文章则是用post Tags: WordPress, 博客

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

千万级用户的大型网站,应该如何设计其高并发架构?

千万级用户的大型网站,应该如何设计其高并发架构?

閱讀本文約花費: 10 (分鐘)目录 (1)单块架构 (2)初步的高可用架构 (3)千万级用户量的压力预估 (4)服务器压力预估 (5)业务垂直拆分 (6)用分布式缓存抗下读请求 (7)基于数据库主从架构做读写分离 (8)总结 (1)单块架构 一般一个网站刚开始建立的时候,用户量是很少的,大概可能就几万或者几十万的用户量,每天活跃的用户可能就几百或者几千个。 这个时候一般网站架构都是采用单体架构来设计的,总共就部署3台服务器,1台应用服务器,1台数据库服务器,1台图片服务器。 研发团队通常都在10人以内,就是在一个单块应用里写代码,然后写好之后合并代码,接着就是直接在线上的应用服务器上发布。 很可能就是手动把应用服务器上的Tomcat给关掉,然后替换系统的代码war包,接着重新启动Tomcat。 数据库一般就部署在一台独立的服务器上,存放网站的全部核心数据。 然后在另外一台独立的服务器上部署NFS作为图片服务器,存放网站的全部图片。应用服务器上的代码会连接以及操作数据库以及图片服务器。如下图所示: (2)初步的高可用架构 但是这种纯单块系统架构下,有高可用问题存在,最大的问题就是应用服务器可能会故障,或者是数据库可能会故障 所以在这个时期,一般稍微预算充足一点的公司,都会做一个初步的高可用架构出来。 对于应用服务器而言,一般会集群化部署。当然所谓的集群化部署,在初期用户量很少的情况…

Read More Read More

深入解读Service Mesh背后的技术细节

深入解读Service Mesh背后的技术细节

閱讀本文約花費: 14 (分鐘)一、Service Mesh是Kubernetes支撑微服务能力拼图的最后一块 在上一篇文章为什么 kubernetes 天然适合微服务中我们提到,Kubernetes是一个奇葩所在,他的组件复杂,概念复杂,在没有实施微服务之前,你可能会觉得为什么Kubernetes要设计的这么复杂,但是一旦你要实施微服务,你会发现Kubernetes中的所有概念,都是有用的。 在我们微服务设计的是个要点中,我们会发现Kubernetes都能够有相应的组件和概念,提供相应的支持。 其中最后的一块拼图就是服务发现,与熔断限流降级。 众所周知,Kubernetes的服务发现是通过Service来实现的,服务之间的转发是通过kube-proxy下发iptables规则来实现的,这个只能实现最基本的服务发现和转发能力,不能满足高并发应用下的高级的服务特性,比较SpringCloud和Dubbo有一定的差距,于是Service Mesh诞生了,他期望讲熔断,限流,降级等特性,从应用层,下沉到基础设施层去实现,从而使得Kubernetes和容器全面接管微服务。 二、以Istio为例讲述Service Mesh中的技术关键点 就如SDN一样,Service Mesh将服务请求的转发分为控制面和数据面,因而分析他,也是从数据面先分析转发的能力,然后再分析控制面如何下发命令。今天这篇…

Read More Read More

浅谈领域模型

浅谈领域模型

閱讀本文約花費: 10 (分鐘)|01 领域模型是什么 领域模型是什么?一句话:“经济基础决定上层建筑”中的“经济基础”,是帮助理解复杂业务领域问题的基石。 有人说:“领域模型是一个商业概念,同行业的企业,一定有内在的共性,是帮助系统分析人员认识现实业务的工具。”领域,即边界的意思,有了清晰的边界,协作才有了利益的基础;模型,即知识体系,深入理解了业务知识,开发才不会走过多的弯路。一般意义上的领域模型是面向软件工程领域的,而现实意义的领域模型则包含了商业模式等广义上的概念。 很多人一上来理解领域驱动设计(DDD),基本都是一头雾水,因为模型设计的初衷并不是围绕性能、架构、分层等软件概念展开的,而是从边界、内聚等抽象概念开始讲起。理解领域模型,并不是通过技术的思维来学习,而是通过不断地实践过程来训练自我的思维意识,进而彻底形成结构化与面向对象的思维方法论。 领域模型并不能直接带来收益,只是辅助我们去理解正在做的事情。 引用百度的说法,“领域模型是对领域内的概念类或现实世界中对象的可视化表示。又称概念模型、领域对象模型、分析对象模型。它专注于分析问题领域本身,发掘重要的业务领域概念,并建立业务领域概念之间的关系。”总结一下,就是“准确描述问题,清晰描述方案”。 如果说软件开发的本质,是从“问题空间”到“解决方案空间”的转化,那么“领域模型”,就是“解决方案空间”的架构,通过抽象的模型,…

Read More Read More

云原生架构概述

云原生架构概述

閱讀本文約花費: 9 (分鐘)1. 什么是云原生 1.1 CNCF组织 在讲云原生之前,我们先了解一下CNCF,即云原生计算基金会,2015年由谷歌牵头成立,基金会成员目前已有一百多企业与机构,包括亚马逊、微软。思科等巨头。 目前CNCF所托管的应用已达14个,下图为其公布的Cloud Native Landscape,给出了云原生生态的参考体系。 1.2 云原生 CNCF给出了云原生应用的三大特征: 容器化封装:以容器为基础,提高整体开发水平,形成代码和组件重用,简化云原生应用程序的维护。在容器中运行应用程序和进程,并作为应用程序部署的独立单元,实现高水平资源隔离。 动态管理:通过集中式的编排调度系统来动态的管理和调度。 面向微服务:明确服务间的依赖,互相解耦。 云原生包含了一组应用的模式,用于帮助企业快速,持续,可靠,规模化地交付业务软件。云原生由微服务架构,DevOps 和以容器为代表的敏捷基础架构组成。 这边引用网上关于云原生所需要的能力和特征总结,如下图。 云原生所需要的能力和特征 1.3 The Twelve Factors 12-Factors经常被直译为12要素,也被称为12原则,12原则由公有云PaaS的先驱Heroku于2012年提出,目的是告诉开发者如何利用云平台提供的便利来开发更具可靠性和扩展性、更加易于维护的云原生应用。具体如下: 基准代码 显式声明依赖关…

Read More Read More

领域模型浅析

领域模型浅析

閱讀本文約花費: 20 (分鐘)领域模型 最近taowen同学连续发起了两起关于贫血模型和领域模型的讨论,引起了大家的广泛热烈的讨论,但是讨论(或者说是争论)的结果到底 怎样,我想值得商榷。问题是大家对贫血模型和领域模型都有自己的看法,如果没有对此达到概念上的共识,那么讨论的结果应该可想而知,讨论的收获也是有的, 至少知道了分歧的存在。为了使问题具有确定性,我想从一个简单例子着手,用我对贫血模型和领域模型的概念来分别实现例子。至于我的理解对与否,大家可以做 评判,至少有个可以评判的标准在这。 一个例子 我要举的是一个银行转帐的例子,又是一个被用滥了的例子。但即使这个例子也不是自己想出来的,而是剽窃的<<POJOs in Action>>中的例子,原谅我可怜的想像力 。当钱从一个帐户转到另一个帐户时,转帐的金额不能超过第一个帐户的存款余额,余额总数不能变,钱只是从一个账户流向另一个帐户,因此它们必须在一个事务内完成,每次事务成功完成都要记录此次转帐事务,这是所有的规则。 贫血模型 我们首先用贫血模型来实现。所谓贫血模型就是模型对象之间存在完整的关联(可能存在多余的关联),但是对象除了get和set方外外几乎就没有其它的方 法,整个对象充当的就是一个数据容器,用C语言的话来说就是一个结构体,所有的业务方法都在一个无状态的Service类中实现,Service类仅…

Read More Read More

用户画像基础

用户画像基础

閱讀本文約花費: 31 (分鐘)导读:在互联网步入大数据时代后,用户行为给企业的产品和服务带来了一系列的改变和重塑,其中最大的变化在于,用户的一切行为在企业面前是可“追溯”“分析”的。企业内保存了大量的原始数据和各种业务数据,这是企业经营活动的真实记录,如何更加有效地利用这些数据进行分析和评估,成为企业基于更大数据量背景的问题所在。随着大数据技术的深入研究与应用,企业的关注点日益聚焦在如何利用大数据来为精细化运营和精准营销服务,而要做精细化运营,首先要建立本企业的用户画像。 01 画像简介 用户画像,即用户信息标签化,通过收集用户的社会属性、消费习惯、偏好特征等各个维度的数据,进而对用户或者产品特征属性进行刻画,并对这些特征进行分析、统计,挖掘潜在价值信息,从而抽象出用户的信息全貌,如图1-1所示。用户画像可看作企业应用大数据的根基,是定向广告投放与个性化推荐的前置条件,为数据驱动运营奠定了基础。由此看来,如何从海量数据中挖掘出有价值的信息越发重要。 大数据已经兴起多年,其对于互联网公司的应用来说已经如水、电、空气对于人们的生活一样,成为不可或缺的重要组成部分。从基础设施建设到应用层面,主要有数据平台搭建及运维管理、数据仓库开发、上层应用的统计分析、报表生成及可视化、用户画像建模、个性化推荐与精准营销等应用方向。 很多公司在大数据基础建设上投入很多,也做了不少报表,但业务部门觉得大…

Read More Read More

Scroll Up