6 沈鸿斌

尚未进行身份认证

爱生活,爱Coding

等级
TA的排名 6k+

如何构建高可用的系统(三):服务治理篇

在如何构建高可用的系统(一):Overview中, 我提到了以下几点:系统依赖的一切下游系统都是不可靠的, 它们随时可能出问题系统的上游可能有多个, 而且每个上游的行为都是不可预知的。如果某个上游抽风把我的系统搞崩, 那么就会影响所有的上游高可用是有前提条件的,一个系统对当前的负载能提供高可用, 不代表负载上升之后仍然高可用如果把这几个问题,映射到现在非常流行的“微服务架构”下,就可以...

2019-01-19 19:32:16

如何构建高可用的系统(二): 消除单点与自动故障转移

前一篇文章我们讲到,一切单点都是不可靠的,如果系统中某个地方可能会出问题(就算概率很低),那么它迟早会出问题。也就是我们常说的Murphy’sLaw。如果要提高系统的可用性,那么就必须尽可能消灭掉系统中所有的单点,并且在发生故障时,把流量自动转移到运行正常的节点。在这篇文章中,我会以互联网产品后端常见的架构为例,讲述如何达到这个目标。1.常见系统架构互联网后端应用的常见架构可...

2019-01-12 21:01:07

如何构建高可用的系统(一):Overview

1.What首先,我们需要对"可用性"下一个定义。业界常用SLA(ServiceLevelAgreement)来描述一个系统的可用性,SLA包含很多信息(服务内容、故障恢复时间、可用性等),在这里我们笼统的用“N个9”来指代,比如4个9指的是99.99%的可用性、5个9指的是99.999%的可用性。假如一个系统声称它的年可用性是4个9,那它提供的可用性承诺

2018-12-22 17:44:49

全球异地多活架构设计(二): 数据层的支持

要做到全球异地多活,一定要在数据层支持多机房写入,并且对大多数业务场景提供最终一致性的解决方案。原因如下:跨洲的网络延迟在100ms的数量级,如果只有单点写,对于用户体验是种灾难对于高频操作来说,如果做强一致性,那么任然受限于网络延迟,对于用户体验是种灾难那么随之而来就有两个问题需要解决:跨机房的数据同步多点写入时的数据冲突处理一、数据同步数据的同步有几个核心问...

2018-12-01 15:43:43

全球异地多活架构设计(一): Why and How

很多全球化的产品,比如facebook、twitter,它们的用户遍布世界各地。工程师们往往会在全球设立多个数据中心(DC)供用户访问,我们可以称之为异地多活。在后续一段时间里,我会写一系列的博客,和大家一起探索异地多活架构。这篇文章主要是讨论我们为什么需要异地多活,以及实现这种架构所需要解决的问题。一、异地多活的好处1.提高用户体验一个产品最重要的是提供良好的用户体验,这对...

2018-11-04 18:20:37

对微信《Scalable Overload Control for Large-scale Microservice Architecture》论文的解读

这几年微服务大行其道,随之而来也伴随着很多问题:服务注册和发现(常见解决方案如Consul,ZK,etcd)熔断和降级(如Hystrix)…在服务过载时,一个常见的解决方案是熔断。以前的熔断方案基本都是各个服务独自处理的,即如果一个服务无法处理所有的请求,那么就抛弃一部分请求。这种粗暴的处理方式并不能缓解整个系统的负载,并且浪费了很多计算资源,比如以下场景:假设...

2018-08-12 22:02:26

《设计数据密集型应用/DDIA》精要翻译(七) :Linearizability

定义和理解Linearizability是常用的一致性模型(对于一致性模型,笔者后续会有专门的文章来讨论)之一,Linearizability也可以被称为原子一致性(atomic consistency),强一致性(strong consistency),立即一致性(immediate consistency)或外部一致性(external consistency )。很难给Lineari...

2018-04-14 14:28:40

《设计数据密集型应用/DDIA》精要翻译(六) :分布式系统中的问题

这一章我们会讨论分布式系统中一些常见的问题,在下一章中我们会讨论这些问题的解决办法。1.故障与部分失败在分布式系统中,系统的部分组件常常会以以某种未知的方式被破坏,我们称之为部分失败/部分故障。而我们的目标就是在不可靠的组件上构建一个可靠的系统。为了容忍部分失败:第一步是检测失败:大多数系统利用超时来判断节点是否可用,但是超时机制没办法区分是网络失效还是节点宕机在检...

2018-04-07 20:13:08

《设计数据密集型应用/DDIA》精要翻译(五) :事务

1. 事务的ACID虽然ACID我们已经说滥了,这里我想再说一下一致性和隔离性。一致性一致性在不同的术语中有不同的含义:在前面那篇博客中,我们讨论了副本之间的一致性(比如最终一致性、读已之写一致性等)在CAP中,一致性表示可线性化(即只要有一个客户端成功写入,别的客户端后续的读取必须能看到刚刚写入的值。 详见本系列第七篇。)在ACID中,指数据库在事务前后保持正确(比如转...

2018-04-05 22:26:17

《设计数据密集型应用/DDIA》精要翻译(四) :副本机制

从这一章开始,我们就正式从单机应用转向了分布式应用的旅程! ps: 其实DDIA这书我1月份已经看完了,只不过那会儿实在没有心力去翻译。前段时间太太太忙了,对几千万日活的系统做了技术栈迁移、跨洲数据中心无缝平移。后续也会写文章来分享我们是怎么做的,欢迎持续关注。副本机制的意思是,在多台通过网络互连的机器上保存同一份数据的多份拷贝。我们为什么需要副本:让用户在地理上离数据...

2018-03-31 15:15:20

《设计数据密集型应用/DDIA》精要翻译(三) :数据的存储和获取之底层数据结构

看了这三章,我最大的收货并不是说学到了什么新的知识,而是对以前通过各种渠道所掌握的知识重新进行了梳理和归纳,使它们有种脉络相通的感觉。一、驱动你的数据库的数据结构这也许是世界上最简单的数据库实现:db_set () { echo "$1,$2" >> database}db_get () { grep "^$1," dat...

2018-01-15 01:03:27

《设计数据密集型应用/DDIA》精要翻译(二) :数据模型和查询语言

当我们在设计kafka、mysql这样的数据密集型应用时,数据模型也许是最为重要的一个考虑点。因为它不仅影响了代码的写法,还影响着我们解决问题的思维方式。这是第一章第二节的读书笔记,介绍了几种不同的数据模型以及数据查询语言。(其实看目录就知道前两章都是小打小闹热热身,但是既然是神书,还是要好好看不是么?)一、关系型模型与文档型模型的比较关系型数据库和文档型数据库有很多的差异...

2018-01-13 16:39:52

《设计数据密集型应用/DDIA》精要翻译(一) :reliability, scalability, maintainability

之前一段时间在看Kafka的源码分析,想学着做个分布式消息系统。后来听说 《设计数据密集型应用》这本书是2017年的神书,对这样的数据系统的内在精髓有很好的讲解。 看完这本书之后再看kafka之类的数据系统能事半功倍。因此,虽然每天忙于搬砖,但还是要抽出时间来拜读一下!这本书暂时还没有中文版,未来的一段时间里我会陆陆续续边看边做部分精华内容的翻译。这是第一章第一节的读书笔记,介绍了re...

2018-01-11 13:51:17

关于负载均衡的一些总结

之前只了解Nginx相关的负载均衡,前段时间写RPC框架的时候涉及到LB这块,就去详细学习了些,在这里做个简单的总结。参考资料: http://blog.51cto.com/virtualadc/591396http://www.jianshu.com/p/8a61de3f8be9http://blog.csdn.net/column/details/load-balancing.

2017-11-28 01:38:59

如何写一个RPC框架(六):负载均衡

在后续一段时间里, 我会写一系列文章来讲述如何实现一个RPC框架。 这是系列第六篇文章, 主要讲述了RPC中负载均衡这一块的内容。常见的LB策略常见的LB策略有很多:RoundRobin (RR): 一个列表中轮着来WeightedRoundRobin (WRR): 带权重的RRLocalFirst:本地服务优先Random:随机选择ConsistentHash: 一致性哈希这些策

2017-11-19 13:50:01

如何写一个RPC框架(五):服务器端实现

在后续一段时间里, 我会写一系列文章来讲述如何实现一个RPC框架(我已经实现了一个示例框架, 代码在我的github上)。 这是系列第五篇文章, 主要讲述了服务器端的实现。在前面的几篇文章里, 我们已经实现了客户端创建proxy bean, 并利用它来发送请求、处理返回的全部流程: 扫描package找出需要代理的service通过服务注册中心和Load Balancer获取se

2017-11-13 23:52:38

如何写一个RPC框架(四):网络通信之客户端篇

在后续一段时间里,我会写一系列文章来讲述如何实现一个RPC框架。这是系列第四篇文章,主要讲述了客户端和服务器之间的网络通信问题。模型定义我们需要自己来定义RPC通信所传递的内容的模型,也就是RPCRequest和RPCResponse。@Data@BuilderpublicclassRPCRequest{privateStringrequestId;pr

2017-11-12 14:36:13

如何写一个RPC框架(三):服务注册与服务发现

在后续一段时间里,我会写一系列文章来讲述如何实现一个RPC框架。这是系列第三篇文章,主要讲述了服务注册和服务发现这一块。在系列的第一篇文章中提到,我们的RPC框架需要有一个服务注册中心。通过这个中心,服务可以把自己的信息注册进来,也可以获取到别的服务的信息(例如ip、端口、版本信息等)。这一块有个统一的名称,叫服务发现。对于服务发现,现在有很多可供选择的工具,例如zookeeper,et

2017-11-01 23:29:03

如何写一个RPC框架(二):利用Bean容器和动态代理简化客户端代码

在后续一段时间里, 我会写一系列文章来讲述如何实现一个RPC框架。 这是系列第二篇文章, 主要讲述了如何利用Spring以及Java的动态代理简化调用别的服务的代码。在本系列第一篇文章中,我们说到了RPC框架需要关注的第一个点,通过创建代理的方式来简化服务调用代码。如果不使用代理?如果我们不用代理去帮我们操心那些服务寻址、网络通信的问题,我们的代码会怎样? 我们每调用一次远端服务,就要在业务代码中

2017-10-28 18:39:12

如何写一个RPC框架(一):关注点与我的实现

开始造轮子之旅, 本期轮子:RPC框架。 在后续一段时间里, 我会写一系列文章来讲述如何实现一个RPC框架。 这是系列第一篇文章, 主要从整体角度讲述了一个RPC框架组成结构与关注点, 并且附上了我的RPC框架的实现作为参考。RPC框架的关注点首先,什么是RPC?RPC的全称是Remote Procedure Call,远程过程调用。RPC框架有很多,比如hsf、dubbo等等。借助RPC框

2017-10-28 14:52:47

查看更多

勋章 我的勋章
  • 专栏达人
    专栏达人
    授予成功创建个人博客专栏的用户。专栏中添加五篇以上博文即可点亮!撰写博客专栏浓缩技术精华,专栏达人就是你!
  • 持之以恒
    持之以恒
    授予每个自然月内发布4篇或4篇以上原创或翻译IT博文的用户。不积跬步无以至千里,不积小流无以成江海,程序人生的精彩需要坚持不懈地积累!