- 博客(161)
- 资源 (3)
- 收藏
- 关注
RSS订阅原创 如何构建高可用的系统（三）：服务治理篇
在如何构建高可用的系统（一）：Overview中， 我提到了以下几点：系统依赖的一切下游系统都是不可靠的， 它们随时可能出问题系统的上游可能有多个， 而且每个上游的行为都是不可预知的。如果某个上游抽风把我的系统搞崩， 那么就会影响所有的上游高可用是有前提条件的，一个系统对当前的负载能提供高可用， 不代表负载上升之后仍然高可用如果把这几个问题，映射到现在非常流行的“微服务架构”下，就可以...
2019-01-19 19:32:16
1307
2
原创 如何构建高可用的系统（二）： 消除单点与自动故障转移
前一篇文章我们讲到， 一切单点都是不可靠的, 如果系统中某个地方可能会出问题（就算概率很低），那么它迟早会出问题。 也就是我们常说的Murphy’s Law。如果要提高系统的可用性， 那么就必须尽可能消灭掉系统中所有的单点，并且在发生故障时，把流量自动转移到运行正常的节点。在这篇文章中， 我会以互联网产品后端常见的架构为例， 讲述如何达到这个目标。1.常见系统架构互联网后端应用的常见架构可...
2019-01-12 21:01:07
1511
原创 如何构建高可用的系统（一）：Overview
1. What首先，我们需要对"可用性"下一个定义。 业界常用SLA（Service Level Agreement）来描述一个系统的可用性, SLA包含很多信息（服务内容、故障恢复时间、可用性等）， 在这里我们笼统的用“N个9”来指代，比如4个9指的是99.99%的可用性、 5个9指的是99.999%的可用性。假如一个系统声称它的年可用性是4个9， 那它提供的可用性承诺
2018-12-22 17:44:49
1435
原创 全球异地多活架构设计(二): 数据层的支持
要做到全球异地多活， 一定要在数据层支持多机房写入， 并且对大多数业务场景提供最终一致性的解决方案。原因如下：跨洲的网络延迟在100ms的数量级，如果只有单点写， 对于用户体验是种灾难对于高频操作来说, 如果做强一致性，那么任然受限于网络延迟， 对于用户体验是种灾难那么随之而来就有两个问题需要解决：跨机房的数据同步多点写入时的数据冲突处理一 、数据同步数据的同步有几个核心问...
2018-12-01 15:43:43
3040
原创 全球异地多活架构设计(一): Why and How
很多全球化的产品， 比如facebook、twitter， 它们的用户遍布世界各地。 工程师们往往会在全球设立多个数据中心（DC）供用户访问， 我们可以称之为异地多活。在后续一段时间里， 我会写一系列的博客，和大家一起探索异地多活架构。这篇文章主要是讨论我们为什么需要异地多活， 以及实现这种架构所需要解决的问题。一、异地多活的好处1. 提高用户体验一个产品最重要的是提供良好的用户体验，这对...
2018-11-04 18:20:37
4418
原创 对微信《Scalable Overload Control for Large-scale Microservice Architecture》论文的解读
这几年微服务大行其道，随之而来也伴随着很多问题： 服务注册和发现（常见解决方案如Consul, ZK, etcd)熔断和降级 （如Hystrix)…在服务过载时， 一个常见的解决方案是熔断。以前的熔断方案基本都是各个服务独自处理的， 即如果一个服务无法处理所有的请求， 那么就抛弃一部分请求。这种粗暴的处理方式并不能缓解整个系统的负载， 并且浪费了很多计算资源，比如以下场景：假设...
2018-08-12 22:02:26
1063
1
翻译 《设计数据密集型应用/DDIA》精要翻译（七） ：Linearizability
定义和理解Linearizability是常用的一致性模型（对于一致性模型，笔者后续会有专门的文章来讨论）之一，Linearizability也可以被称为原子一致性（atomic consistency），强一致性（strong consistency），立即一致性（immediate consistency）或外部一致性（external consistency ）。很难给Lineari...
2018-04-14 14:28:40
675
翻译 《设计数据密集型应用/DDIA》精要翻译（六） ：分布式系统中的问题
这一章我们会讨论分布式系统中一些常见的问题，在下一章中我们会讨论这些问题的解决办法。1.故障与部分失败在分布式系统中，系统的部分组件常常会以以某种未知的方式被破坏，我们称之为部分失败/部分故障。而我们的目标就是在不可靠的组件上构建一个可靠的系统。为了容忍部分失败：第一步是检测失败：大多数系统利用超时来判断节点是否可用，但是超时机制没办法区分是网络失效还是节点宕机在检...
2018-04-07 20:13:08
893
翻译 《设计数据密集型应用/DDIA》精要翻译（五） ：事务
1. 事务的ACID虽然ACID我们已经说滥了，这里我想再说一下一致性和隔离性。一致性一致性在不同的术语中有不同的含义：在前面那篇博客中，我们讨论了副本之间的一致性（比如最终一致性、读已之写一致性等）在CAP中，一致性表示可线性化（即只要有一个客户端成功写入，别的客户端后续的读取必须能看到刚刚写入的值。 详见本系列第七篇。）在ACID中，指数据库在事务前后保持正确（比如转...
2018-04-05 22:26:17
680
翻译 《设计数据密集型应用/DDIA》精要翻译（四） ：副本机制
从这一章开始，我们就正式从单机应用转向了分布式应用的旅程！ ps: 其实DDIA这书我1月份已经看完了，只不过那会儿实在没有心力去翻译。前段时间太太太忙了，对几千万日活的系统做了技术栈迁移、跨洲数据中心无缝平移。后续也会写文章来分享我们是怎么做的，欢迎持续关注。副本机制的意思是，在多台通过网络互连的机器上保存同一份数据的多份拷贝。我们为什么需要副本：让用户在地理上离数据...
2018-03-31 15:15:20
785
翻译 《设计数据密集型应用/DDIA》精要翻译（三） ：数据的存储和获取之底层数据结构
看了这三章，我最大的收货并不是说学到了什么新的知识，而是对以前通过各种渠道所掌握的知识重新进行了梳理和归纳，使它们有种脉络相通的感觉。一、驱动你的数据库的数据结构这也许是世界上最简单的数据库实现：db_set () { echo "$1,$2" >> database}db_get () { grep "^$1," dat...
2018-01-15 01:03:27
2411
2
翻译 《设计数据密集型应用/DDIA》精要翻译（二） ：数据模型和查询语言
当我们在设计kafka、mysql这样的数据密集型应用时，数据模型也许是最为重要的一个考虑点。因为它不仅影响了代码的写法，还影响着我们解决问题的思维方式。这是第一章第二节的读书笔记，介绍了几种不同的数据模型以及数据查询语言。（其实看目录就知道前两章都是小打小闹热热身，但是既然是神书，还是要好好看不是么？）一、关系型模型与文档型模型的比较关系型数据库和文档型数据库有很多的差异...
2018-01-13 16:39:52
1159
翻译 《设计数据密集型应用/DDIA》精要翻译（一） ：reliability, scalability, maintainability
之前一段时间在看Kafka的源码分析，想学着做个分布式消息系统。后来听说 《设计数据密集型应用》这本书是2017年的神书，对这样的数据系统的内在精髓有很好的讲解。 看完这本书之后再看kafka之类的数据系统能事半功倍。因此，虽然每天忙于搬砖，但还是要抽出时间来拜读一下！这本书暂时还没有中文版，未来的一段时间里我会陆陆续续边看边做部分精华内容的翻译。这是第一章第一节的读书笔记，介绍了re...
2018-01-11 13:51:17
2946
原创 关于负载均衡的一些总结
之前只了解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
963
原创 如何写一个RPC框架（六）：负载均衡
在后续一段时间里， 我会写一系列文章来讲述如何实现一个RPC框架。 这是系列第六篇文章， 主要讲述了RPC中负载均衡这一块的内容。常见的LB策略常见的LB策略有很多：RoundRobin (RR)： 一个列表中轮着来WeightedRoundRobin (WRR)： 带权重的RRLocalFirst：本地服务优先Random：随机选择ConsistentHash： 一致性哈希这些策
2017-11-19 13:50:01
3350
原创 如何写一个RPC框架（五）：服务器端实现
在后续一段时间里， 我会写一系列文章来讲述如何实现一个RPC框架（我已经实现了一个示例框架， 代码在我的github上）。 这是系列第五篇文章， 主要讲述了服务器端的实现。在前面的几篇文章里， 我们已经实现了客户端创建proxy bean， 并利用它来发送请求、处理返回的全部流程： 扫描package找出需要代理的service通过服务注册中心和Load Balancer获取se
2017-11-13 23:52:38
1052
原创 如何写一个RPC框架（四）：网络通信之客户端篇
在后续一段时间里， 我会写一系列文章来讲述如何实现一个RPC框架。 这是系列第四篇文章， 主要讲述了客户端和服务器之间的网络通信问题。模型定义我们需要自己来定义RPC通信所传递的内容的模型， 也就是RPCRequest和RPCResponse。@Data@Builderpublic class RPCRequest { private String requestId; pr
2017-11-12 14:36:13
2089
1
原创 如何写一个RPC框架（三）：服务注册与服务发现
在后续一段时间里， 我会写一系列文章来讲述如何实现一个RPC框架。 这是系列第三篇文章， 主要讲述了服务注册和服务发现这一块。在系列的第一篇文章中提到，我们的RPC框架需要有一个服务注册中心。 通过这个中心，服务可以把自己的信息注册进来，也可以获取到别的服务的信息（例如ip、端口、版本信息等）。这一块有个统一的名称，叫服务发现。对于服务发现，现在有很多可供选择的工具，例如zookeeper, et
2017-11-01 23:29:03
3595
1
原创 如何写一个RPC框架（二）：利用Bean容器和动态代理简化客户端代码
在后续一段时间里， 我会写一系列文章来讲述如何实现一个RPC框架。 这是系列第二篇文章， 主要讲述了如何利用Spring以及Java的动态代理简化调用别的服务的代码。在本系列第一篇文章中，我们说到了RPC框架需要关注的第一个点，通过创建代理的方式来简化服务调用代码。如果不使用代理？如果我们不用代理去帮我们操心那些服务寻址、网络通信的问题，我们的代码会怎样？ 我们每调用一次远端服务，就要在业务代码中
2017-10-28 18:39:12
2121
3
原创 如何写一个RPC框架（一）：关注点与我的实现
开始造轮子之旅， 本期轮子：RPC框架。 在后续一段时间里， 我会写一系列文章来讲述如何实现一个RPC框架。 这是系列第一篇文章， 主要从整体角度讲述了一个RPC框架组成结构与关注点， 并且附上了我的RPC框架的实现作为参考。RPC框架的关注点首先，什么是RPC？RPC的全称是Remote Procedure Call，远程过程调用。RPC框架有很多，比如hsf、dubbo等等。借助RPC框
2017-10-28 14:52:47
3524
原创 一次频繁Full GC的排查过程
问题描述最近公司的线上监控系统给我推送了一些kafka lag持续增长的消息，我上生产环境去看了相应的consumer的情况，发现几台机器虽然还在处理消息，但是速度明显慢了很多。问题猜测与验证我猜测是JVM频繁做Full GC，导致进程也跟着频繁卡顿，处理消息的速度自然就慢了。为了验证这个想法，先用jstat看看内存使用情况： jstat -gcutil 1 1000 #1是进程号结果如我所
2017-10-03 13:22:34
19383
3
转载 Netty线程模型
《Netty实战》这本书对于Netty的线程模型讲的还是太浅了，后来我找到一篇不错的文章。原文链接：http://www.infoq.com/cn/articles/netty-threading-model?utm_source=infoq&utm_campaign=user_page&utm_medium=link#anch1120041. 背景1.1. Java线
2017-09-24 19:29:51
637
原创 Netty实战读书笔记四：Bootstrapping
在深入地学习了 ChannelPipeline、ChannelHandler 和 EventLoop 之后，你接下来的问题可能是:“如何将这些部分组织起来，成为一个可实际运行的应用程序呢?” 答案是, 引导(Bootstrapping)。Bootstrap 类引导类的层次结构包括一个抽象的父类和两个具体的引导子类，如图 8-1 所示。服务器致力于使用一个父 Channel 来接受 来自客
2017-09-24 19:13:42
608
原创 Netty实战读书笔记三：EventLoop和线程模型
EventLoop 接口运行任务来处理在连接的生命周期内发生的事件是任何网络框架的基本功能。与之相应的编 程上的构造通常被称为事件循环— 一个 Netty 使用了 interface io.netty.channel. EventLoop 来适配的术语。代码清单 7-1 中说明了事件循环的基本思想，其中每个任务都是一个 Runnable 的实例。Netty 的 EventLoop 是协同设计的一部分
2017-09-24 17:45:41
608
原创 Netty实战读书笔记二：ChannelHandler和ChannelPipeline
ChannelHandler家族Channel生命周期Interface Channel 定义了一组和 ChannelInboundHandler API 密切相关的简单但 功能强大的状态模型，表 6-1 列出了 Channel 的这 4 个状态。 Channel 的正常生命周期如图 6-1 所示。当这些状态发生改变时，将会生成对应的事件。 这些事件将会被转发给 ChannelPipeline 中
2017-09-24 16:41:20
616
原创 Netty实战读书笔记一：Netty的组件和设计以及它的传输
工作中用到了GRPC, 而它又用到了Netty, 所以最近在学习Netty的相关内容。第三章 Netty的组件和设计Channel 接口基本的 I/O 操作(bind()、connect()、read()和 write())依赖于底层网络传输所提 供的原语。在基于 Java 的网络编程中，其基本的构造是 class Socket。Netty 的 Channel 接 口所提供的 API，大大地降低
2017-09-23 15:08:25
520
原创 Consul实现原理系列文章3: Consul的整体架构
工作中用到了Consul来做服务发现，之后一段时间里，我会陆续发一些文章来讲述Consul实现原理。在前几篇文章介绍完了Consul用到的两个关键性东西Raft和Gossip之后，这篇文章会讲述Consul的整体架构。本文基于一篇别的译文，并做了一些改进和完善。术语表代理(agent)： 代理是Consul集群上每个成员的守护进程，它是由consul agent开始运行。代理能够以客户端或服务
2017-09-07 22:37:01
6125
3
原创 Consul实现原理系列文章2: 用Gossip来做集群成员管理和消息广播
工作中用到了Consul来做服务发现，之后一段时间里，我会陆续发一些文章来讲述Consul实现原理。这篇文章会讲述Consul是如何使用Gossip来做集群成员管理和消息广播的。Consul使用Gossip协议来管理集群中的成员关系，以及把消息广播到集群中。而这些Gossip的特性是利用Serf这个lib来实现的。下面，我们先来看看什么是Gossip协议。Gossip协议 在学习Gossip的
2017-09-06 22:47:18
1785
原创 Consul实现原理系列文章1: 用Raft来实现分布式一致性
工作中用到了Consul来做服务发现，之后一段时间里，我会陆续发一些文章来讲述Consul实现原理。在前一篇文章中，我介绍了Raft算法。这篇文章会讲讲Consul是如何使用Raft算法来实现分布式一致性的。Consul中的Raft只有以server模式运行的Consul节点，才会被认为是Raft节点集的一部分。所有的client节点会把收到的请求转发到server节点中。这么设计的原因主要是出于
2017-09-03 14:48:47
7327
原创 分布式一致性之Raft算法
最近工作中用到了Consul，在学习过程中，发现它是基于Raft来做分布式一致性的。正巧以前学习过Raft, 那么就正好借此机会复习一下吧！
2017-09-02 19:44:29
1914
3
原创 我在分布式session上的一些实践
这篇文章大致讲解了用Nginx+Tomcat+Spring+Redis实现分布式session。Spring项目地址：https://github.com/hshenCode/spring_redis_exercise1. 系统拓扑1台Redis服务器，用来存储session。2台Tomcat服务器，访问Redis进行session存储。1台Nginx服务器，作为反向代
2017-06-09 15:10:06
559
转载 使用消息队列需要注意的几个关键问题
工作的项目中使用了消息队列，需要注意几个关键问题：消息的顺序问题消息的重复问题事务消息看了一篇不错的文章，以下是那篇文章部分内容：一、顺序消息消息有序指的是可以按照消息的发送顺序来消费。例如：一笔订单产生了 3 条消息，分别是订单创建、订单付款、订单完成。消费时，要按照顺序依次消费才有意义。与此同时多笔订单之间又是可以并行
2017-04-19 23:58:48
20765
4
原创 RabbitMQ中的Exchange Types
整理自：https://www.rabbitmq.comhttps://www.cloudamqp.com/blog/2015-09-03-part4-rabbitmq-for-beginners-exchanges-routing-keys-bindings.html《RabbitMQ实战》在RabbitMQ中，消息不是直接被发布到队列上的，生产者把消息发送到
2017-04-16 20:09:34
3721
原创 微服务架构(十): 一些别的问题
除了前面的文章所提到的话题，还有一些别的在微服务架构中非常重要的问题，比如安全测试（单个组件的测试、集成测试）CI/CD（持续集成，持续交付/持续部署）这些话题，在这占个坑，留给日后再讨论。
2017-04-04 17:44:00
939
翻译 微服务架构(九): 数据管理
工作中使用了微服务架构，接下来的一段时间里，我会写一系列的文章来介绍微服务架构，这篇文章主要讲述了微服务架构中的数据管理。
2017-04-04 17:19:39
3372
翻译 微服务架构(八): 断路器
工作中使用了微服务架构，接下来的一段时间里，我会写一系列的文章来介绍微服务架构，同时我也会在github上写一个microservices的应用框架（地址会在后续文章给出）。这篇文章主要讲述了微服务架构中的断路器。翻译和整理自：http://microservices.io/patterns/reliability/circuit-breaker.html
2017-04-04 14:06:43
3579
翻译 微服务架构(七): 服务发现与服务注册
工作中使用了微服务架构，接下来的一段时间里，我会写一系列的文章来介绍微服务架构，同时我也会在github上写一个microservices的应用框架（地址会在后续文章给出）。这篇文章主要讲述了微服务架构中的API Gateway。翻译和整理自：http://microservices.io/patterns/client-side-discovery.htmlhttp://
2017-04-04 13:21:13
10602
翻译 微服务架构(六): API Gateway
工作中使用了微服务架构，接下来的一段时间里，我会写一系列的文章来介绍微服务架构，同时我也会在github上写一个microservices的应用框架（地址会在后续文章给出）。这篇文章主要讲述了微服务架构中的API Gateway。翻译和整理自：http://microservices.io/patterns/apigateway.html一、问题微服
2017-04-03 22:57:23
5408
翻译 微服务架构(五): 服务间通信方式
工作中使用了微服务架构，接下来的一段时间里，我会写一系列的文章来介绍微服务架构，同时我也会在github上写一个microservices的应用框架（地址会在后续文章给出）。这篇文章主要讲述了微服务架构中服务间的通信方式。翻译和整理自：http://microservices.io/patterns/communication-style/rpi.htmlhttp://mi
2017-04-03 22:16:15
16503
4
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人