Browsed by
标签:网关

Kubernetes集群搭建:基于Kubeadm

Kubernetes集群搭建:基于Kubeadm

閱讀本文約花費: 16 (分鐘)一,环境准备 * K8S版本为15.1 * Docker版本最高支持18.06.1 二,Docker环境构建及替换 1,清除原Docker环境,原版本为最新版 yum remove docker \docker-client \docker-client-latest \docker-common \docker-latest \docker-latest-logrotate \docker-logrotate \docker-selinux \docker-engine-selinux \docker-engine rm -rf /etc/systemd/system/docker.service.d rm -rf /var/lib/docker rm -rf /var/run/docker 2,如果清除后依旧包冲突错误 file /usr/share/man/man1/docker-manifest-annotate.1.gz from install of docker-ce-18.06.1.ce-3.el7.x86_64 conflicts with file from package docker-ce-cli-1:18.09.6-3.el7.x86_64 通过yum命令手动移除冲突包 yum erase docker-common-2:1…

Read More Read More

图文:千万级高性能长连接网关是如何搭建的?

图文:千万级高性能长连接网关是如何搭建的?

閱讀本文約花費: 17 (分鐘)实时的响应总是让人兴奋的,就如你在微信里看到对方正在输入,如你在王者峡谷里一呼百应,如你们在直播弹幕里不约而同的 666,它们的背后都离不开长连接技术的加持。 每个互联网公司里几乎都有一套长连接系统 ,它们被应用在消息提醒、即时通讯、推送、直播弹幕、游戏、共享定位、股票行情等等场景。而当公司发展到一定规模,业务场景变得更复杂后,更有可能是多个业务都需要同时使用长连接系统。 业务间分开设计长连接会导致研发和维护成本陡增、浪费基础设施、增加客户端耗电、无法复用已有经验等等问题。共享长连接系统又需要协调好不同系统间的认证、鉴权、数据隔离、协议拓展、消息送达保证 等等需求,迭代过程中协议需要向前兼容,同时因为不同业务的长连接汇聚到一个系统导致容量管理的难度也会增大。 经过了一年多的开发和演进,经过我们服务面向内和外的数个 App、接入十几个需求和形态各异的长连接业务、数百万设备同时在线、突发大规模消息发送等等场景的锤炼,我们提炼出一个长连接系统网关的通用解决方案,解决了多业务共用长连接时遇到的种种问题。 知乎长连接网关致力于业务数据解耦、消息高效分发、解决容量问题,同时提供一定程度的消息可靠性保证。 我们怎么设计通讯协议? 业务解耦 支撑多业务的长连接网关实际上是同时对接多客户端和多业务后端的,是多对多的关系,他们之间只使用一条长连接通讯。 这种多对多的系统…

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

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

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

别让自己“墙”了自己

别让自己“墙”了自己

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

Read More Read More

Docker不香吗,为啥还要K8s?

Docker不香吗,为啥还要K8s?

閱讀本文約花費: 16 (分鐘)上一篇文章我们着重讲解了 Docker,其实遗留了一个大问题。Docker 虽好用,但面对强大的集群,成千上万的容器,突然感觉不香了。 这时候就需要我们的主角 Kubernetes 上场了,先来了解一下 K8s 的基本概念,后面再介绍实践,由浅入深步步为营。 关于 K8s 的基本概念我们将会围绕如下七点展开: Docker 的管理痛点 什么是 K8s? 云架构 & 云原生 K8s 架构原理 K8s 核心组件 K8s 的服务注册与发现 关键问题 Docker 的管理痛点 如果想要将 Docker 应用于庞大的业务实现,是存在困难的编排、管理和调度问题。 于是,我们迫切需要一套管理系统,对 Docker 及容器进行更高级更灵活的管理。 Kubernetes 应运而生!Kubernetes,名词源于希腊语,意为「舵手」或「飞行员」。 image Google 在 2014 年开源了 Kubernetes 项目,建立在 Google 在大规模运行生产工作负载方面拥有十几年的经验的基础上,结合了社区中最好的想法和实践。 K8s 是 Kubernetes 的缩写,用 8 替代了 「ubernete」,下文我们将使用简称。 什么是 K8s ? image K8s 是一个可移植的、可扩展的开源平台,用于管理容器化的工作负载和服务,可促进声明式配置和自动化。 …

Read More Read More

微信、陌陌等著名IM软件设计架构详解

微信、陌陌等著名IM软件设计架构详解

閱讀本文約花費: 13 (分鐘)对微信、陌陌等进行了分析,发出来分享一下(时间有些久了) 电量:对于移动设备最大的瓶颈就是电量了。因为用户不可能随时携带电源,充电宝。所以必须考虑到电量问题。那就要检查我们工程是不是有后台运行,心跳包发送时间是不是合理。 流量:对于好多国内大部分屌丝用户来说可能还是包月30M,那么我们必须站在广大用户角度来考虑问题了。一个包可以解决的就一个包。 网络: 这个也是IM最核心的内容了,我们要做到在任何网络下等顺畅聊天那就不容易了,好多公司都用的xmpp框架,如果在强网络环境下,xmpp完全没有问题。但是那种弱网络环境下xmpp就束手无策啦,用户体验就很垃圾了。 个人觉得xmpp 可以玩玩(参考看这个RFC3920和RFC3921), 但是用来真正的产品就差远了。如果遇到一个做IM 的朋友张口闭口都说xmpp 的话,那么不用沟通了,肯定不是什么好产品。微信、QQ以前也曾用过xmpp,但是最后也放弃了xmpp,就知道xmpp有很多弊端了,还有就是报文太大,好臃肿,浪费流量。为了保证稳定,微信用了长链接和短链接相结合,例如: 1 、两个域名 微信划分了http模式(short链接)和 tcp 模式(long 链接),分别应对状态协议和数据传输协议 long.weixin.qq.com  dns che…

Read More Read More

企业应用架构演化探讨:从微服务到Service Mesh

企业应用架构演化探讨:从微服务到Service Mesh

閱讀本文約花費: 18 (分鐘)导读 当下微服务的实践方案中,Spring Cloud,Dubbo作为主流的落地方案,在企业应用架构中发挥越来越重要的作用。需要特别说明:本文讨论的架构目前适用于普通的企业级应用,其他行业(例如互联网)需要进一步扩展。 在讨论之前,我们需要明确一个事实:企业应用一定是围绕业务进行的。无论采用什么的架构落地,都是为了更好的为应用业务进行服务。从企业应用的特性考虑,主要包括:稳定性,安全性,扩展性,容错性。 围绕着企业应用的这些特点,我们来看一个典型的微服务企业架构模型,如图所示: 服务接入层:企业暴露到外部访问的入口,一般通过防火墙等。 网关层:服务网关是介于客户端和服务端的中间层,所有的外部请求会先经过服务网关,为企业应用提供统一的访问控制入口。服务网关是微服务架构下的服务拆分,聚合,路由,认证以及流控综合体现。 支撑服务层:为企业应用提供运行所需的支撑环境,包括注册发现,集中配置,容错限流,认证授权,日志聚合,监测告警,消息服务等 业务服务层:业务服务是企业应用的核心所在,为企业领域应用的具体实现,一般进一步拆分为基础服务(基础功能)和聚合服务(综合场景)。 平台服务层:为企业应用提供运行所需的软件资源,包括应用服务器,应用发布管理,应用镜像包管理,服务治理。 基础设施层:为企业应用提供运行所需的硬件资源,包括计算资源,网络资源,存储资源,基本的安…

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

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

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

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

Read More Read More

设计详解:电商业务中台如何实现可视、可配、可复用?

设计详解:电商业务中台如何实现可视、可配、可复用?

閱讀本文約花費: 23 (分鐘) 本文从常见的中台架构出发,对中台产品设计如何实现可视、可配、可复用这个问题展开了详细解析,与大家分享。 建设中台最直接的目的一般是为了帮助企业快速且低成本的创新,这就要求了中台必须降低使用方的学习成本,能把各个业务进行集中管理以及需要有较低的学习门槛,简单来讲就是:可视化、配置化、低代码。中台产品设计如何实现可视、可配、可复用?本文作者从常见的中台架构出发,对这个问题展开了详细解析,与大家分享。 中台在这两年是一个非常火的概念,其出现的目的只有一个:帮助企业快速且低成本的进行创新。 二十年前,中国的互联网刚刚起步,在线交易一片荒芜,商品信息极难通过在线进行展示,更别论在线交易;十年前,中国互联网蓬勃发展,以阿里、京东为代表的企业实现了在线交易基础设施的搭建,大部分的消费则能够在网上查找商品并进行交易; 而如今,互联网日益向着成为水电煤的趋势发展,各种模式、形态的电商不断涌现,昨天刚出现蘑菇街、小红书,今天就有有赞、拼多多;昨天刚大力吹捧微博、公众号的自媒体营销,今天又有小程序的出现。 在这个极其不确定的时代里,任何一家企业都害怕错失机会,不断出现的新鲜事物,让企业创新的成本越来越高,如何能够通过尽量少的成本,而不失尝试新鲜事物的机会,成为企业经营中遇到的难题之一。 一、常见的中台架构 在聊中台的时候,我们一定需要聊一聊软件架构,软件架构是系统发展到…

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

如何搭建支付中台系统?

如何搭建支付中台系统?

閱讀本文約花費: 10 (分鐘) 编辑推荐:本文主要讲解了什么是中台呢?中台能解决什么问题,如何去搭建适合公司的中台系统?支付中台如何落地? 什么是中台 中台其实最早是起源于军事领域,在二战时期的美军在各个战场上,看起来有打不完的弹药、耗不完的燃料、充足的食品补给、及时准确的情报……但其资源却在万里之遥的美国本土,这一切是如何做到的呢? 就是依靠庞大的中台体系,支持到世界各战场。前方战场上的一名士兵,平均就有12名人员支持,在战场-基地-本土形成前、中、后台的效率系统。 国内互联网最早实行中台战略的就是阿里。 由于阿里涉及的业务线非常多,在没有中台之前都是每个业务自己去做一套系统,但是每个业务系统都有相同的模块,例如订单系统、支付系统、商户系统、短信系统等。因此就导致各个业务线重复造轮子的现象,业务端不仅需要对业务模块进行优化和升级,同时也需要维护这些基础支撑服务。 用一句话概括:中台就是将所有业务的公共模块抽象出来,单独创建一个中台系统统一对这些公共模块进行维护,统一输出服务提供业务方使用,让业务方能够集中全力发展业务。 中台解决什么问题 理解了中台的概念,那么就需要思考对于互联网公司,中台系统的搭建能够解决什么问题呢? 可以解决你的996问题 中台是独立于业务系统而又服务于业务系统的存在,业务系统的前台和后台是关联存在的,但是中台的定位就是出于整个公司层面,要服务于多条业务线。…

Read More Read More

Scroll Up