分布式架构

新手学分布式 - Envoy Proxy XDS Server动态配置的一点使用心得

感情迁移 提交于 2019-12-06 16:22:41
Envoy Proxy 动态API的使用总结 Envoy Proxy和其它L4/L7反向搭理工具最大的区别就是原生支持动态配置。 首先来看一下Envoy的大致架构 从上图可以简单理解:Listener负责接受外部的请求,然后经过Filter/Router处理之后,在转发到具体的Cluster。 其中Listener,Router,Cluster和Host地址都是可以动态配置的,配置这些数据的服务就称之为X Discovery Services,简称XDS。 本文主要描述如何编写XDS Server更新逻辑。 Envoy Porxy XDS Service通过GRPC服务进行数据更新,所有Proto文件可以参考 https://github.com/envoyproxy/envoy/tree/master/api/envoy/api/v2 。 用户可以根据proto文件自行生成相对应语言的GRPC代码文件。如果使用golang来实现的话,Envoy已经提供了一份编译好的GRPC代码,地址在这里: https://github.com/envoyproxy/go-control-plane/tree/master/envoy/api/v2 每个XDS Service都有两种GRPC服务, Stream 和 Delta 。 Stream 用来更新全量数据, Delta 用来更新增量数据

Kafka初识

亡梦爱人 提交于 2019-12-06 14:22:36
转载自 https://www.cnblogs.com/luotianshuai/p/5206662.html Kafka初识 1、Kafka使用背景 在我们大量使用分布式数据库、分布式计算集群的时候,是否会遇到这样的一些问题: 我们想分析下用户行为(pageviews),以便我们设计出更好的广告位 我想对用户的搜索关键词进行统计,分析出当前的流行趋势 有些数据,存储数据库浪费,直接存储硬盘效率又低 这些场景都有一个共同点: 数据是由上游模块产生,上游模块,使用上游模块的数据计算、统计、分析,这个时候就可以使用消息系统,尤其是分布式消息系统! 2、Kafka的定义 What is Kafka:它是一个分布式消息系统,由linkedin使用scala编写,用作LinkedIn的活动流(Activity Stream)和运营数据处理管道(Pipeline)的基础。具有高水平扩展和高吞吐量。 3、Kafka和其他主流分布式消息系统的对比 定义解释: 1、Java 和 scala都是运行在JVM上的语言。 2、erlang和最近比较火的和go语言一样是从代码级别就支持高并发的一种语言,所以RabbitMQ天生就有很高的并发性能,但是 有RabbitMQ严格按照AMQP进行实现,受到了很多限制。kafka的设计目标是高吞吐量,所以kafka自己设计了一套高性能但是不通用的协议

[转]MongoDB分布式集群搭建手记

末鹿安然 提交于 2019-12-06 12:48:31
一、架构简介 目标 单机搭建mongodb分布式集群(副本集 + 分片集群),演示mongodb分布式集群的安装部署、简单操作。 说明 在同一个vm启动由两个分片组成的分布式集群,每个分片都是一个PSS(Primary-Secondary-Secondary)模式的数据副本集; Config副本集采用PSS(Primary-Secondary-Secondary)模式。 二、配置说明 端口通讯 当前集群中存在shard、config、mongos共12个进程节点,端口矩阵编排如下: 编号 实例类型 1 mongos 2 mongos 3 mongos 4 config 5 config 6 config 7 shard1 8 shard1 9 shard1 10 shard2 11 shard2 12 shard2 内部鉴权 节点间鉴权采用keyfile方式实现鉴权,mongos与分片之间、副本集节点之间共享同一套keyfile文件。 官方说明 账户设置 管理员账户:admin/Admin @01 ,具有集群及所有库的管理权限 应用账号:appuser/AppUser @01 ,具有appdb的owner权限 关于初始化权限 keyfile方式默认会开启鉴权,而针对初始化安装的场景,Mongodb提供了 localhost-exception机制 ,

Redis 分布式锁

三世轮回 提交于 2019-12-06 12:19:56
众所周知,redis是一个高性能的分布式 key-value 存储系统,在NoSQL数据库市场上,redis自己就占据了将近半壁江山,足以见到其强大之处。同时,由于redis的单线程特性,我们可以将其用作为一个 消息队列 。本篇文章就来讲讲如何将redis整合到spring boot中,并用作消息队列的 (本人自己在线上使用后,感觉加分布式锁大大影响了效率,还没有单机效率高) 为什么会出现消息队列? 异步:常见的B/S架构下,客户端向服务器发送请求,但是服务器处理这个消息需要花费的时间很长的时间,如果客户端一直等待服务器处理完消息,会造成客户端的系统资源浪费;而使用消息队列后,服务器直接将消息推送到消息队列中,由专门的处理消息程序处理消息,这样客户端就不必花费大量时间等待服务器的响应了; 解耦:传统的软件开发模式,模块之间的调用是直接调用,这样的系统很不利于系统的扩展,同时,模块之间的相互调用,数据之间的共享问题也很大,每个模块都要时时刻刻考虑其他模块会不会挂了;使用消息队列以后,模块之间不直接调用,而是通过数据,且当某个模块挂了以后,数据仍旧会保存在消息队列中。最典型的就是 生产者-消费者 模式,本案例使用的就是该模式; 削峰填谷:某一时刻,系统的并发请求暴增,远远超过了系统的最大处理能力后,如果不做任何处理,系统会崩溃;使用消息队列以后,服务器把请求推送到消息队列中

Service Mesh 是新瓶装旧酒吗?

我的梦境 提交于 2019-12-06 12:17:24
点击下载《不一样的 双11 技术:阿里巴巴经济体云原生实践》 本文节选自《不一样的 双11 技术:阿里巴巴经济体云原生实践》一书,点击上方图片即可下载! 作者 | 李云(花名:至简) 阿里云高级技术专家 导读 :在即将过去的 2019 年,Service Mesh 开源产品的成熟度虽在全球范围内没有发生质的变化,但在国内仍出现了一些值得特别关注的事件。比如:阿里巴巴在 双11 的部分电商核心应用上落地了完整的 Service Mesh 解决方案,借助 双11 的严苛业务场景完成了规模化落地前的初步技术验证。本文作者将结合自己在阿里巴巴落地实践 Service Mesh 过程中的观察与思考,来和大家进行分享。 Service Mesh 是新瓶装旧酒吗? 新技术出现时所主张的价值一定会引发相应的探讨,Service Mesh 也不例外。 以往,怀疑 Service Mesh 价值的观点主要有两大类。 第一类 是应用的数量并没有达到一定的规模,在 Service Mesh 增加运维和部署复杂度的情形下,认为所带来的成本和复杂度高于所获得的收益。 从根本上来看,这一类并非真正怀疑 Service Mesh 的价值,而是主张在 Service Mesh 还没有完全成熟和普及的情形下,在未来合适的时机再考虑采纳。当然,我在与外部客户交流时也碰到一些特例,他们即便在应用数很少的情形下,仍希望通过

推荐!国外程序员整理的系统管理员资源大全 ()

你说的曾经没有我的故事 提交于 2019-12-06 11:54:44
推荐!国外程序员整理的系统管理员资源大全 2015-1-19 12:24 发布者: admin 微博分享 受其他程序员汇编 php 资源,kahun 在 Github 发起系统管理员相关的开源资源整理。 内容分类包括:备份/克隆软件、云计算/云存储、协作软件、配置管理、日志管理、监控、项目管理…… 当然也有系统管理员相关书籍。 备份 备份软件 Amanda -客户端-服务器模型备份工具 Bacula - 另一个客户端-服务器模型备份工具 Backupninja -轻量级,可扩展的元数据备份系统 Backuppc -客户端-服务器模型备份工具和文件共享方案。 Burp -网络备份和还原程序 Duplicity -使用rsync算法加密的带宽-效率备份 Lsyncd -监控一个本地目录树的变化,然后产生一个进程去同步变化。默认使用rsync。 Rsnapshot -文件系统快照工具 SafeKeep -使用rdiff-backup,集中的,基于pull的备份 TarSnap - 具有一个开源客户端的安全备份服务 UrBackup -另一个客户端-服务器备份系统 DREBS - AWS EBS支持策略的备份脚本 克隆 克隆软件 Clonezilla -分区和磁盘镜像/克隆程序 Fog - 另一个计算机克隆解决方案 Redo Backup -简单的备份,恢复和还原 云计算 AppScale

使用Cap解决.Netcore分布式事务

扶醉桌前 提交于 2019-12-06 10:57:46
一、什么是Cap CAP 是一个基于 .NET Standard 的 C# 库,它是一种处理分布式事务的解决方案,同样具有 EventBus 的功能,它具有轻量级、易使用、高性能等特点。 在我们构建 SOA 或者 微服务系统的过程中,我们通常需要使用事件来对各个服务进行集成,在这过程中简单的使用消息队列并不能保证数据的最终一致性, CAP 采用的是和当前数据库集成的本地消息表的方案来解决在分布式系统互相调用的各个环节可能出现的异常,它能够保证任何情况下事件消息都是不会丢失的。 你同样可以把 CAP 当做 EventBus 来使用,CAP提供了一种更加简单的方式来实现事件消息的发布和订阅,在订阅以及发布的过程中,你不需要继承或实现任何接口。 以下是CAP集在ASP.NET Core 微服务架构中的一个示意图: 二、安装 你可以运行以下下命令在你的项目中安装 CAP。 PM> Install-Package DotNetCore.CAP CAP 支持 Kafka、RabbitMQ、AzureServiceBus 等消息队列,你可以按需选择下面的包进行安装: PM> Install-Package DotNetCore.CAP.Kafka PM> Install-Package DotNetCore.CAP.RabbitMQ PM> Install-Package DotNetCore

分布式的优点、分布式锁及分布式事务处理机制

最后都变了- 提交于 2019-12-06 10:54:01
1、关于分布式锁的了解? 原理:控制分布式系统有序的去对共享资源进行操作,通过互斥来保持一致性。 具备的条件: ①分布式环境下,一个方法在同一时间只能被一个机器的一个线程执行 ②高可用的获取锁和释放锁 ③高性能的获取锁和释放锁 ④具备可重入特性 ⑤具备锁失效机制,防止死锁 分布式锁的三种实现: A. 基于数据库实现分布式锁; B. 基于缓存(Redis等)实现分布式锁; C. 基于Zookeeper实现分布式锁 A.基于数据库的实现: 在数据库中创建一个表,表中包含方法名等字段,并在方法名字段上创建唯一索引,想要执行某个方法,就是用这个方法名向表中插入数据,成功插入则获取锁,执行完成后删除对应的行数据释放锁 B.基于缓存(Redis等)实现分布式锁: 推荐: Redis有很高的性能; Redis命令对此支持较好,实现起来比较方便 实现: (1)获取锁的时候,使用setnx加锁,并使用expire 命令为锁添加一个超时时间,超过该时间则自动释放锁,锁的value值为一个随机生成的UUID,通过此在释放锁的时候进行判断。 (2)获取锁的时候设置一个获取的超时时间,若超过这个时间就放弃获取锁。 (3)释放锁的时候,通过UUID判断是不是该锁,若是该锁,就执行delete进行锁释放。 C.基于Zookeeper的实现方式 原因: Zookeeper是一个为分布式应用提供一致性服务的开源组件

终极手撕之架构大全:分布式+开源框架+微服务+性能优化,够不够?

谁都会走 提交于 2019-12-06 10:20:01
终极手撕之架构大全:分布式+开源框架+微服务+性能优化,够不够? 一只Tom猫4小时前 我要分享 之前有零零散散整理过一些专题给大家参考学习,这次一次性来个终极手撕之架构大全,包含开源框架、分布式、微服务、性能优化等四个大专题共17个小专题,全部一锅端,送给大家一起学习~ 注意:需要全部完整版架构大全答案的可以 【“点击我”免费领取】 《终极手撕之架构大全:分布式+开源框架+微服务+性能优化,够不够?》 01 开源框架(Spring +SpringMVC+Mybatis) 开源框架答案解析如下: 1.1 手撕开源框架之Spring 什么是 Spring 框架?Spring 框架有哪些主要模块? 使用 Spring 框架能带来哪些好处? 什么是控制反转(IOC) 请解释下 Spring 框架中的 IoC BeanFactory 和 和 ApplicationContext 有什么区别? Spring 有几种配置方式? 如何用基于 XML 配置的方式配置 Spring 如何用基于 Java 配置的方式配置 Spring 怎样用注解的方式配置 Spring 请解释 Spring Bean 的生命周期? Spring Bean 的作用域之间有什么区别? Spring 框架中的单例 Beans 是线程安全的么? 请举例说明如何在 Spring 中注入一个 Java Collection

微服务和分布式的区别

左心房为你撑大大i 提交于 2019-12-06 10:15:22
1.分布式      将一个大的系统划分为多个业务模块,业务模块分别部署到不同的机器上,各个业务模块之间通过 接口 进行数据交互。区别分布式的方式是根据不同机器不同业务。   上面:service A、B、C、D 分别是业务组件,通过API Geteway进行业务访问。   注:分布式需要做好事务管理。   2.分布式是否属于微服务?   答案是肯定的。微服务的意思也就是将模块拆分成一个独立的服务单元通过接口来实现数据的交互。   3.微服务架构   微服务的设计是为了不因为某个模块的升级和BUG影响现有的系统业务。微服务与分布式的细微差别是,微服务的应用不一定是分散在多个服务器上,他也可以是同一个服务器。     分布式和微服的架构很相似,只是部署的方式不一样而已。   分布式服务架构与微服务架构概念的区别与联系是怎样的   分布式:分散压力。   微服务:分散能力。   当下理解   分布式:   不同模块部署在不同服务器上;   作用:分布式解决网站高并发带来问题;   集群:相同的服务;   多台服务器部署相同应用构成一个集群;   作用:通过负载均衡设备共同对外提供服务;   SOA[组装服务/ESB企业服务总线];   业务系统分解为多个组件,让每个组件都独立提供离散,自治,可复用的服务能力;   通过服务的组合和编排来实现上层的业务流程;   作用:简化维护